Architecture in an Agile World

©2012 Improving Enterprises, Inc. www.synerzip.com
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

5
What is Software Architecture?

6
Business Goals
What business goals could affect our
Architectural decisions?

7
Non-Functional Requirements
Usability
Scalability
Portability
Maintainability
Availability
Accessibility
Supportability
Security
Performance
Cost
Legal
Cultural
...

Does it compare to building this?
House

… or this?
???

Level of Complexity
Simple
Everything is known
Complicated
More is known than unknown
Complex
More is unknown than known
Chaotic
Very little is know
Source: Ralph Stacey, University of
Hertfordshire

Empirical vs Defined Processes
Defined Empirical
Predict the Future
Initial information and assumptions
are valid throughout the planning
horizon.
Adapt to the Future
Frequent inspection/adaptation
rather than predictive planning
Examples:
assembly line, construction,
accounting, orchestra
Examples:
sales, marketing, creative writing,
band
Plan Do P D P D P D P D

•Business Case
• Financing
• Scope & Approach
• Contracts
• Initial Release Plan
• Assemble Team
Sprint Planning
1 day
• Acceptance
Defined
• Team commits
• Tasks created
Product Owner
establishes vision and
prioritizes Product Backlog
Sprint
1 to 4 weeks
Team (BA, QA, Dev, etc.) creates
and estimates Sprint Backlog (tasks)
Releasable
Increment
Daily Scrum
< 15 minutes
Burn down
Sprint Review
1/2 day
Sprint Retrospective
1/2 day
Burn up
velocity
Scrum

BigDUF or LittleDUF?
Monday Tuesday Wednesday Thursday Friday
Sprint
1
Sprint
2
Sprint Planning
Sprint Planning
LDUF
PB Grooming
PB Creation
PB Sizing
Release Planning
PB Grooming
Retrospective
Sprint Review
Retrospective
Sprint Review

14
Usability
Scalability
Portability
Maintainability
Availability
Accessibility
Supportability
Security
Performance
Cost
Legal
Cultural
...

15
Usability
Scalability
Portability
Maintainability
Availability
Accessibility
Supportability
Security
Performance
Cost
Legal
Cultural
...
Captured as:
• Acceptance
Criteria
• Definition of
Done
• Stories

Sprint Capacity over Time

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

Most Important Architecture Goal?
Maintainability

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
certification course

Yuck.
*From Scrum.org’s

How do you get out of debt?
*From Scrum.org’s
1. Stop creating debt
2. Make a small payment each Sprint
3. Repeat from 2

Sprint Planning
1 day
• Acceptance
Defined
• Team commits
• Tasks created
Product Owner
establishes vision and
prioritizes Product Backlog
Sprint
1 to 4 weeks
Team (BA, QA, Dev, etc.) creates
and estimates Sprint Backlog (tasks)
Releasable
Increment
Daily Scrum
< 15 minutes
Sprint Retrospective
1/2 day
Sprint Review
1/2 day
Done Task?
Unit Tested
Code Reviewed
Checked-in
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?
Definition of Done

Paying off Debt
Feature
Name
Scheduled Active 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 Active 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

Core Aspects of Good Design
Good
Design
✓ Low Coupling
✓ High Cohesion

Coupling vs. Cohesion

Core Aspects of Bad Design
.
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➔Bad
Design

Refactoring
✓Good
Design
➔XBad
Design
Refactoring
to / towards / away from
Design
Patterns
Bad
Smells

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

Vertical Teams
Business
Presentation
DBPersistence
TEAM 1 TEAM 2 TEAM 3 TEAM 4

Vertical Features
Business
Presentation
DBPersistence
TEAM 1 TEAM 2 TEAM 3 TEAM 4
Features Features Features Features

Ideal Team Composition
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

Realistic Team Composition
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
participate throughout the sprint.
2. REALISTIC: Specialists service multiple teams
and participate as needed.
3. WORST CASE: Specialists do not participate 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)
Solution Architect
(advisory & governance)
Application Architect
(on teams)

Where to Plug In?
Monday Tuesday Wednesday Thursday Friday
Sprint
1
Sprint
2
Sprint Planning
Sprint Planning
LDUF
PB Grooming
PB Creation
PB Sizing
Release Planning
PB Grooming
Retrospective
Sprint Review
Retrospective
Sprint Review

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 foundations that
embrace change
Today’s technologies
and enterprise
frameworks give us
this flexibility
We just need to
take advantage
of them.

Questions?
Don McGreal
@donmcgreal

Thank You!
Don McGreal
@donmcgreal

Questions?
www.synerzip.com
Hemant Elhence
hemant@synerzip.com
469.322.0349

©2012 Improving Enterprises, Inc. www.synerzip.comConfidential
Synerzip in a Nut-shell
1. Software product development partner for small/mid-
sized technology companies
Exclusive focus on small/mid-sized technology companies, typically
venture-backed companies in growth phase
By definition, all Synerzip work is the IP of its respective clients
Deep experience in full SDLC – design, dev, QA/testing, deployment
2. Dedicated team of high caliber software professionals
for each client
Seamlessly extends client’s local team, offering full transparency
Stable teams with very low turn-over
NOT just “staff augmentation”, but provide full mgmt support
3. Actually reduces risk of development/delivery
Experienced team - uses appropriate level of engineering discipline
Practices Agile development – responsive, yet disciplined
4. Reduces cost – dual-shore team, 50% cost advantage
5. Offers long term flexibility – allows (facilitates) taking
offshore team captive – aka “BOT” option

Our Clients

©2012 Improving Enterprises, Inc. www.synerzip.com60
Call Us for a Free Consultation!
www.synerzip.com
Hemant Elhence
hemant@synerzip.com
469.322.0349
Thanks!

Architecture in an Agile World

Recommended

Recommended

More Related Content

Similar to Architecture in an Agile World

Similar to Architecture in an Agile World (20)

More from Synerzip

More from Synerzip (20)

Recently uploaded

Recently uploaded (20)

Architecture in an Agile World