We now acknowledge that complete upfront requirements is an impossible mission. Agile approaches have emerged as a way to manage the creation of systems that can never be completely defined and are certain to change. But what about architecture and design for these systems? How much is the right amount? How do you plan for emergent design? What is the architect's role on an agile project? Topics include: - Role of the agile architect - Agile design - Keeping change easy - Reducing technical risks - Capturing non-functional and technical requirements and constraints - Dealing with technical debt - Addressing architectural concerns within the Scrum framework - Tests – They're not just for finding bugs - Architecture anti-patterns

1. Architecture)in)an))
Agile)World)
Don McGreal
don.mcgreal@ImprovingEnterprises.com
@donmcgreal
linkedin.com/in/donmcgreal!

2. Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns

3. What'is'So/ware'Architecture?'

4. Business'Goals'
• What business goals could affect our
Architectural decisions?

5. Non9Func;onal'Requirements'
" Usability'
" Scalability'
" Portability'
" Maintainability'
" Availability'
" Accessibility'
" Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...

6. Does'it'compare'to'building'this?'
'
• Standard'
House'
'

7. …'or'this?'
'
• House???'
'

8. …'or'this?'
'
• ???'
'

9. Level'of'Complexity'
Simple'
Everything'is'known'
Complicated'
More'is'known'than'unknown'
Complex'
More'is'unknown'than'known'
Chao;c'
Very'liNle'is'know'
Source:'Ralph'Stacey,'University'of'HerRordshire'

10. Empirical'vs'Defined'Processes'
Defined) Empirical)
Predict'the'Future'
Ini;al'informa;on'and'assump;ons'are'
valid'throughout'the'planning'horizon.'
'
Adapt'to'the'Future'
Frequent'inspec;on/adapta;on'rather'
than'predic;ve'planning'
'
Examples:''
assembly'line,'construc;on,'accoun;ng,'
orchestra'
Examples:''
sales,'marke;ng,'crea;ve'wri;ng,'band'
Plan' Do' P' D' P' D' P' D' P' D'

11. Team)(BA,)QA,)Dev,)etc.))creates)
and)es@mates)Sprint)Backlog)(tasks)'
• Business)Case)
• Financing)
• Scope)&)Approach)
• Contracts)
• Ini@al)Release)Plan)
• Assemble)Team)
Sprint)Planning)
1)day)
• Acceptance))
Defined)
• Team)commits)
• Tasks)created)
Product)Owner)
establishes)vision)and)
priori@zes)Product)Backlog)
Sprint
1)to)4)weeks)
Releasable)
Increment)
Daily)Scrum
<)15)minutes)
Burn)down)
Scrum'
Sprint)Review
1/2)day)
Sprint)Retrospec@ve
1/2)day)
Burn)up)
velocity)

12. BigDUF'or'LiNleDUF?'
Monday) Tuesday) Wednesday) Thursday) Friday)
Sprint))
1)
Sprint))
2)
Sprint)Planning)
Sprint)Planning)
LDUF)
PB)Grooming)
PB)Crea@on)
PB)Sizing)
Release)Planning)
PB)Grooming)
Sprint)Review)
Retrospec@ve)
Sprint)Review)
Retrospec@ve)

13. Non9Func;onal'Requirements'
" Usability'
" Scalability'
" Portability'
" Maintainability'
" Availability'
" Accessibility'
" Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...

14. Non9Func;onal'Requirements'
" Usability'
" Scalability'
" Portability'
" Maintainability'
" Availability'
" Accessibility'
" Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...
Captured'as:'
'
" Acceptance'
Criteria'
" Defini;on'of'
Done'
" User'Stories'

15. Sprint'Capacity'over'Time'
100'
90'
80'
70'
60'
50'
40'
30'
20'
10'
0'
Infrastructure'/'
Architecture'
Func;onality'

16. …'but'one'is'different'
" Usability
" Scalability
" Portability
" Maintainability
" Availability
" Accessibility
" Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...

17. Most'Important'Architecture'Goal?'
• Maintainability

18. Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns

19. Technical'Debt'in'an'Unhealthy'Team'
Time'available'for'
new'feature'
development'
Time'struggling'with''
complexity'and'debt'
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'

20. Yuck.'
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'

