SlideShare a Scribd company logo
Why We Need
Architects (and
Architecture) on
Agile Projects
Rebecca Wirfs-Brock
rebecca@wirfs-brock.com
www.wirfs-brock.com
©2013 Wirfs-Brock Associates
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?
? ? ?
Agile Design Values
• Core values:
– Design Simplicity
– Sustainable systems
– Continuous improvement
– Teamwork
– Communication
– Trust
– Satisfying stakeholder needs
• Constant learning
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
,….
How Much Architecting Do You Need?
Alistair Cockburn’s project characteristics grid
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
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
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
Small Project Architecture Practices:
Incrementally Refine Abstractions
• Goal: Refactor to
eliminate redundant
code
• Time: Few minutes
• When done:
Whenever you spot
duplication
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
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
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
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,…)
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
THE MORE THERE IS TO
COORDINATE
The Bigger the Project….
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
Types of Project Risks
• Schedule & budget
• Operational
– execution
– resources
– communications
• Technical
– too complex
– poorly defined
– misunderstood
Risk Management Strategies
• Avoid
• Share: Insure or transfer
• Retain: Accept and budget for
• Reduce: Mitigate
– Develop incrementally
– Integrate often
– Design innovate if needed
Iterative & Incremental Lifecycles
Reduce Technical Risks
THE LAST POSSIBLE MOMENT
Especially on Large Projects, Some Decisions are too
Important to Leave Until
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.
CHOOSE THE MOST RESPONSIBLE
MOMENT
A Better Way to Act:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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…????
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
What You Do In an Architecture Spike
– prototyping
– design noodling
– looking outside
– experimenting
– modeling
– proving ideas
Criteria For an Architecture Spike:
Answer Bounded Questions
• Buys information
– Feasibility
– Reasonable design
approach
– Alternatives
• Better estimates
• Actionable
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
Architecture Spikes
• Example spikes:
– Business
transaction
redesign
– Document parsing
investigation
– Fact
representation &
rule simplification
– Automated
location of
external resources
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
3 Ways To Manage Architectural Tasks
Why We Need Architects (and Architecture) on Agile Projects
Why We Need Architects (and Architecture) on Agile Projects
Why We Need Architects (and Architecture) on Agile Projects
Architecturally
meaty feature
Design spike
related task
Architecture
investigation
Prototype Framework
development
Roadmap
exploration
What Can Go On An Architecture
Backlog?
WHAT DO AGILE ARCHITECTS DO?
Primary Architecture Responsibilities
system
integrity
balance elegancearchitecture
views,
explanations,
sketches
system structure
design approach
module
subsystem
system
X
51
The Agile Architecture Landscape
The Integral Triad
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
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
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
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
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.”
Example:
Database
“Responsibilities”
Values Important to Agile Architects
• Balance
• Testable
architectural
qualities
• Being hands-on
– programming, des
igning, reading
code, building
things…
• Sustainable
development
Sustainable
Architecture
• Stewardship
– Follow through
– Ongoing attention
– Not ignoring the little things that
can undermine our ability to
grow, change and adapt our
systems
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
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.
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

More Related Content

PPTX
cloud-migrations.pptx
PPT
Container security
PPTX
Information management and data governance in Office 365
PPTX
Apache Kafka Best Practices
PDF
Finding Your Way in Container Security
PDF
Consul: Service Mesh for Microservices
PDF
"DevOps > CI+CD "
PDF
Taylor Wicksell and Tom Gianos at SpringOne Platform 2019
cloud-migrations.pptx
Container security
Information management and data governance in Office 365
Apache Kafka Best Practices
Finding Your Way in Container Security
Consul: Service Mesh for Microservices
"DevOps > CI+CD "
Taylor Wicksell and Tom Gianos at SpringOne Platform 2019

What's hot (20)

