Continuous Delivery of Agile Architecture

Continuous Delivery of Agile Architecture
Integrating Architecture into Agile Delivery
Spiral, by dewailang Source: Flickr
by Brad Appleton
Updated April 2018 (created July 2009)

Continuous Delivery of Agile Architecture:
Integrating Architecture into Agile Delivery
Brad Appleton
Agile Professional Learning Conference 2018

Continuous Delivery of Agile Architecture: Integrating Architecture into AgilityBrad Appleton 3
About the Presenter
Agile/DevOps/Lean Leader & Coach
DevOps/ADLM/SCM Solution Architect
Leading Agile adoption & scaling for teams and organizations
since 2000.
Publications
» Software Configuration Management Patterns (Addison-Wesley, 2002)
» Agile CM Environments article series & blog (AgileConnection &
CMCrossRoads, 2003-2014)
Brad Appleton
Enterprise Agile & DevOps
Engineering Manager
<brad@bradapp.net>
linkedin.com/in/bradappleton

Continuous Delivery of Agile Architecture: Integrating Architecture into AgilityBrad Appleton
Learning Objectives
 Understand the difference between agile (emergent) design and
agile (evolutionary) architecture
 Understand how & where [software] architecture fits in an agile
delivery lifecycle
 Understand the relationship between architecture & organization
(Conway’s Law, and how to exploit it)
 Architecture in enterprise agile frameworks (LeSS, DAD, SAFe)
 Principles & techniques of agile/evolutionary architecture:
 Architectural elements as backlog-items
 Continuously integrating architecture into agile planning & delivery
 Minimum Viable Architecture
 Architecture spikes, iterations & runway
 Last responsible moment
 Architectural dimensions/views/concerns
 Fitness functions
4

What is Software Architecture?
5
The fundamental organization of a [software] system, embodied in its
components, their relationships to each other and the environment,
and the principles governing its design and evolution.
—ANSI/IEEE 1471-2000 [Updated in ISO/IEC/IEEE 42010:2011]
All architecture is design but not all design is architecture. Architecture
represents the significant design decisions that shape a system, where
significant is measured by cost of change. —Grady Booch (2006) “On Design”
The set of design decisions which, if made correctly,
will cause your project to be cancelled. —Eoin Woods
The set of structures needed to reason about the system, which comprises
software elements, relations among them, and properties of both.
—Documenting Software Architectures (2e), Clements et. al. (2010)
Software Architecture is the decisions which are both
important and hard to change. —Martin Fowler

Perceived Tensions Agility versus Architecture
 Architecture = Big Up-Front Design
 Architecture = massive documentation
 Role of architect(s)
 Low perceived or visible value of architecture
Adaptation versus Anticipation
Source: Phillipe Kruchten, Software Architecture and Agile Software Development - An Oxymoron?
6

Agility and Architecture
Agile architecture enables incremental value delivery by
balancing between emergent design & intentional architecture:
Emergent design – Provides the technical basis for a fully evolutionary and
incremental implementation approach. This helps designers respond to
immediate user needs, allowing design to emerge as the system is built
and deployed.
Intentional architecture – A set of purposeful, planned architectural
initiatives, which enhance solution design, performance & usability and
provide guidance for inter-team design and development synchronization.
Source: Dean Leffingwell, Scaling Software Agility
7

Agile Design vs. Agile Architecture
Agile literature talks about “Emergent Design”
The idea is that, rather than all up-front, the design “emerges”
continually during development through the use of Refactoring,
TDD, Continuous Integration, Incremental Design, etc.
8

Emergence and System Dynamics
9

Emergent Design vs. Software Architecture
Software Architecture concerns infrastructure elements
that must exist before you can begin execution.
Since architecture is about things that are hard to change later, it is
difficult to allow an architecture to emerge.
For large projects, this includes partitioning of the system into
functionality/elements that will be allocated to separate teams.
— Neal Ford, Evolutionary Architecture and Emergent Design
10

Architectural Interaction Points
Agile Architecture
Interactions
by James Madison
in IEEE Software
11

Architecture Evolution & Collaboration
12
Source: Dean Leffingwell & Ryan Martens, Principles of Agile Architecture

Conway’s Law
 Often leads to unintended friction points.
