Agile Software Architecture

http://agilenorth.org/2016-conference Chris F Carroll
Agile Software Architecture

2 things it might mean “agile software architecture” is?
doing the architect’s job
in an “agile” way?
creating a software architecture to
support agile development?
— or —

agilenorth.org/2016-conference/ Chris F Carroll
✤ Software Architecture: Why & What? 
✤ What is different about the (software
quality) requirements in a business
where “agility” is important? 
✤ How do we express those priorities in
architecture, design & code?

Software Architecture : why & what?

the value-add of software architecture
Software Architecture
claims
“to enable reasoning  
about the quality attributes  
of software systems”
Why software architecture?

What is a Quality Attribute?
What does “Reasoning about” mean?
just two questions… The promise of Software Architecture

What is a Quality Attribute? Who deﬁnes quality?
“It’s not what you do, it’s the way that you do it”
affordability, availability, correctness,
deployability,efficiency, evolvability,
extensibility, fault-tolerance, main-
tainability, modifiability, reliability,
resilience, responsiveness, robust-ness,
safety, scalability, securability,
testability, usability, …

What is a Quality Attribute? ISO 25010
“It’s not what you do, it’s the way that you do it”
accessibility, accountability, accuracy, adaptability, administrability,
affordability, agility, auditability, autonomy, availability, compatibility,
composability, configurability, correctness, credibility, customizability,
debugability, degradability, determinability, demonstrability,
dependability, deployability, discoverability, distributability, durability,
effectiveness, efficiency, evolvability, extensibility, failure transparency,
fault-tolerance, fidelity, flexibility, inspectability, installability, integrity,
interchangeability, interoperability, learnability, maintainability,
manageability, mobility, modifiability, modularity, operability,
orthogonality, portability, precision, predictability, process capabilities,
producibility, provability, recoverability, relevance, reliability,
repeatability, reproducibility, resilience, responsiveness, reusability,
robustness, safety, scalability, seamlessness, self-sustainability,
serviceability, supportability, securability, simplicity, stability, standards
compliance, survivability, sustainability, tailorability, testability,
timeliness, traceability, understandability, upgradability, usability

why architecture? because …
“… No-one re-writes a system because of
deficient functionality. It’s always because
of some quality failing – performance or
reliability, usability, or ease of modifiability”

and even to predict“Reasoning” is analytical thinking
estimate
measure
risk-evaluate
account for
cost-beneﬁt-analyse
calculate
quantify
validate
budget
}everything

Abstraction is often the key Which goes faster? It depends…

Abstraction is often the key Maths: Reason by abstraction
220kW
12T

But get the right requirements The cost of change is high
1 60

Many ways to get from A to B …understand your context

the value-add of software architecture
✤ Understand what qualities you need 
✤ Define them precisely, using
abstractions 
✤ Measure & Test

Software qualities, agile style
Reliability / Availability
Story: “Our service should still be available
even if a machine fails”
Acceptance test #1:
Pull the plug. Does the service still work?
ISO 25010

User Stories & Acceptance Tests  
works well as a format to define and
measure software qualities:
Story: “The search should be fast”
Acceptance test #1:
Run 1000 automated searches for each of
the 50 most popular terms. 95% should
return in less than 2 seconds.
ISO 25010

Story: “User accounts should be secure
against brute force attacks”
Acceptance Tests
#1: After 10 incorrect password entries, the
system should refuse even a correct
password for 20 minutes (& show message)
#2 After 21 minutes, a correct password
should work
#3 Even if 10 guesses are from 10 different
IP addresses
ISO 25010

Some Special Software Qualities
Security: Is complicated. Usually analysed as 3
different qualities (“CIA”), applied to specific
Assets (e.g. data and/or systems). Oh and there’s
authenticity, non-repudiation & accountability & …
Scalability: is not, imho, a software quality. But it is
a nearly-magic bullet: one tactic for performance,
reliability/availability & volume/load in one go.
Maintainability/Evolvability: Is often your agile
developers’ favourite concern
for some meaning of “special”

Modiﬁability, Extensibility, Evolvability

