architecture in an agile world

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!