13
Any organization that designs a system ... will inevitably
produce a design whose structure is a copy of the
organization’s communication structure. —Melvin Conway
http://bonkersworld.net/organizational-charts

Exploit: The Inverse Conway Maneuver
Recommends evolving your team and organizational structure
to promote your desired architecture. Ideally your technology
architecture will display isomorphism with your business
architecture.
̶ https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
14

Agile Design and Agile Architecture
Agile Design Agile Architecture
Small, Fast & Frequent
Refactorings
Larger, Periodic & Planned
Restructurings
Code Smells Architecture Smells
Clean Code Clean Architecture
MVP, Theme, Epic, Feature,
Story, Task
MVA, Runway, Spike, Enabler,
Tradeoff/Risk/Decision
Emergent Design Evolutionary Architecture
YAGNI & DTSTTCPW Last Responsible Moment (CoD)
Acceptance Tests Fitness Function
15

Architecture in Agile Planning/Backlog
16
Decisions are your (fine-grained) deliverable
Keep a backlog of architecture enablers/concerns
Let economic impact determine your focus
Keep it small
Use “Just Enough” Anticipation
Source: Agile Architecture Roadmapping, SATURN 2016

Continuous Stream of Architecture Decisions
MVP  Runway  Spikes broken down into a continuous
stream of architecture enablers/decisions
17

Scrum and the Architecture Micro-cycle
18

Minimum Viable Architecture (MVA)
Just Enough (Simplest/Smallest) Architecture that …
1. Successfully integrates, starts executing, & gracefully exits
2. Imposes the least amount of duplication, dependencies,
discontinuity, and delays across the delivery lifecycle
3. Expresses the “highest valued” set of stakeholder views &
concerns (continuously validated by metrics/tests)
4. Minimizes the number and size of stakeholder views,
dimensions, structures and concerns
Incrementally Evolves using Validated Learning (Build-
Measure-Learn feedback-loops from Lean Startup):
 Prioritized by highest risk-to-value / learning-value
19

Minimal Viable Architecture (MVA)
20
3. Formulate a
hypothesis
2. Consider
practical
alternatives
1. Determine
top-priority
concern
Architectural
decisions
Architecture
concerns
Build
Measure
Learn
Pivot
Persevere
MVA
Hypothesis

Architectural Spike
An isolated, focused and time-boxed effort to …
 Explore an architectural hypothesis (HDD) or decision
with cross-cutting concerns that has a high degree of
risk/impact to the project
 Implement “just enough” of a skeletal solution
prototype (experiment) to analyze its effects
 Learn what we need to know next in order to
prove/validate what is the most appropriate “fit”
21

Architectural Spike
Source: Ryan Shriver, Agile Engineering for Architects
22

Architectural Spike Examples
 Make a build -vs- buy/reuse decision
 Select a particular technology, supplier, or standard
 Identify the better of two or more different design
alternatives/styles
 Flesh-out the critical portions of a quality-attribute
scenario or an architecturally significant use-case
 Successfully start-up the “null” system (to flesh out
software/system integration issues as early as
possible)
23

Architecture Iteration
An iteration that produces (or refines) specific elements of the
architecture and requirements that are needed prior to any
development iteration
Typically devoted to implementing an architectural spike (or a
small handful of “spike” solutions)
Produces tangible results in the form of a “baseline architectural
prototype”
Enables the evaluation or validation of one or more key “quality
attributes” of the system/architecture
The iteration objectives and results are focused on producing
“working architecture” (which may not always correspond to
customer-visible functionality)
24

From User Stories to Agile Architecture
25
Source: https://www.planetgeek.ch/2010/03/29/from-user-stories-to-architecture/

Evolutionary Architecture
An evolutionary architecture supports
incremental, guided change as a first
principle along multiple dimensions
26

Evolutionary Architecture
Just because we can't allow architecture to emerge
doesn't mean that it can't evolve.
 If we create an initial, flexible architecture and take special
care to not create an irreversible decision, then we can
allow it to evolve over time as new concerns appear.
— Neal Ford, Evolutionary Architecture and Emergent Design
Evolutionary Architecture is an agile practice to
incrementally build, deliver & improve software
architecture throughout the lifecycle of an application.
27