PPTX
Docker Container Security
PPTX
Understanding container security
PPTX
Control Kubernetes Ingress and Egress Together with NGINX
PPTX
What is Site Reliability Engineering (SRE)
PPTX
Site (Service) Reliability Engineering
PDF
WSO2Con US 2015 Kubernetes: a platform for automating deployment, scaling, an...
PPTX
Cloud workload migration guidelines
PPTX
MULTI-CLOUD ARCHITECTURE
PPTX
When IGA meets PAM ... through their mutual friend SCIM
PPTX
DevOps Introduction
PDF
Oracle Cloud Infrastructure – Storage
PDF
Enterprise Application and Data Protection on AWS with Amazon FSx for NetApp ...
PDF
Site Reliability Engineering (SRE) - Tech Talk by Keet Sugathadasa
PDF
Cloud Native In-Depth
PPTX
cloud computing
PDF
Docker London: Container Security
PDF
Container Security
PPTX
Oracle Cloud Infrastructure.pptx
PPTX
Cloud security
PPTX
Cloud Native: what is it? Why?
Docker Container Security
Understanding container security
Control Kubernetes Ingress and Egress Together with NGINX
What is Site Reliability Engineering (SRE)
Site (Service) Reliability Engineering
WSO2Con US 2015 Kubernetes: a platform for automating deployment, scaling, an...
Cloud workload migration guidelines
MULTI-CLOUD ARCHITECTURE
When IGA meets PAM ... through their mutual friend SCIM
DevOps Introduction
Oracle Cloud Infrastructure – Storage
Enterprise Application and Data Protection on AWS with Amazon FSx for NetApp ...
Site Reliability Engineering (SRE) - Tech Talk by Keet Sugathadasa
Cloud Native In-Depth
cloud computing
Docker London: Container Security
Container Security
Oracle Cloud Infrastructure.pptx
Cloud security
Cloud Native: what is it? Why?
Ad

Viewers also liked (20)

PPTX
Software architecture in an agile environment
PDF
Adam boczek 2015 agile architecture in 10 steps v1.0
PDF
Architectural runway
PDF
Agile enterprise architecture
PPTX
User story estimation with agile architectures
PPTX
Does Agile Enterprise Architecture = Agile + Enterprise Architecture?
PDF
Microservices: Architecture for Agile Software Development
PPTX
Agile, TOGAF and Enterprise Architecture: Will They Blend?
PPTX
Comparing Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD)
PPTX
Maintaining Your Code Clint Eastwood Style
PPT
Agiles 2009 - Agile Architecture - Diego Fontdevila
PPTX
Agile Architecture
PDF
The tension between agile and architecture
PPTX
Agile Architecture and Design
PDF
Searching for Inspiration: User Needs and Search Architecture
PPTX
Architecture in agile projects
PPTX
Agile Architecture: Ideals, History, and a New Hope
PDF
Shearing Layers: An architectural response to uncertainty & change
PPTX
Agile DC 2013 - Comparing Scaled Agile Framework (SAFe) with Disciplined Agil...
PDF
Análisis de arquitecturas de software
Software architecture in an agile environment
Adam boczek 2015 agile architecture in 10 steps v1.0
Architectural runway
Agile enterprise architecture
User story estimation with agile architectures
Does Agile Enterprise Architecture = Agile + Enterprise Architecture?
Microservices: Architecture for Agile Software Development
Agile, TOGAF and Enterprise Architecture: Will They Blend?
Comparing Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD)
Maintaining Your Code Clint Eastwood Style
Agiles 2009 - Agile Architecture - Diego Fontdevila
Agile Architecture
The tension between agile and architecture
Agile Architecture and Design
Searching for Inspiration: User Needs and Search Architecture
Architecture in agile projects
Agile Architecture: Ideals, History, and a New Hope
Shearing Layers: An architectural response to uncertainty & change
Agile DC 2013 - Comparing Scaled Agile Framework (SAFe) with Disciplined Agil...
Análisis de arquitecturas de software
Ad

Similar to Why We Need Architects (and Architecture) on Agile Projects (20)

PPT
He mian agile project-inception
PDF
Right-sized Architecture: Integrity for Emerging Designs
PDF
SAF - architecture framework
PDF
Reality checking agile's architectural inner workings
PDF
Picking the right architecture and sticking to it
PPTX
Unit iii-Architecture in the lifecycle
PDF
Evolution Of Architecture, Pawel Lipinski
PDF
Scrum Bangalore 18th Meetup - October 15, 2016 - Agile Architecture - Deepak ...
PPTX
L22 Architecture and Agile
PDF
Architecture in an Agile World
PPTX
Agile Architecture and Modeling - Where are we Today
PDF
GECon2017_ Lean_architecturemanagement_Andrei Kavaleu
PDF
Pragmatic Architecture for Agile Teams
PDF
L21 Architecture and Agile
PDF
Agile It 20091020
PPTX
NISI Agile Software Architecture Slide Deck
PDF
Ten Advices for Architects
PDF
10 Hinweise für Architekten
PDF
Applying Agile Values to Enterprise Architecture Software Architectural Trend...
PPT
Arch factory - Agile Design: Best Practices
He mian agile project-inception
Right-sized Architecture: Integrity for Emerging Designs
SAF - architecture framework
Reality checking agile's architectural inner workings
Picking the right architecture and sticking to it
Unit iii-Architecture in the lifecycle
Evolution Of Architecture, Pawel Lipinski
Scrum Bangalore 18th Meetup - October 15, 2016 - Agile Architecture - Deepak ...
L22 Architecture and Agile
Architecture in an Agile World
Agile Architecture and Modeling - Where are we Today
GECon2017_ Lean_architecturemanagement_Andrei Kavaleu
Pragmatic Architecture for Agile Teams
L21 Architecture and Agile
Agile It 20091020
NISI Agile Software Architecture Slide Deck
Ten Advices for Architects
10 Hinweise für Architekten
Applying Agile Values to Enterprise Architecture Software Architectural Trend...
Arch factory - Agile Design: Best Practices

