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
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
