architectural runway
TRANSCRIPT
Protecting the irreplaceable | f-secure.com
Architectural Runway
Dmitriy Viktorov
AgileDays’10, St.Petersburg, September 17th 2010
2
3
© F-Secure Confidential4
© F-Secure Confidential5
© F-Secure Confidential6
© F-Secure Confidential21 September,
2010
7
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
10
* Source : Scaling Software Agility by Dean Leffingwell
Copyright © 2009 Leffingwell, LLC.
Architecture is role collaboration
11
Architectural
inputs,
ideas,
constraints
Architectural Evolution
Theme 1
A
r
c
h
i
t
e
c
t
u
r
e
E
p
i
c
s
Solution Epics
Epic
1
Epic
2
Epic
5
Epic 6
Epic 4
Epic 3
Building Architecture Runway
12
Arch feature
Solution feature
Architecture features, in which the
Solution features depends on.
Note : No time dimension is illustrated in this picture.
Solution features without
dependency on arch feature.
Architecture features without
dependency from solution features.
Building Architecture Runway
13
1. Determine initial component-based
architecture that will influence the eventual
formation of the application teams.
Architects /
Technical
leaders
2. Prototyping (Optional)
If uncertainty
high & risky
iterate
3. Update
Feedback
Extending Architecture Runway
14
“program” spikes
into iteration1. Identify story : design spikes, refactoring
required, evaluations & dependencies.
2. Determine what features the system
may require in upcoming release plan
that are not presently supported by
architecture.Architects /
Technical
leadersiterate
3. UpdateSpikes that
cannot resolved
within a team
iterate
State Machine for Architectural Epic Kanban Model
15
Disruptive
technology
Portfolio
Roadmap
Solution
problem
Technology
Roadmap
Funnel
1
Common
usage model
Backlog2
Analysis3
Implementation
4
criteria met,
slot avail.
value/effort>X,
slot avail.
not ready
business case
approved &
resource available
Trash
further
review
rejected
rejected
rejected
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
Thank You!Questions ?
18