Modiﬁability & Extensibility
Quality: Modifiability/Evolvability
Story: A new font format or
output format becomes popular
Acceptance test #1: Using the
new format should require
change to only 1 component and
no interfaces

Load balancing as a tactic for scaling

Load balancing as a tactic for scaling
Quality: Availability (under load)
Story: Lots of users
Acceptance test #1: the system
should support 1000
simultaneous users without loss
of any other quality or function

multiple architectural views each view has its own vocabulary

4+1 (Kruchten, 1995) IBM developerworks

20 years on … “6 + 0 + 1”
Rozanski & Woods, Software Systems Architecture, 2nd ed

Why Software Architecture ?
because
it enables reasoning  
about the quality attributes  
of a software system
the “Value-Add”

Software Architecture : What?

Architecture is ... Bass, Clements, Kazman, 1997-2012
The Software Engineering Institute 
(ca 2001AD) :
“The structure or structures of the
system, which comprise software
elements, the externally visible properties
of those elements, and the relationships
among them.”

Architecture is ... Kruchten, updated 2009
Kruchten 2009  
The Significant Decisions about: 
• the organisation of a software system,
• the selection of the structural elements and their
interfaces by which the system is composed together
with their behaviour as specified in the collaboration
among those elements,
• the composition of these elements into progressively
larger subsystems,the architectural style that guides
this organisation, these elements and their interfaces,
their collaborations, and their composition

architecture has design decisions
http://www.enterpriseintegrationpatterns.com/gregor.html

What is “The Architecture” of a system? rough cut deﬁnitions
“the fundamental structures or
organisation of your code”
“all the rules & design decisions you have
get right up-front, because they are too
expensive to change later.”

“Shearing
layers” views a
building as
components that
evolve in
different
timescales.
 
Frank Duffy:
“Our basic
argument is that
there isn't any
such thing as a
building.
A building
properly
conceived is
several layers of
longevity of built
components.”lower shearing layers are too expensive to change

Agile
Software
Architecture
photo: http://d.lib.ncsu.edu ua023_025 copyright not known

Agile vs Architecture
Destined to Fight?
Individuals & interactions
over processes and tools
Working software
vs comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
ITABOK
ISO 42010
40 years of experience!

Agile & Architecture
Common Priorities
“Our highest priority is to satisfy the customer ...”
ISO42010
Systems & Software
Engineering —
Architecture Description

http://agilemanifesto.org together with /principles.html
Manifesto for Agile Software Development
We are uncovering better ways of developing 
software by doing it and helping others do it. 
Through this work we have come to value:
Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan 
That is, while there is value in the items on the  
right, we value the items on the left more.

Manifesto for Agile Software Development
We are uncovering better ways of developing 
software by doing it and helping others do it. 
Through this work we have come to value:
Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan 
That is, while there is value in the items on the  
right, we value the items on the left more.
learning through doing together
CONTINUOUS LEARNING
RELATIONSHIPS
together with /principles.html
FOCUS ON THE GOAL

Cargo Cult Agile “the outward form, but not the power”

Cockburn’s “Heart of Agile” alistair.cockburn.us/HeartOfAgile

We
don’t need
no stinkin’
architecture

The Architect vs. the Agile Team
Threats
“The chief measure of progress is working
software” so what value are you adding?
“Your up-front design won’t solve our actual
problems or help us respond to change”

!
Story of a failure
!  Large re-engineering of
a complex distributed
world-wide system;
2 millions LOC in C,
C++, Cobol and VB
!  Multiple sites, dozens of data repositories,
hundreds of users, 24 hours operation, mission-
critical ($billions)
!  xP+Scrum, 1-week iterations, 30 then up to 50
developers
!  Rapid progress, early success, features are
demo-able
!  Direct access to customer , etc.
!  A poster project for scalable agile development
https://pkruchten.ﬁles.wordpress.com/2009/07/kruchten-090608-agile-architecture-usc.pdf P Kruchten 2009

