Með tilkomu agile hugbúnaðargerðar er hætt á að forritarar fórni hlutum sem voru sjálfsagðir í aðferðum eins og Waterfall og RUP en eiga fullt erindi í agile þó svo með öðrum hætti. Má nefna skjölun, en margir misskildu agile á þann veg að ekkert þarf að skjala. Skjölun er nauðsynleg þótt hún sé með örðum hætti, en svo er einnig með architecture. Í agile er nauðsynlegt að huga vel að architecture en einnig að átta sig hvað það er sem við skilgreinum sem architecture og hvað ekki. Í þessum fyrirlestri er fjallað um architecture og agile og hvernig þessir hlutir geta fallið vel saman. Með aglie teymum flyst mikið af ábyrgð á architecture til teymanna, en samt þarf að vera einhver sameinlegur strúktúr og sýn.

1. Lecture 22
Architecture and Agile

2. Agenda
 Software Development Evolution
 Architecture in Agile environment
– Conflicts
– Boundaries for xDD
 Moving from Big Up-front Design
 Quantifying Risk
– Risk Storming
– Mitigation Strategies
 Just Enough Design
 Introducing Architecture

3. Reading
 Brown 62 - 67

4. Software Development
Waterfall RAD RUP Agile
70s, 80s
Sequential
Process
All design front-up
Process heavy
Rapid Application
Development
80s, 90s
Rational Unified Process
90s, 00s 00s, 10s
Rapid Prototyping
Prototype not plan
Process Light
Framework for
iterative development
Can be process heavy
Iterative and
incremental
Can be process light

5. Architecture in Agile Environment
Architecture
is about
structure
and vision
Agile is
about
flexibility
Is this not a Conflict?

6. Conflict #1 – Team Structure
Traditionally a Chief Software
Architecture defines the architecture for
all to follow – large design documents
Chief Software Architect in his Ivory
Tower
Big Upfront
Specifications

7. Conflict #1 – Team Structure
In Agile, teams are small, self-sufficient
with minimum overhead
But we still Architecture, don’t we?

8. Conflict #1 – Team Structure
In Agile, teams are small, self-sufficient
with minimum overhead
Software
Architecture SA
SA
SA
SA
SA
Team members form an
Architecture Group

9. Conflict #2 – Process and Output
Agile teams favor responding to change
over following a plan – no upfront design
But we still need Architecture, don’t we?

10. Boundaries for xDD
Test-, Behavioral-, Domain, and Resume
Driven Development are not substitutes for
Architecture
The architecture is about putting
boundaries in place

11. Boundaries for xDD
We must define Architecture and the
architectural drivers:
Functional Requirements
Quality Attributes
Constraints
Principles
Requirements drive architecture
User stories, acceptance tests, etc
Non-functional Requirements
Scalability, performance, security, etc
Real-world constraints
Approved technology, people, standards etc.
Principles – Rules for consistency
Layering strategy, separation of concerns, patterns etc

12. Moving from Big Up-front Design
Architecture is about stuff that hard or
costly to to change
Core technology choices
Overall High Level Structure
Architecture is about defining high-level
structure and put a vision in place
Agile teams need a framework and
boundaries – and should be trusted to do
the rest

13. Quantifying Risk
Risk management is crucial in agile
Not addressing Risk can kill projects
Risk can be managed by separating
probability from impact
Probability: How likely is this to happen?
Impact: What is the negative impact if this occurs?

14. Quantifying Risk
Prioritizing risk
Use scale 1-5 (5 high)
for probability and
impact, then multiply

15. Risk Storming
Process for identifying Risk
Step 1: Draw some architecture diagrams
Step 2: Identify the risks individually
Step 3: Converge risk on the diagrams
Step 4: Prioritize the risk

16. Risk Storming
Example risks:
Data formats from 3rd party system change
External components don’t work
External systems are not available in time
Technical specification is vague
People are not cooperating
Politics in the workplace

17. Mitigation Strategies
What can we do to prevent this or how can
we correct this
Example strategies:
Education
Prototypes
Rework
Alliances, people issues

18. Just Enough Design
We are agile, do we need design?

19. Just Enough Design
The solution is to identify the need for
design and do just that – not to little, not
too much
Structure
Risk
Vision

20. Just Enough Design
The solution is to identify the need for
design and do just that – not to little, not
too much

21. Just Enough Design
1. Structure
• What: understand the structural elements and how they fit
together
• How: Design and decomposition down to containers and
components
2. Risk
• What: Identify and mitigate the highest priorities
• How: Risk storming and concrete experiments
3. Vision
• What: Create and communicate a vision for the team to work with
• How: Context, Container and component diagrams

22. Introducing Software Architecture
Architecture is necessary in software
development
It needs to be communicated and
accessible
People have limited time and a usually
interested in other things

23. Introducing Software Architecture
Practical suggestions
1. Educate People
2. Talk about Architecture in retrospectives
3. Definition of Done
4. Allocate the architecture role to someone
5. Architecture katas

24. Summary
 Agile is important today
– Architecture needs to fit the methodology
– Conflicts
– Boundaries for xDD
 Moving from Big Up-front Design
 Quantifying Risk
– Risk Storming
– Mitigation Strategies
 Just Enough Design
 Introducing Architecture