Evolutionary Architecture Principles
28
 Last Responsible Moment
 Remove Needless Variability
 Defer Irreversible Decisions (e.g. using Cost-of-Delay)
 Or Make them Configurable/Pluggable/Replaceable
 Architect for Evolvability
 Sensible breakdown of functionality (modularity & granularity)
 Appropriate coupling (separation of concerns, encapsulate variability)
 Consider data lifecycle & ownership
 Postel’s Law (Robustness Principle)
 Be conservative in what you send, liberal in what you receive
 Only validate what is needed
 Architect for Testability
 Conway’s Law
 Lightweight, Living Documentation

Last Responsible Moment (LRM)
 Remove Needless Variability
 Defer Irreversible Decisions (e.g. using Cost-of-Delay)
 Or Make them Configurable/Pluggable/Replaceable
How can I
make that
decision
reversible?
What can I do to
allow me to
defer that
decision?
Do I need to
make that
decision
now?
What is the
cost of
delaying that
decision?
*sometimes it is “up front”
29
Source: Neal Ford

Evolutionary Architecture Guidelines
Heuristics & Patterns
Prefer Evolvable over Predictable
Architectural Briefings
Lightweight Architecture Decision Records (ADR)
Build Anticorruption Layers
Build Sacrificial Architectures
Strangler Application Pattern
Mitigate External Change
Consumer-Driven Contracts
Prefer Continuous Delivery to Snapshots
Version Services Internally
30

Evolutionary Architecture Cycles
 Architecture evolves through incremental
releases
 Incremental releases represent GENERATIONS
 GENERATIONS = CYCLE TIME
Time elapsed to get a single, simple change into
production (repeatably & reliably)
 Required for Continuous Integration & Delivery
Automate everything
Keep everything in source control
“Done” means released (into production)
Shared release responsibility
Improve continuously
31
Source: Patrick Kua, https://www.slideshare.net/thekua/building-evolutionary-architectures

Generations of Evolutionary Architecture
32
Source: Patrick Kua, https://www.slideshare.net/thekua/building-evolutionary-architectures
6 months
3 months
1 month
daily?

Fitness Functions
Evolutionary architectures are guided by Fitness Functions
“An objective function that measures how close a given
solution fits to a particular goal” [and/or set of constraints]
May be realized by Metrics, Tests, Process
Are Atomic, Holistic & Continuous
33
Source: Neal Ford

Mechanics of Fitness Functions
1. Identify Dimensions Affected by Evolution
 Stakeholder Views / Key Quality Attributes
 Automatability, Testability, Deployability, Monitorability,
Configurability, Evolvability, etc.
2. Define Fitness Function(s) for Each Dimension
3. Use Deployment Pipelines to Automate Fitness Functions
34
Dimensions
Fitness Function Fit
Source: Neal Ford
StakeholderViews/Concerns

Examples of Fitness Functions
 Technical Debt (SQALE)
 NFR/CFR limits & ranges
 Complexity/Coverage/Dependency Ratios & Density
Test to code ratio
CC/LoC
afferent/efferent coupling
DSM
SQALE
Cyclomatic
Complexity
Metrics tree maps
A.Abstractness
I. Instability
35

Fitness Function tools
http://www.campwoodsw.com/sourcemonitor.html
Polymetric
views
https://github.com/softvis/polymetric-views
Code toxicity chart
https://github.com/softvis/toxicity-reloaded
iPlasma
http://loose.upt.ro/reengineering/research/iplasma
X-Ray complexity view
http://xray.inf.usi.ch/
SONARQube
https://www.sonarqube.org/
36
Source: Neal Ford

Continuous Delivery of Agile Architecture: Integrating Architecture into AgilityBrad Appleton 37
https://sketchingscrummaster.com/tag/agile/

Software Architecture in
Enterprise Agile Frameworks

SAFe Architecture Principles
1. Design emerges. Architecture is a collaboration.
2. The bigger the system, the longer the runway.
3. Build the simplest architecture that can possibly
work.
4. When in doubt, code or model it out.
5. They build it. They test it.
6. There is no monopoly on innovation.
7. Implement architectural flow.
Source: https://www.scaledagileframework.com/agile-architecture/
39

