This document discusses principles of agile architecture, including that teams should code and design systems, build the simplest architecture possible, and test what they build. It also discusses building an "architectural runway" by determining an initial component-based architecture and prototyping if needed. Extending the runway involves identifying future needs and evaluating them. The document cautions against the myth that up-front architecture is bad, stating that some initial architectural decisions are needed.

1. Architectural Runway
Dmitriy Viktorov
AgileDays’10, St.Petersburg, September 17th 2010
Protecting the irreplaceable | f-secure.com

2. 2

3. 3

4. 4 © F-Secure Confidential

5. 5 © F-Secure Confidential

6. 6 © F-Secure Confidential

7. 7 © F-Secure Confidential
21 September,

8. Principles of Agile Architecture
1. The teams that code the system design the system
2. Build the simplest architecture that can possibly work
3. When in doubt, code it out
4. They build it, they test it
5. The bigger the system, the longer the runway
6. System architecture is a role collaboration
7. There is no monopoly on innovation
8. Implement architectural flow
8

9. 9

10. * Source : Scaling Software Agility by Dean Leffingwell
Copyright © 2009 Leffingwell, LLC.
10

11. Architecture is role collaboration
Architectural
inputs,
ideas,
constraints
Architectural Evolution
11

12. Building Architecture Runway
Theme 1 Solution Epics
Epic Epic Epic Architecture features, in which the
1 2 5 Solution features depends on.
A
r
c
Epic 3
h Solution features without
E
i dependency on arch feature.
p
t
i
e Epic 4 Architecture features without
c
c dependency from solution features.
s
t
u Solution feature
r Epic 6
Arch feature
e
Note : No time dimension is illustrated in this picture.
12

13. Building Architecture Runway
3. Update
1. Determine initial component-based
architecture that will influence the eventual
formation of the application teams.
Architects /
Technical
iterate leaders
If uncertainty
high & risky
Feedback
2. Prototyping (Optional)
13

14. Extending Architecture Runway
3. Update
Spikes that
cannot resolved
“program” spikes
1. Identify story : design spikes, refactoring within a team
into iteration
required, evaluations & dependencies.
2. Determine what features the system iterate
may require in upcoming release plan
that are not presently supported by
architecture.
Architects /
Technical
iterate leaders
14

15. State Machine for Architectural Epic Kanban Model
2
Portfolio Disruptive Backlog
Roadmap technology
Technology
Roadmap criteria met, not ready
slot avail.
further
value/effort>X, 3 review
1 rejected slot avail.
Funnel Analysis
Trash
rejected
rejected
4 business case
approved &
Implementation resource available
Solution Common
problem usage model
15

16. One of the more insidious and persistent myths of agile development
is that up-front architecture and design are bad; that you should never
spend time up front making architectural decisions. That instead you
should evolve your architecture and design from nothing, one test-
case at a time.
Pardon me, but that’s Horse Shit.
(...)
Don’t feel that TDD is the only way to design. On the other hand,
don’t let yourself get too vested in your designs. Allow TDD to change
your plans if it leads you in a different direction.
Robert C. Martin, ObjectMentor blog, „The Scatalogy of Agile
Architecture”, 25.04.2009
17

17. Thank You!
Questions ?
18