This is an updated version of this talk which I will present at Agile 2013. The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn’t require ongoing attention. But it isn’t always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky. So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.

1. Why We Need
Architects (and
Architecture) on
Agile Projects
Rebecca Wirfs-Brock
rebecca@wirfs-brock.com
www.wirfs-brock.com
©2013 Wirfs-Brock Associates

2. Three Questions…
• How much architecting do you need and
when?
• How can you manage architecture risk on
small as well as large, complex projects?
• What is the role of an agile architect?
? ? ?

3. Agile Design Values
• Core values:
– Design Simplicity
– Sustainable systems
– Continuous improvement
– Teamwork
– Communication
– Trust
– Satisfying stakeholder needs
• Constant learning

4. Qualities of Good Architecture
• Pragmatic. Does what it needs to without
extras
• Designed for test
• Modular
• No unintentional data redundancy or
overlapping functionality
• Supports
performance, reliability, modifiability, usability
,….

5. How Much Architecting Do You Need?
Alistair Cockburn’s project characteristics grid

6. What’s a Small Project?
• A team of 6-8
• Working on non-life critical
projects
• Architecture typically
evolves along with
implementation without
much risk
• May or may not need extra
architecture attention

7. Small Project Architecture Practices:
Design “Spikes”
• Goal: Figure out a
design approach
• Time: Few hours to
a few days
• Tools: CRC
Cards, exploratory
coding, whiteboard
sketching

8. Small Project Architecture Practices:
Experiment on Branches
• Goal: Experiment away
from main code branch
• Time: Few hours to a
few days
• When done: Merge or
throwaway branch
code

9. Small Project Architecture Practices:
Incrementally Refine Abstractions
• Goal: Refactor to
eliminate redundant
code
• Time: Few minutes
• When done:
Whenever you spot
duplication

10. Small Project Architecture Practices:
Manage Technical Debt
• Term invented by Ward
Cunningham
• Piles up when you
continually implement
without going back to
reflect new
understanding
• Can have long term
costs and consequences

11. All Tasks Aren’t Alike
• The Core—fundamental to
your software’s success
• The rest—requires far less
creativity or inspiration
• The Revealing—lead to
new, deeper understanding
– Always a surprise
– Require invention and innovation
– Hard to predict when they will be
done
– Don’t neatly fit into a planned
iteration cycle

12. Keeping Architecture in Mind
• Sort tasks into “problem
buckets”: core and the rest
• Make sure each iteration
gets enough core work
accomplished
• Get team involved on core
issues
• Use post-iteration
reflections to ask why
things were harder than
they first appeared

13. Architectural Practice:
Reduce Technical Debt
• Integrate new learning
into your code
– Refactoring
– Redesign
– Rework
– Code clean up
• Unit tests
(functionality)
• Test for architectural
qualities
(performance, reliabilit
y,…)

14. Best Practices for Small Project
Architecture
• Pay attention to architecture
• Don’t only work on feature
implementation
• Strive for design consistency. “This
is the way we do x”
– Coding standards
– Consistent implementation practices
(API use, errors, logging…)
• Code stewards for architecturally
critical areas

15. THE MORE THERE IS TO
COORDINATE
The Bigger the Project….

16. Team Size Matters
• >9 and any group splits
into teams
• No one knows everything
or everybody
– Expertise uneven
– Skills varied
– Specialists
• Work needs coordination
• Architecture allowed to
“naturally” emerge often
reflects the
organizational structure

17. Types of Project Risks
• Schedule & budget
• Operational
– execution
– resources
– communications
• Technical
– too complex
– poorly defined
– misunderstood

18. Risk Management Strategies
• Avoid
• Share: Insure or transfer
• Retain: Accept and budget for
• Reduce: Mitigate
– Develop incrementally
– Integrate often
– Design innovate if needed

19. Iterative & Incremental Lifecycles
Reduce Technical Risks

20. THE LAST POSSIBLE MOMENT
Especially on Large Projects, Some Decisions are too
Important to Leave Until

21. Agile Misconception: Upfront
Thinking, Planning, Investigating, Archi
tecting is Wasteful
• A reaction to “too much” thinking without
“doing”.
• Reality:
– You need to strike a balance: Find the right time and
effort for your project
• Some upfront planning is critical for large, complex projects
• Ongoing thinking, prototyping, and architecture experiments
are important too.

22. CHOOSE THE MOST RESPONSIBLE
MOMENT
A Better Way to Act:

23. Stuart Brand’s Shearing Layers
• Buildings are made of components that evolve
at different timescales.
• Layers: site, structure, skin, services, space
plan, stuff. Each layer has its own value, and
speed of change (pace).
• Buildings adapt because
faster layers (services) are
not obstructed by slower
ones (structure).
—Stuart Brand, How Buildings Learn