Architectural Runway (SAFe)
Provides the technical foundation for future development of
business value.
Contains existing or planned infrastructure sufficient to allow incorporation
of current and near term anticipated requirements without excessive
refactoring/restructuring/rework.
Necessary for an Intentional Architecture that evolves continuously (rather
than emerging during development)
Architectural work is visible, accountable & demonstrable every iteration.
Source: https://www.scaledagileframework.com/agile-architecture/ and .../architectural-runway/
40

Architectural Runway (SAFe)
Continuous build-out and maintenance of new architectural
runway is the responsibility of all mature agile teams.
Failing to do so will cause one of two things to happen (both bad):
1. Release dates will be missed as large scale, just-in-time, in-situ
infrastructure refactoring adds substantial risk to scheduling
2. Failure to address the problem systemically means that the teams will
eventually run out of runway, which means:
 New features cannot be added and …
 The system becomes so brittle/unstable that it has to be rewritten
Source: Dean Leffingwell, Scaling Software Agility
41
Enablers build up the runway
Features consume it
Runway must be continuously maintained
Enablers extend the runway

How much “runway” is sufficient?
How to know how much architecture is enough to begin story
development without significant rework/restructuring?
Identify the key/critical architectural concerns and driving quality
attributes (i.e., an “architecture backlog”)
Devise an initial minimal set of attribute/architecture scenarios (“spikes”)
and their go/no-go criteria
Order them by technical dependency and prioritize by risk
Conduct time-boxed architecture spikes/iterations in
priority+dependency order
At the end of each architecture iteration, re-evaluate the above and
whether or not development iterations can get started.
Source: https://www.scaledagileframework.com/program-and-solution-backlogs/
42

LeSS and Architecture
43
Source: https://less.works/less/technical-excellence/architecture-design.html

1. Think ‘gardening’ over ‘architecting’—Create a culture of living, growing
design
2. Design workshops with agile modeling
3. Just-in-Time (JIT) modeling; vary the abstraction level
4. Design workshops each iteration, in the team rooms
5. Multi-team design workshops for broader design issues
6. Technical leaders teach at workshops
7. Architects and system engineers are regular (feature) team members
8. Question all early architectural decisions as final
9. Don’t comform to outdated architectural decisions
10. Very early, develop a walking skeleton with tracer code
11. Incrementally build ‘vertical’ architectural slices of customer-centric
features
12. Do customer-centric features with major architectural impact first
13. Architects clarify by programming spike solutions
44

14. Don’t let architects hand off to ‘coders’
15. Tiger team conquers then divides
16. SAD workshops at end of “tiger phase”
17. Back up “human infection” with an agile SAD workshop
18. Technical leaders teach during code reviews
19. Don’t wait for approval reviews by experts
20. Design/architecture community of practice
21. Show-and-tell during workshops
22. Component mentors for architectural integrity when shared code
ownership
23. Internal open source with teachers—for tools too
24. Configurable design for customization
25. Use architectural and design patterns
26. Promote a shared pattern vocabulary
45

Disciplined Agile Architecture
46

Disciplined Agile Architecture
47

Appendix: Resources & Links

Building Evolutionary Architectures
 Mechanics
1. Identify Dimensions Affected by Evolution
2. Define Fitness Function(s) for Each Dimension
3. Use Deployment Pipelines to Automate Fitness Functions
 Guidelines for Building
 Remove Needless Variability
 Make Decisions Reversible
 Prefer Evolvable over Predictable
 Build Anticorruption Layers
 Build Sacrificial Architectures
 Mitigate External Change
 Updating Libraries Versus Frameworks
 Prefer Continuous Delivery to Snapshots
 Version Services Internally
 Organizational Factors
 Cross-Functional Teams
 Organized Around Business Capabilities
 Product over Project
 Dealing with External Change
 Connections Between Team Members
49
http://evolutionaryarchitecture.com/

Books
50

Microservices and Architecture
51

Resources: Agile Architecture
 Chris Sterling's book on Architecture in an Agile Organization
 Presentations by Ryan Shriver at theagileengineer.com
 Dean Leffingwell's writings on Agile Architecture
 OOPSLA '09 workshop on "Architecture in an Agile World"
 Software Architecture and Agile Software Development - An Oxymoron? by