Hitting the wall
!  After 4 ½ months, difficulties
to keep with the 1-week
iterations
!  Refactoring takes longer
than one iteration
!  Scrap and rework ratio
increases dramatically
!  No externally visible progress anymore
!  Iterations stretched to 3 weeks
!  Staff turn-over increases; Project comes to a halt
!  Lots of code, no clear architecture, no obvious way
forward
https://pkruchten.ﬁles.wordpress.com/2009/07/kruchten-090608-agile-architecture-usc.pdf P Kruchten 2009

how much architecture you need depends on what you are building

depends on what you are building

Software without architecture? P.S. option 1 is a lie
Two options for doing software without
doing architecture:
1) Build something very small and simple 
– or – 
2) Rely on someone else’s architecture

Software without architecture? Simple software …
public static void Main()
{
System.Console.WriteLine("Hello, World!");
}

Software without architecture? …means someone did architecture
public static void Main()
{
System.Console.WriteLine("Hello, World!");
}

Fairbanks, 2010
How 
about 
“Just Enough”
Architecture?
enough to cover your risk

Fairbanks, 2010Software Quality Risk of Failure
1) Identify and prioritise risks
2) Select and apply a set of architecture
techniques
3) Evaluate risk reduction
http://static1.1.sqspcdn.com/static/f/702523/9359219/1289413590470/201011-Fairbanks.pdf

how much architecture you need depends on how much RISK you have

architecture & iterative delivery “Risk Driven Development”
The Fairbanks’ Quick Test:
☛ Are your risks written down?

Rational Uniﬁed Process & OpenUP http://epf.eclipse.org/wikis/openup/
Unified Process proposed that on a
greenfield project, the highest risk is
usually the architecture
On paper
Coded & on hardware

Skeleton is the ﬁrst deliverable grow the functionality on it
also
called
“Spike”
or
“Tracer
Bullet”
Hence, the Skeleton Architecture

Skeleton is the ﬁrst deliverable but identify where functionality will go
The Agile Growable Walking Skeleton
identify
WHERE
the muscle
will go

Partitioning for Agile Development http://epf.eclipse.org/wikis/openup/
How do you make a skeleton “growable”?
☛ Architectures have a hammer for this
kind of problem, before which
everything is a nail; and the name of
this hammer shall be called, 
 
“Partition the System”

Just
the right
architecture
“building software as if people mattered”

Coplien & Bjørnvig, 2010
• The right architecture
enables  
rapid agile
development.
• “Lean” means thinking
ahead

Lean Architecture for Agile Software:
Coplien & Bjørnvig's Partitioning Steps
An example of 
“Partition by rate of
change”
 
The domain is stable,  
sometimes over
centuries!
 
The functionality is
volatile, and
requirements can
change daily

get the domain right
good  
old- 
fashioned
OO
“Respect
the
Domain”

Domain Driven Design means…
☛ Care more about the business (domain)
you are targeting than the technology
☛ If the domain is complex, model it
accurately & don’t stop refining and
correcting the model
☛ Ubiquitous Language: the same
vocabulary everywhere
☛ Bounded Context: Models, like words,
only have meaning in a context
https://www.infoq.com/interviews/domain-driven-design-eric-evans

Lean Architecture for Agile Software
2) Partition to maximise the autonomy of self-
organising teams
• Agile organisations organise by teams
• You can't fight Conway’s Law 
“Organisations which design systems ... are constrained to
produce designs which are copies of the communication
structures of those organisations”
☛ Let the human considerations drive the partitioning, with
software engineering concerns secondary

Implications of Conway’s law dependencies: code & people
Your architecture
will follow your
teams.
If your teams are
organised in
layers like this,
then
 
(whatever you try
to make it)
 
your architecture
will look like this
too.

Layers means dependencies dependencies: code & people
If teams  
match layers…  
dependencies
go outside the
team… 
 
no team is ever
able to deliver
easily

match teams to business domain rather than skill-oriented teams
http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/
Don’t fight Conway’s law. The law will win.
But
a team 
that can
cover all
the bases  
(& layers!) 
can deliver
indepen-
dently