Recently uploaded (20)

PPTX
Understanding_Digital_Forensics_Presentation.pptx
DOCX
The AUB Centre for AI in Media Proposal.docx
PDF
Peak of Data & AI Encore- AI for Metadata and Smarter Workflows
PDF
Review of recent advances in non-invasive hemoglobin estimation
PPTX
breach-and-attack-simulation-cybersecurity-india-chennai-defenderrabbit-2025....
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
PDF
Network Security Unit 5.pdf for BCA BBA.
PDF
Per capita expenditure prediction using model stacking based on satellite ima...
PDF
GDG Cloud Iasi [PUBLIC] Florian Blaga - Unveiling the Evolution of Cybersecur...
PPT
“AI and Expert System Decision Support & Business Intelligence Systems”
PDF
Dropbox Q2 2025 Financial Results & Investor Presentation
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
PPTX
Effective Security Operations Center (SOC) A Modern, Strategic, and Threat-In...
PDF
[발표본] 너의 과제는 클라우드에 있어_KTDS_김동현_20250524.pdf
PDF
Empathic Computing: Creating Shared Understanding
PDF
Advanced Soft Computing BINUS July 2025.pdf
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
PDF
Electronic commerce courselecture one. Pdf
PPTX
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
Understanding_Digital_Forensics_Presentation.pptx
The AUB Centre for AI in Media Proposal.docx
Peak of Data & AI Encore- AI for Metadata and Smarter Workflows
Review of recent advances in non-invasive hemoglobin estimation
breach-and-attack-simulation-cybersecurity-india-chennai-defenderrabbit-2025....
20250228 LYD VKU AI Blended-Learning.pptx
Network Security Unit 5.pdf for BCA BBA.
Per capita expenditure prediction using model stacking based on satellite ima...
GDG Cloud Iasi [PUBLIC] Florian Blaga - Unveiling the Evolution of Cybersecur...
“AI and Expert System Decision Support & Business Intelligence Systems”
Dropbox Q2 2025 Financial Results & Investor Presentation
Mobile App Security Testing_ A Comprehensive Guide.pdf
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Effective Security Operations Center (SOC) A Modern, Strategic, and Threat-In...
[발표본] 너의 과제는 클라우드에 있어_KTDS_김동현_20250524.pdf
Empathic Computing: Creating Shared Understanding
Advanced Soft Computing BINUS July 2025.pdf
Advanced methodologies resolving dimensionality complications for autism neur...
Electronic commerce courselecture one. Pdf
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy

Why We Need Architects (and Architecture) on Agile Projects

  • 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
  • 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.”
  • 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

Editor's Notes

  • #4: Get something from skills for agile designers?Agile design values?Agile Developer values?
  • #20: Incremental development means that different parts of a software project are continuously integrated into the whole, instead of a monolithic approach where all the different parts are assembled in one or a few milestones of the project.Iterative means that once a first version of a component is complete it is tested, reviewed and the results are almost immediately transformed into a new version (iteration) of this component.So as a first result: iterative development doesn&apos;t need to be incremental and vice versa, but these methods are a good fit.Agile development aims to reduce massive planning overhead in software projects to allow fast reactions to change e.g. in customer wishes. Incremental and iterative development are almost always part of an agile development strategy. There are several approaches to Agile development (e.g. scrum).
  • #25: I would go further to say, develop the tools, tooling, and mechanisms that instrument the rates of change you need. And, you encapsulate the parts that do vary so that they don’t leak out/effect other areas. This may mean that if you have highly changing software you architect ways that drive this change via mechanisms that are “easier” to change than others—data driven techniques, meta techniques, whatever…. Fast redeploy/tested code…all are ways
  • #31: Landing ZoneA small section of a deck that a pilot must touch down in to land the aircraft safely
  • #38: And, based on exper, maybe we need to recalibarate the lz based on arch decisions/costs to achieve them.Drives ongoing tradeoffs, decisions, and risk mitigation investments
  • #41: Explore potential pathsTalk to othersShort experimentsExtrapolateConclude based on experience, intelligence gathered &amp; intuition
  • #51: May or may not be a person designated as “architect”, but a role taken on by those who care about the system architecture
  • #62: Because most systems that are successful have architectures that successfully evolve, too…
  • #65: The architecture can (and may) need to evolve.