Philippe Kruchten
 Agile Architecture - How much is enough?, by Eoin Woods
 The Agile Architect site (including the role of the agile architect)
 Agile Architecting by Erik Philippus
 Scott Ambler's Scaling Agile Development via Architecture
 Lean Software Architecture, Jim Coplien & Gertrud Bjornvig
 Architecture Meets Agility, by Hakan Erdogmus
 Systems Engineering and Architecting Challenges: Application to Agile
Development, by Murray Cantor
52

Resources: Agile Architecture [2]
 https://www.infoq.com/articles/agile-architecture
 https://pgppgp.wordpress.com
 https://resources.sei.cmu.edu/asset_files/Presentation/2016_017_001_454847.pdf
 https://www.infoq.com/news/2014/11/minimum-viable-architecture
 http://www.agilearchitect.org
 http://scs-architecture.org
 http://agilemodeling.com/essays/agileArchitecture.htm
 http://www.disciplinedagiledelivery.com/devops-enterprise-architecture/
 http://wirfs-brock.com/PDFs/PatternsToDevelopAndEvolveArchitecture.pdf
 https://www.slideshare.net/ScottWAmbler/continuous-architecture-and-emergent-design-disciplined-agile-
strategies
 https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
 https://www.scaledagileframework.com/agile-architecture/
 https://less.works/less/technical-excellence/architecture-design.html
 https://sketchingscrummaster.com/tag/agile/
 https://resources.sei.cmu.edu/asset_files/Presentation/2016_017_001_454632.pdf
53

Resources: Evolutionary Architecture
 LRM Principle: Read Delaying Decisions and Decide as Late as Possible
 Neal Ford's series of IBM developerWorks articles on Evolutionary Architecture
and Emergent Design
 http://evolutionaryarchitecture.com/
 https://www.thoughtworks.com/pt/books/building-evolutionary-architectures
 https://www.slideshare.net/ThoughtWorks/neal-ford-emergent-design-and-evolutionary-architecture
 https://www.oreilly.com/ideas/the-evolution-of-evolutionary-architecture-2016
 https://www.infoq.com/news/2016/03/evolutionary-architectures
 https://www.slideshare.net/shawnbutton/patterns-of-evolutionary-architecture
 https://www.slideshare.net/latcraft/evolutionary-software-architecture-why-and-how
 http://nealford.com/downloads/Evolutionary_Architecture_Keynote_by_Neal_Ford.pdf
 https://www.slideshare.net/thekua/building-evolutionary-architectures
 https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture
 https://www.oreilly.com/topics/software-architecture
 https://medium.com/developers-writing/my-take-on-evolutionary-architecture-f761d45e75b9
54

References: Architecture Frameworks (Sw & IT)
 What is your definition of software architecture? SEI-CMU_3854_Jan-2017
 ISO/IEC/IEEE 42010:2011(E), Systems and software engineering – Architectural description
 http://www.iso-architecture.org/ieee-1471/defining-architecture.html
 ISO/IEC/IEEE 1471 Survey of Architecture Frameworks
 https://www.viewpoints-and-perspectives.info/
 SQUID: Software Architecture Framework for Specificying Quality in DevOps – (DOI) (Paper)
(Presentation)
 https://handbookofsoftwarearchitecture.com/
 SASSY: Self Architecting Software Systems -- https://cs.gmu.edu/~menasce/sassy/
 EAM Pattern Catalog V1 (2008)
 Extreme Architecture Framework -- http://extremearchitecture.org/ (A Minimalist IT
Architecture Framework)
 http://www.opengroup.org/content/agile-enterprise-architecture-methodology
 The Open Group - IT4IT Applied – Case Studies for Agile IT4IT (Part 1, Part 2)
 DEF Agile Architecture Framework -- https://agilearchitect.azurewebsites.net/
 Agile Enterprise Architecture -- https://www.agileea.com/
 Enterprise Architecture Proessional Journal -- https://eapj.org/
55

Backup Slides