principles behind the agile manifesto agilemanifesto.org/principles.html
Autonomous, Self Organising Teams
“Build projects around
motivated people.  
Give them the environment
and support they need,  
and trust them to get the job
done.”
“The best architectures,
requirements, and designs  
emerge from self-organizing
teams.”

2) Partition to maximise
the autonomy of self-
organising teams
• Enable teams to deliver
• If you fight Conway’s
Law, the Law will win
☛ Let the human considerations
drive the partitioning, with
software engineering
concerns secondary

each url is almost a separate
business with its own webapp  
(possibly on a separate server)

(microservices not the only way)
https://msdn.microsoft.com/en-us/magazine/mt595752.aspx
Auto- 
nomous  
teams can  
deliver faster
by avoiding
complex
dependencies
Autonomous teams reduce dependencies

Q: how stable are capabilities?
SOA example: services map to business capabilities

Respect Domain Knowledge

• Partition around domains. Domains should in fact match
business structure

• Don't split a domain across geographic locations or
across architectural units

• Re-use existing products & product lines to bolster
domain partitioning

Respect Conway’s Law

• It shouldn't take a village to raise a module.

• 1 team can deliver & change a module fast. 3 teams can’t.

Lean Architecture for Agile Software:
What the system is vs. what the system does
Having “Partitioned
by rate of change”
and created a stable
domain we now deal
with …
 
The functionality is
volatile, and
requirements can
change daily

create Spaces for what-the-system-does tactics for agility
Consider how the architecture for a hotel
enables the functionalities of hotelling, e.g.
eating and sleeping.
☛ It does so by providing spaces within
which the functions can take place
☛ Build a software architecture which
provides a space for things to happen:
the functionality

royal palace, venaria http://www.dreamstime.com/zanico_info

two metaphors, but the same idea make space for functionality

deﬁne a space for what-the-system-does make space for functionality
☛ The growable skeleton has identified
places where a growing series of use-
cases can be added.
☛ The building-creates-spaces idea
provides space within which the
functionality can be coded and easily
changed or even replaced

the application layer can be expandable “layer” does not mean layered architecture
Aim for stability in the
domain model: it only
goes here if it’s true
“forever”
Let the application
layer change &
expand to your
customers’ heart’s
content
UI layer is usually at
least as volatile as
application layer

works even better with hexagons hexagonal architecture
http://www.methodsandtools.com/archive/archive.php?id=97
Domain Model  
in the middle
ApplicationLayerForUseCases
Application  
“Layer”

some thoughts on SOA IANA Service Architect
No change here: still
aiming for a long term
stable domain model
Event handlers
one option for
where you easily
change behaviour
SOA: You may be more
concerned with
business processes than
with Use Cases

agility as a software quality tactics to achieve it
• An early walking skeleton with
identifiable space for use-cases to
expand in
• Match teams to business domain
• Partition by Domain
• Partition for Autonomous Teams
• Architect the spaces for adding
functionality

how many ways can I do it wrong?
how to do it wrong

My Favourite Anti Patterns … let me count the ways
15 Layer Architecture 
Distributed objects for hipsters 
Re-use that isn’t 
Un-autonomous teams 
It’s the wrong abstraction, Grommit!

15 Layer Architecture Step 1 to a 15 layer architecture
Step 1:
Start
with a good
old-fashioned
20th century
3-tier
or layered
application
architecture

Here’s one I made earlier
Step 2:
Jump on
Services
Bandwagon
but don’t
study any
service
oriented
architecture
patterns

distributed objects were popular once there’s a reason they’re history

A SOA reference architecture is very diﬀerent to layers

in summary, three principles… Chris F Carroll

prioritise your software qualities deﬁne, measure and test

Don’t Fight Conway’s Law
Partition for Domains, and for Autonomous Teams
Respect The Domains

http://cafe-encounter.net @chrisfcarroll

Agile Software Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Agile Software Architecture

Similar to Agile Software Architecture (20)

More from Chris F Carroll

More from Chris F Carroll (6)

Recently uploaded

Recently uploaded (20)

Agile Software Architecture