24. Yoder and Foote’s
Software Shearing Layers
“Factor your system so that artifacts that change at similar rates
are together.”—Foote & Yoder, Ball of Mud Pattern
• The platform
• Infrastructure
• Data schema
• Standard frameworks and components
• Abstract classes and interfaces
• Classes
• Code
• Data
LayersSlower
Faster

25. Agile Architecture Values
• Respect your system’s shearing layers
– Understand the rates of what changes
– Isolate rapidly changing parts/components from more stable
ones
• Make what is too difficult, time consuming, or tedious
easier
– Create tools, leverage design patterns, build or use
frameworks, use data to drive behavior…
• Don’t overdesign!!!
• Don’t under architect
• Architect for sustainable development/delivery of
features and customer value

26. Being Agile Does Not Mean
• You can make
significant architecture
changes at the last
moment
• Good architecture
always emerges from
“good” development
practices
• Sometimes you need to
do more

27. Architecture Debt
• Compromises in the
system that have
significant impacts
• Not isolated
• Costly to reverse
• Examples:
– reliance on a poorly
designed framework
– inconsistent service
interfaces

28. Architecture Risk Reduction Tools for
Larger Projects and Programs
• Grooming and vetting project/product road
maps and timelines
• Landing zones
• Architecture spikes
• Risk reduction backlogs
• Set-based design
Component
Design Choices
Design Cycle Decision to Eliminate
x
x
x

29. Product Roadmaps As Guides
• Where you expect
to go
• What features and
when? Relative
time when feature
is needed
• Influence
architecture work
and efforts
Sherwood, Oregon
Portland International Airport

30. Product Landing Zones
• A range of acceptable
values for important
system qualities
– Minimal: OK, we
can live with that
– Target: Realistic
goal, what we are aiming
for
– Outstanding: This
would be great, if
everything goes well

31. Good Landing Zone Criteria
• Define acceptable range of values for some
characteristic or system quality
(performance, usability, reliability, etc.)
– # transactions, average latency of a transaction under
load, click through rate, up time….
• Broader in scope than an acceptance criteria
• SMART
• Specific
• Measurable
• Achievable (minimum value)
• Relevant
• Timely
Within
acceptable
limits
Within
acceptable limits

32. Good Acceptance Criteria
• Focused on a single thing (a rule or step of a
process)
• A specification of what should happen/what must
be true written in the language of the domain
• SMART
• Specific
• Measurable
• Achievable
• Relevant
• Timely

33. What’s Different?
Acceptance Criteria
Free 2-day shipping is offered to
Amazon Prime customers for all
items in an order that are sold
directly by Amazon
If an Amazon prime customer
wants faster shipping, they pay
standard shipping fees.
Automated tests can be written
(fairly easily)
Landing Zone Criteria
Selection of shipping options
should be completed with 99%
customer accuracy
Test, but usually in production or
staging environment
May require instrumenting
“hooks” and making several
measurements that are
aggregated/interpreted

34. Too many landing zone criteria and you lose track of what’s important
Define a core set, organize and group
Break down aggregate targets into measurable architecture-specific
goals/targets
To be agile, re-calibrate values as you implement more functionality
Managing Landing Zones
Minimum Target Outstanding
Throughput (loan
payment txns per day)
50,000 70,000 90,000
Average loan payment
txn time
2 seconds 1 second < 1 second
Intersystem data
consistency between x,
y, z systems (per cent
critical data attributes
consistent)
95% 97% 97%
ETL data accuracy for
claims data
97% 99% >99%
Performance
Data Quality

35. Agreeing on Landing Zone Targets
• Someone makes a first “rough cut”
• Base targets on history & evidence
• Discuss and fine-tune as a group
– product manager, architects, QA lead
• Informed consensus-building

36. How Architects Use & Interact with
Landing Zones
• Create them along with Product Owners and
other Stakeholders
• Identify high architecture risk items
• Establish/verify target values
• Explain architecture tradeoffs and costs
• Monitor architecture health
• Recalibrate landing zone values based on
emerging design

37. Landing Zones on Agile
Projects
• Helps make sense of
the bigger picture:
– What happens when
one attribute edges
below minimum?
– When will targets be
achieved?
– What do we need to
do architecturally to
achieve targets?

38. Architecture Spikes
• Answer deep questions
about potential solutions
for achieving landing
zone targets
• Not as tactical or
incidental as an XP
Design Spike
• Try out radical changes in
how things are done
before committing to
them
• How can we scale up, scale
out, re-distribute, re-
think…????

39. XP Design Spike
“A spike solution is a very simple program to explore
potential solutions. Build the spike to only addresses
the problem under examination and ignore all other
concerns. Most spikes are not good enough to
keep, so expect to throw it away. The goal is
reducing the risk of a technical problem or increase
the reliability of a user story’s estimate.”
—Don Wells
http://www.extremeprogramming.org/rules/spike.html