Other Architecture Terms & Definitions
Term Definition
Architecture
Framework
Conventions, principles and practices for the description of
architectures established within a specific domain of
application and/or community of stakeholders
Architecture
View
Work product expressing the architecture of a system from the
perspective of specific system concerns
Architecture
Viewpoint
Conventions for the construction, interpretation and use of
architecture views to frame specific system concerns
Concern Interest in a system relevant to one or more of its stakeholders.
(Pertains to any influence on a system in its environment,)
Environment System context determining the setting and circumstances of
all influences upon a system (includes developmental,
technological, business, operational, organizational, political,
economic, legal, regulatory, ecological and social.)
Source: ISO/IEC/IEEE 42010:2011(E), Systems and software engineering — Architecture description
57

Source: The Software Architect’s Role in the Digital Age, Hohpe, Ozkaya, et.al., IEEE Software Nov/Dec 2016
Architectural dimensions and the evolution of the software architecture field
58

Architecture First
Source: Grady Booch, Software Architecture
Risk
Time
Risk
resolution
Controlled risk management
Iterative
Waterfall
Risk
59

Architecture as Role Collaboration
Source: Dean Leffingwell & Ryan Martens, Principles of Agile Architecture
60

Agile Architecture Interactions, by James Madison, in IEEE Software
61

Agile Architecture Interactions, by James Madison, in IEEE Software
62

From Clean Code to Clean Architecture
63
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
Dependencies point inward

Principles of Agile Engineering
1. Deliver Value
2. Quantify Qualities
3. Explore Alternatives
4. Last Responsible Moment
5. Front-to-Back
6. Test-Driven
7. Shorten Feedback Cycles
64

Quantify Qualities
 System Qualities are Priority #1 for Agile Architects
 Especially for products that differentiate on quality, more
than on functionality
 Current agile thinking encourages architects to focus on
functionality (user stories) not qualities
 But … Stakeholder value can most often be delivered by
improving qualities
 Agile system engineers’ primary focus should be on specifying
and delivering measurable improvements to qualities
 Qualities include things like Performance, Usability,
Maintainability, Availability, ...
 They can be elementary or complex
 They are typically scalar, not binary
65

Developing an Agile Architecture
 Agility is “the ability to make change cheap”
 Architecture is “what’s difficult to change”
 Some elements may be inherently agile
 Other elements are agile only by design
 Think about how to make change cheap
 Understand the expected dimensions of change
 In the business
 In the technology
 Make decisions about inflexibility conscious ones
Source: Andrew K. Johnston, Agile Architecture
66

Strategies for an Agile Architecture
 Build strong foundations
 Adopt a layered structure
 Separate the core from the business rules
 Layer the data, as well as the software (e.g. rule tables)
 Couple components loosely, but don’t go overboard
 Identify abstractions
 Solve a class of problems (e.g. expressive systems)
 Allow for growth, but remember Moore’s Law
 Practice change continually
Source: Andrew K. Johnston, Agile Architecture
67

Common Priorities
Architects and agile teams share many priorities:
Focus on the consumers of the systems
Efficient delivery of valuable software
Simplification and reduction of cost
Quality & reliability of delivered software
Supporting efficient change
Effectiveness of communication
Source: Eoin Woods, Agile Architecture - How much is enough?
68

Architecture Related Challenges in Agile
Development
 Incorrect prioritization of User Stories
 Lack of consideration for alternative design choices
 Lack of focus on quality attributes
 Unknown domain and untried solutions
Source: M. Ali Babar, Going Agile? Beware of Architecture-Related Changes and Challenges
69

Architecture First Fundamentals
The soul of an architecture is found in its mechanisms that cut across
the components of the system, thus yielding its essential structures
and behaviors.
 Architecture establishes the context for design and implementation
 Architectural decisions are the most fundamental decisions; changing
them will have significant ripple effects.
A system’s architecture can be used to
 Mitigate technical risks through the release of a continuous stream of
executables
 Improve learning and understanding and communicate important
decisions
 Accelerate testing and attack integration risks
 Set expectations
 Break-in the development environment and the team
Source: Grady Booch, Handbook of Software Architecture
Simplicity
Clear Separation of Concerns
Distribution of Responsibilities
Crisp Abstractions
70

Continuous Delivery of Agile Architecture

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Continuous Delivery of Agile Architecture

Similaire à Continuous Delivery of Agile Architecture (20)

Plus de Brad Appleton

Plus de Brad Appleton (12)

Dernier

Dernier (20)

Continuous Delivery of Agile Architecture