21. Stabiliza;on:'Plan'vs.'Reality'
Plan"
P D P D P D RC P D P D P D RC P D P D P D RC Release
Actual"
"
P D P D P D RC P D P D P D RC P D P D P D RC Stabilization"Release
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'

22. How'do'you'get'out'of'debt?'
1. Stop'crea;ng'debt'
2. Make'a'small'payment'each'Sprint'
3. Repeat'from'2'
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'

23. • Business)Case)
• Financing)
• Scope)&)Approach)
• Contracts)
• Ini@al)Release)Plan)
• Assemble)Team)
Sprint)Planning)
1)day)
• Acceptance))
Defined)
• Team)commits)
• Tasks)created)
Product)Owner)
establishes)vision)and)
priori@zes)Product)Backlog)
Sprint
1)to)4)weeks)
Daily)Scrum
<)15)minutes)
Burn)down)
Defini;on'of'
Sprint)Review
1/2)day)
Sprint)Retrospec@ve
1/2)day)
Burn)up)
Done)Release?)
Compliance'
velocity)
Team)(BA,)QA,)Dev,)etc.))creates)
and)es@mates)Sprint)Backlog)(tasks)'
Sprint)Review
1/2)day)
Done)Task?)
Unit'Tested'
Code'Reviewed'
Checked9in'
others?'
'
Done)Feature?)
Acceptance'Tested'
On'Test'Server'
Performance'Tested'
others?'
'
' Done)Sprint?)
Versioned'
In'UAT'
Integrated'
others?'
'
'
Labeled'
Training'
others?'
'
'
Releasable)
Increment)
Done'

24. Paying'off'Debt'
Feature))Name) Scheduled) Ac@ve) Blocked) Closed)
'
Feature''1'
Task1.4' Task1.2'
'
Task1.3' Task1.1'
Feature''2'
'
Task2.3' Task2.1'
Task2.2'
Feature''3' Task3.3' Task3.1'
Task3.2'
Task3.4'

25. Paying'off'Debt'
Feature))Name) Scheduled) Ac@ve) Blocked) Closed)
'
Feature''1'
Task1.4' Task1.2'
'
Task1.3' Task1.1'
Design)Task)
'
Feature''2'
'
Task2.3'
Upgrade)Task)
Task2.1'
Task2.2'
ENGINEERING)&)
MAINTENANCE)
Eng.)Task)1)
Bug)
Eng.)Task)2) Upgrade)Task)
'

26. Design Patterns
!=
Good Design

27. What'is'a'PaNern?'

28. Design'PaNern'Structure'
Pattern Name: A descriptive and unique name that helps in identifying and referring to the pattern."
"
Intent: A description of the goal behind the pattern and the reason for using it."
"
Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used."
"
Structure: A graphical representation of the pattern, such as Class diagrams and Interaction diagrams."
"
Consequences: A description of the results, side effects, and trade offs caused by using the pattern."
"
Implementation: A description of an implementation of the pattern; the solution part of the pattern."
"
Sample Code: An illustration of how the pattern can be used in a programming language"
"
Known Uses: Examples of real usages of the pattern."
"
Related Patterns: Other patterns that have some relationship with the pattern."

29. Core'Aspects'of'Good'Design'
✓✓ Low Coupling
Good
Design
✓ High Cohesion

30. Coupling'vs.'Cohesion'

31. Core'Aspects'of'Bad'Design'
X • Duplication
Bad
Design
• Ambiguity
• Complexity

32. Bad'Smells'
The Bloaters
Long Method, Large Class, Data Clumps
The OO Abusers
Type Attribute, State Attribute, Indecent Exposure
The Dispensables
Lazy Class, Dead Code, Data Class
The Couplers
Feature Envy, Message Chains, Middleman
The Change Preventers
Divergent Change, Shotgun Surgery, Non-localized Logic

33. How'do'we'get'there?'
XBad ➔ ✓Good
Design
Design

34. Refactoring'
X ➔ Design Bad
✓ Good
Design
Refactoring
to / towards / away from
Design
Patterns
Bad
Smells

35. Refactoring'
X ➔ Design Refactoring
✓ Good
to / towards / away from
Design
Patterns
Bad
Smells
Encapsulate Field!
Extract Method !
Generalize Type!
Pull Up!
Push Down!
Rename Method !
...!
Bad
Design

36. Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns

37. Ver;cal'Teams'
TEAM)1) TEAM)2) TEAM)3) TEAM)4)
Presentation
Business
PersisDBt ence

38. Ver;cal'Features'
TEAM)1) TEAM)2) TEAM)3) TEAM)4)
Presentation
Features' Features' Features' Features'
Business
PersisDBt ence

39. Ideal'Team'Composi;on'
VP'
QA'
'Manager'
Product'Manager'
QA'
QA'
QA'
Dev'
Dev'
Dev'
Dev'
Architecture'
Manager'
Architect'
Architect'
Architect'
DBA''
Manager'
DBA'
DBA'
Team)A)
Team)B)

40. Realis;c'Team'Composi;on'
VP'
QA'
'Manager'
Product'Manager'
QA'
QA'
QA'
Dev'
Dev'
Dev'
Dev'
Architecture'
Manager'
Architect'
Architect'
Architect'
DBA''
Manager'
DBA'
DBA'
Team)A)
Team)B)
What'
now?'

41. Specialists ''
1. IDEAL:'Specialists'are'dedicated'to'a'team'and'
par;cipate'throughout'the'sprint.'
'
2. REALISTIC:'Specialists'service'mul;ple'teams'and'
par;cipate'as'needed.'
'
3. WORST)CASE:'Specialists'do'not'par;cipate'in'a'
sprint,'but'someone'on'the'team'takes'
responsibility'for'working'with'them.'

42. Architect'Roles'
• Enterprise'Architect''
(policies'&'standards)'
• Infrastructure'Architect''
(systems'&'network'design)'
• Solu;on'Architect''
(advisory'&'governance)''
• Applica;on'Architect''
(on'teams)'

43. Where'to'Plug'In?'
Monday) Tuesday) Wednesday) Thursday) Friday)
Sprint))
1)
Sprint))
2)
Sprint)Planning)
Sprint)Planning)
LDUF)
PB)Grooming)
PB)Crea@on)
PB)Sizing)
Release)Planning)
PB)Grooming)
Sprint)Review)
Retrospec@ve)
Sprint)Review)
Retrospec@ve)

44. Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns

45. Logic'in'Wrong'Layer'
Think about what would need to change in other
layers if one was swapped out or modified.
Presentation
Controller Façade
Business
Integration
Persistence
S
h
a
r
e
d

46. No'Architectural'Vision'
! A single architecture vision should be well
defined and communicated across the team and
organization.
! The vision should map to business goals and
objectives.
! All decisions should be made with this vision in
mind.

47. Swiss'Army'Knife'
! Do not try to anticipate every possible use of the
system and over-design the interfaces - this will
lead to needless complexity.
! Do the simplest thing that works, within
the Architectural Vision.

48. Threading'
Do your homework!
✓ Typically not necessary
✓ Adds massive complexity
✓ Hard to maintain, test, and debug
✓ Rely on the application frameworks
threads

49. Caching'
Do your homework!
✓ Do you even need a cache?
✓ Can you keep everything in memory?
✓ Rely on persistence framework’s caching

50. Ivory'Tower'Architect'
! It is very hard to truly know the best
solutions for design problems if you are
not working (coding) on the project.
! It takes many iterations of a solution
before it finally works - so you can’t
suggest a solution then leave.

51. Custom'Frameworks'
! May seem like a good idea at first. But...
– Who will maintain it?
– Who will upgrade it when it’s depended upon libraries
are upgraded? Java version?
– How long will your new hires need to learn it? Who
will teach them?
! Look for an off-the-shelf solution first.
– You can hire/train people on it easier.
– It will be upgraded for you.

52. So, to sum up…

53. Emergent'Architecture'
Agile'architects'build'
plans'and'founda;ons'
that'embrace'change'
'
Today’s'technologies''
and'enterprise''
frameworks'give'us'
this'flexibility'
We)just)need)to)
take)advantage)of)
them.)

54. Thank You!
Don McGreal
don.mcgreal@ImprovingEnterprises.com
@donmcgreal
linkedin.com/in/donmcgreal!

55. Questions?
Don McGreal
don.mcgreal@ImprovingEnterprises.com
@donmcgreal
linkedin.com/in/donmcgreal!