40. What You Do In an Architecture Spike
– prototyping
– design noodling
– looking outside
– experimenting
– modeling
– proving ideas

41. Criteria For an Architecture Spike:
Answer Bounded Questions
• Buys information
– Feasibility
– Reasonable design
approach
– Alternatives
• Better estimates
• Actionable

42. Criteria For an Architecture Spike:
Actionable Results
• Buy information
that
– Feeds into future
release planning
– Adjusts the
release roadmap
– Recalibrates your
landing zone
– Drives new
development and
design
Actionable
or
evidence

43. Architecture Spikes
• Example spikes:
– Business
transaction
redesign
– Document parsing
investigation
– Fact
representation &
rule simplification
– Automated
location of
external resources

44. Architecture Spike Best Practices
• Small, smart, goal-oriented teams
– avoid us vs. them mentality
• Evidence-based answers
– working prototypes
– existing similar things
• Time-boxed
– Limited scope and duration (2-6
weeks)
• Failure is an option
– permit answers that will shift your
goals

45. 3 Ways To Manage Architectural Tasks

49. Architecturally
meaty feature
Design spike
related task
Architecture
investigation
Prototype Framework
development
Roadmap
exploration
What Can Go On An Architecture
Backlog?

50. WHAT DO AGILE ARCHITECTS DO?

51. Primary Architecture Responsibilities
system
integrity
balance elegancearchitecture
views,
explanations,
sketches
system structure
design approach
module
subsystem
system
X
51

52. The Agile Architecture Landscape

53. The Integral Triad

54. Agile Architecture Wayfinding
• Scouting—looking
enough ahead
• Exploring potential
paths
– Short experiments
– Extrapolations
– Conclusions based
on
experience, intellig
ence gathered &
intuition
• Explaining and
selling architectural
ideas

55. Differences Between Agile and Traditional
Architecture
Traditional
• Big picture thinking
• Produces Models and
blue prints
• Not so hands-on
• Focused on
compliance
Agile
• Balances big picture &
details
• Produce what’s needed to
make informed decisions
• Hands-on
• Focused on sustainability
55

56. Models
“Big M” vs. “little m”
• Lots of time invested
• Intended to last
• “Definitive”
• Usually formal
• May not be widely used
or understood
• Not a lot of time invested
• Intended to communicate
• Often discarded
• Can be formal or informal
• Made to be viewed
Agile architects create models as needed

57. Model
Maintain problem
related info
Broadcast change
notification
View
Render the model
Transform
coordinates
Model
Controller
Controller
Interpret user input
Distribute control
Model
View
“A Laboratory For Teaching Object-
Oriented Thinking,”
Kent Beck, Apple Computer, Inc., Ward
Cunningham, Wyatt Software
Services, Inc.
OOPSLA 89
CRC Cards: A “little m” model
The First CRC Cards

58. Example:
Component Responsibility Descriptions
Application
Support
Business
"Applications"
Allowed to
use
Attribute
Defintion
Business
Rule
Customer xxx
Price
Definition
Offering Term
Underwriting Sourcing
Note
Custody
Pooling
Payment
Management
Default Relationship xxx
Data Import/Export xxx xxx xxx Reporting
Fraud
Management
Loan Account Contract Agreement xxx xxx xxxBusiness
Infrastructure
Attribute
Defintion
Key
Business
Subysystem
“The Customer component is responsible for knowing the organizations and
individuals. It includes authentication and role-based authorization for detailed
tasks and contact information for organizations.”

59. Example:
Database
“Responsibilities”

60. Values Important to Agile Architects
• Balance
• Testable
architectural
qualities
• Being hands-on
– programming, des
igning, reading
code, building
things…
• Sustainable
development

61. Sustainable
Architecture
• Stewardship
– Follow through
– Ongoing attention
– Not ignoring the little things that
can undermine our ability to
grow, change and adapt our
systems

62. Sustaining an Architecture
• Minimize architectural
debt: Support the ability
to change/adapt what
needs to change
• Make what is too
difficult, time
consuming, or tedious
easier
• Decide at the most
responsible moment, not
the last possible moment
• Learn and evolve
62
Keep the system “livable” for its users and developers

63. Agile Values Drive Architectural
Practices
• Do something. Don’t debate or
discuss architecture too long.
• Do something that buys you
information
• Prove your architecture ideas
• Reduce risks
• Make it testable
• Prototype realistic scenarios that
answer specific questions
• Incrementally refine your
architecture
• Defer architectural decisions that
don’t need to be immediately made
Do
something!
Prove &
Refine.

64. Indicators You’ve Paid Enough
Attention to Architecture
• Defects are localized
• Stable interfaces
• Consistency
• Developers can easily add
new functionality
• New functionality doesn’t
“break” existing architecture
• Few areas that developers avoid because they are
too difficult to work in
• Able to incrementally integrate new functionality

65. 65