agile software architecture 2016
TRANSCRIPT
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?
agilenorth.org/2016-conference/ Chris F Carroll
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 defines 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-benefit-analyse calculate quantify validate budget
}everything
the value-add of software architecture
Software Architecture claims
“to enable reasoning about the quality attributes
of software systems”
Why software architecture?
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
Why software architecture?
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
Software qualities, agile style
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
Software qualities, agile style
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”
Modifiability, Extensibility, Evolvability
Modifiability & 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?
Why Software Architecture ? because
it enables reasoning about the quality attributes
of a software system
the “Value-Add”
agilenorth.org/2016-conference/ Chris F Carroll
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 definitions
“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.files.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.files.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.files.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 …
publicstaticvoidMain(){System.Console.WriteLine("Hello,World!");}
Software without architecture? …means someone did architecture
publicstaticvoidMain(){System.Console.WriteLine("Hello,World!");}
Fairbanks, 2010
Howabout
“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 Unified Process & OpenUP http://epf.eclipse.org/wikis/openup/
Unified Process proposed that on a greenfield project, the highest risk is usually the architecture
On paperCoded & on hardware
Skeleton is the first deliverable grow the functionality on it
also called “Spike”
or “Tracer Bullet”
Hence, the Skeleton Architecture
Skeleton is the first 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 Coplien & Bjørnvig's Partitioning Steps
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.”
Lean Architecture for Agile Software Coplien & Bjørnvig's Partitioning Steps
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
Lean Architecture for Agile Software Coplien & Bjørnvig's Partitioning Steps
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 partitioningRespect 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
functionality goes in here
grand central terminal
two metaphors, but the same idea make space for functionality
define 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 middleAp
plica
tion
Laye
rFo
r Use
Cas
es
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
“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
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 different to layers
in summary, three principles… Chris F Carroll
Agile Software Architecture
prioritise your software qualities define, measure and test
Don’t Fight Conway’s Law
Partition for Domains, and for Autonomous Teams
Respect The Domains
Make Spaces for functionality
http://cafe-encounter.net @chrisfcarroll
Agile Software Architecture