Post on 20-Jun-2015
description
Architecture)in)an))Agile)World)
don.mcgreal@ImprovingEnterprises.com
Don McGreal
@donmcgreal
linkedin.com/in/donmcgreal!
Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns
What'is'So/ware'Architecture?'
Business'Goals'
• What business goals could affect our Architectural decisions?
Non9Func;onal'Requirements'
" Usability'" Scalability'" Portability'" Maintainability'" Availability'" Accessibility'" Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...
Does'it'compare'to'building'this?'
'
• Standard'House'
'
…'or'this?'
'
• House???''
…'or'this?'
'
• ???''
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'
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'
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)
Sprint)Review 1/2)day)
Sprint)Retrospec@ve 1/2)day)
Burn)up)
velocity)
Scrum'
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)
Retrospec@ve)Sprint)Review)
Retrospec@ve)Sprint)Review)
Non9Func;onal'Requirements'
" Usability'" Scalability'" Portability'" Maintainability'" Availability'" Accessibility'" Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...
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'
Sprint'Capacity'over'Time'
0'
10'
20'
30'
40'
50'
60'
70'
80'
90'
100'
Infrastructure'/'
Architecture'
Func;onality'
…'but'one'is'different'
" Usability " Scalability " Portability " Maintainability " Availability " Accessibility " Supportability
" Security
" Performance
" Cost
" Legal
" Cultural
" ...
Most'Important'Architecture'Goal?'
• Maintainability
Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns
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'
Yuck.'
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'
Stabiliza;on:'Plan'vs.'Reality'
Plan"
RC P P P D D D RC P P P D D D RC P P P D D D Release
Actual""
RC P P P D D D RC P P P D D D RC P P P D D D Release Stabilization"
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'
How'do'you'get'out'of'debt?'
*From'Scrum.org’s'
Professional'Scrum'Master'
cer;fica;on'course'
1. Stop'crea;ng'debt'
2. Make'a'small'payment'each'Sprint'
3. Repeat'from'2'
• 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)
Sprint)Review 1/2)day)
Sprint)Retrospec@ve 1/2)day)
Burn)up)
velocity)
Sprint)Planning) 1)day)
• Acceptance))Defined)
• Team)commits)• Tasks)created)
Product)Owner) establishes)vision)and)
priori@zes)Product)Backlog)
Sprint 1)to)4)weeks)
Team)(BA,)QA,)Dev,)etc.))creates)and)es@mates)Sprint)Backlog)(tasks)'
Releasable)Increment)
Daily)Scrum <)15)minutes)
Sprint)Retrospec@ve 1/2)day)
Sprint)Review 1/2)day)
Done)Task?)Unit'Tested'
Code'Reviewed'
Checked9in'
others?'
'
Done)Feature?)Acceptance'Tested'
On'Test'Server'
Performance'Tested'
others?'
'
' Sprint)Review 1/2)day)
Done)Sprint?)Versioned'
In'UAT'
Integrated'
others?'
'
'
Releasable)Increment)
Done)Release?)Compliance'
Labeled'
Training'
others?'
'
'
Defini;on'of'
Done'
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'
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)'
Design Patterns !=
Good Design
What'is'a'PaNern?'
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."
Core'Aspects'of'Good'Design'
✓Good Design
✓ Low Coupling
✓ High Cohesion
Coupling'vs.'Cohesion'
Core'Aspects'of'Bad'Design'
X Bad Design
• Duplication
• Ambiguity
• Complexity
Bad'Smells'
The Bloaters
The OO Abusers
The Change Preventers
The Dispensables
The Couplers
Long Method, Large Class, Data Clumps
Type Attribute, State Attribute, Indecent Exposure
Lazy Class, Dead Code, Data Class
Feature Envy, Message Chains, Middleman
Divergent Change, Shotgun Surgery, Non-localized Logic
How'do'we'get'there?'
✓Good Design ➔ X Bad
Design
Refactoring'
✓ Good Design ➔ X Bad
Design
Refactoring to / towards / away from
Design Patterns
Bad Smells
Refactoring'
✓ Good Design ➔ X
Refactoring to / towards / away from
Design Patterns
Bad Smells
Encapsulate Field!Extract Method !Generalize Type!Pull Up!Push Down!Rename Method !...!
Bad Design
Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns
Ver;cal'Teams'
Business
Presentation
DB Persistence
TEAM)1) TEAM)2) TEAM)3) TEAM)4)
Ver;cal'Features'
Business
Presentation
DB Persistence
TEAM)1) TEAM)2) TEAM)3) TEAM)4)
Features' Features' Features' Features'
Ideal'Team'Composi;on'VP'
QA''Manager'
QA'
QA'
QA'
Product'Manager'
Dev'
Dev'
Dev'
Dev'
Architecture'Manager'
Architect'
Architect'
Architect'
DBA''Manager'
DBA'
DBA'
Team)A)
Team)B)
Realis;c'Team'Composi;on'VP'
QA''Manager'
QA'
QA'
QA'
Product'Manager'
Dev'
Dev'
Dev'
Dev'
Architecture'Manager'
Architect'
Architect'
Architect'
DBA''Manager'
DBA'
DBA'
Team)A)
Team)B)What'
now?'
What'
now?'
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.'
Architect'Roles'• Enterprise'Architect''(policies'&'standards)'
• Infrastructure'Architect''(systems'&'network'design)'
• Solu;on'Architect''(advisory'&'governance)''
• Applica;on'Architect''(on'teams)'
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)
Retrospec@ve)Sprint)Review)
Retrospec@ve)Sprint)Review)
Agenda'
! Agile and Architecture
! Reducing Technical Risks
! Team Makeup & Roles
! Architecture Anti-Patterns
Logic'in'Wrong'Layer'
Think about what would need to change in other layers if one was swapped out or modified.
Business
Presentation
Persistence
Controller Façade
Integration
S h a r e d
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.
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.
Threading'
Do your homework!
✓ Typically not necessary
✓ Adds massive complexity
✓ Hard to maintain, test, and debug
✓ Rely on the application frameworks threads
Caching'
Do your homework!
✓ Do you even need a cache? ✓ Can you keep everything in memory?
✓ Rely on persistence framework’s caching
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.
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.
So, to sum up…
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.)
Thank You!
don.mcgreal@ImprovingEnterprises.com
Don McGreal
@donmcgreal
linkedin.com/in/donmcgreal!
Questions?
don.mcgreal@ImprovingEnterprises.com
Don McGreal
@donmcgreal
linkedin.com/in/donmcgreal!