You are on page 1of 38

Agile Software Architecture

Designing architecture iteratively, keeping it simple and


Martn Salas
This book is for sale at

This version was published on 2017-05-16

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.

2016 - 2017 Martn Salas

Tweet This Book!
Please help Martn Salas by spreading the word about this book on Twitter!
The suggested hashtag for this book is #AgileArchitecture.
Find out what other people are saying about the book by clicking on this link to search for this
hashtag on Twitter:

Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Chapter 1: Agile & Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Agile Recap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Software Architecture Recap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Agile Architecture Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 2: Architecture Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Emergent vs. Adaptive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Quality-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Business Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 3: Agile Architecture Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Architectural Inception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Design and Validation Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Symmetry and Integral Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Validation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Validation Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Quality Stream Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 4: Architectural Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

The Monolyth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
The Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapter 5: Architecture Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Greenfield Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Brownfield Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Legacy Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 6: The Agile Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Facilitator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Innovator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Architectural Tarot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Architectural Radiators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
This book is still being written. The topics in the table of content will probably change over time.
Also, Im writing following a slicing strategy: instead of writing whole chapters or sections, Im
constantly adding text everywhere, trying to cover a wider range first, then going deeper in each
topic, in an organic fashion. I cant guarantee the results, but Im having fun!
Please feel free to provide feedback to me as you want. The easier way to contact me is via Twitter
at @MartinSalias. And dont forget to visit us at Kleer!
Thanks for reading!
Software Architecture is a wide and complex discipline, full of different perspectives, opinions and
definitions. If there is something in which most practitioners agree is in its importance, and how the
lack of thought on the subject -even while it should be proportional to the problem at hand- tends
to produce poor or downright deficient results.
The main idea behind this work is that, as fundamental as software architecture is, it shouldnt be
considered a separate activity on the whole software life cycle, either to be performed by an isolated
group or individual, or to be conceived in a separate phase from the majority of the construction
Following the main ideas of iterative and incremental development on the Agile paradigm, my
thesis is that the best software architecture for a given project emerges as the rest of the projects
goes on, and that there are concrete practices and techniques that support the incremental design
of the architecture together with the rest of the application, allowing for late but safe refinement
whenever needed.
The main ideas in this book come mostly from other people, mixed and matched by me within a
few different initiatives, including an early Software Architecture Seminar; a few years teaching
Software Architecture at Universidad de Palermo, in Buenos Aires; a paper written together with
my friend Diego Fontdevila for the late Architecture Journal; and the Agile Architecture Workshop
I frequently facilitate at Kleer, my current company, which is constantly evolving, probably more
than ever during the writing of this book.
Beside all this theoretical or conceptual sources, this work tries to distill the experience of a couple
decades designing architectures from different types of applications on heterogeneous technologies
and platforms, in several different industries, either as the main architect, part of a team, or as an
external consultant or advisor. As usual, the most interesting ideas came from committing horrible
Chapter 1: Agile & Software
Software development is a pretty new discipline. It started in theory with Charles Babbage and
his Differential Engine, and Lady Augusta Ada Byron, Countess of Lovelace, becoming the first
programmer in history, although she never had the actual computer to execute her programs!
From these early days to Word War II, computing turned from theory to a mean to push
mathemathics to a larger scale, and remained as an academic endeavor until the early 50s, with the
Univac. Later that decade IBM starts producing their first commercials computers and programmers
start spreading from mathematicians to engineers, and a new species was born: the homo-nerdus,
also known as computer programmer.
Early programming methods were pretty much ad-hoc, and the cycle between coding and compi-
lation could be measured in weeks, from punching the cards (which sometimes the coder could not
do on her own) to submitting the batch of cards to the Computers Administrators and wait days to
receive back a paper listing with the result run or just pages of error information.
As computers became popular in the corporate world and software applications got more complex,
the need to stronger engineering practices appeared, and from 70s to 90s our industry exported
ideas and processes from the previous engineering fields, from electronics to civil construction. The
result introduced several problems, basically because programmers got subjected to controls and
environments closer to blue-collar workers than designers, most of the time restricting innovation
and creativity.
Agile software development crystalized at the start of the XXI century as a reaction to these
prescriptive processes, putting the focus back in the non-repetitive side of programming, fostering
relationships, team dynamics, collaboration outside of the technical roles, and maximizing feedback
loops everywhere.
In the first part of this book I want to provide a short recap of its main topics, just to set expectations,
boundaries and terminology I will use in the rest of the book, and as a pivot for further discussion.
First I will review the Agile paradigm from the values and principles and the practices in he most
common frameworks like Scrum and Extreme Programming, its Lean cousin Kanban, and then what
I understand as the meta-model behind Agile.
Then I will do the same with Software Architecture, focusing mostly in the type of Architecture I
will refer to in this book, and pointing to connected disciplines.
Lastly I want to present my view of the main challenges Software Architecture face on Agile teams,
projects and organizations, and provide a short overview of the different approaches I present about
this topic during the rest of the book.
Chapter 1: Agile & Software Architecture 2

This book is still a work in progress, but luckily Im not alone. I want to thank several friends who
helped me come to the ideas Im compiling here, and also the ones helping me during writing, by
providing feedback about concepts, grammar even my style and humor (or lack of thereof).
I have to thank first Diego Fontdevila who wrote with me the paper where I started writing down
the ideas and experiences I gathered over the previous ten years (Software Architecture in the Agile
Life Cycle, Architecture Journal #23).
Several years before the paper, I worked and taught Software Architecture with Diego Gonzlez and
Juan Ladetto, whose insights and ideas were really influential in many of my choices and research.
Also, I feel in debt with Ted Neward, whose book Effective Enterprise Java had a huge impact
in the way I see the field beyond any technology, and of course, because he started the idea of
Architectural Katas, which I later adopted and customized to run in several events and also as part
of my workshops.
I also need to thank the whole Southworks crew, in special Johnny Halife, Matias Woloski and my
old-time friend Angel Java Lpez. I always miss the awesome discussions we had, full of ideas
and practical wisdom. Also, I enjoyed working and discussing with the team at Microsoft Patterns
& Practices, one of Southworks most important customers, in particular Eugenio Pace and Scott
As I joined Kleer and designed my Agile Architecture Workshop, I had great input from several of my
colleagues at Kleer, especially Juan Gabardini, Luis Mulato and Yamit Crdenas, and colleagues from
other companies like Ral de Villa Cano, Marcelo Oks, Andrs Joaqun, Adrin Anacleto, Santiago
Blanco and many more Im probably forgetting.
Lastly, I want to thank the first reviewers of this book, Nico Pez and Scott Baldwin.
Chapter 1: Agile & Software Architecture 3

Agile Recap
As Agile Methodologies decreases focus on written documentation in favor of oral and visual
communication, I will start using my colleague Pablituxs poster to review the Agile Manifesto:

Agile Manifesto (by @pablitux)

Chapter 1: Agile & Software Architecture 4

The text of the Manifesto says:

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

Lets re-read these values from an architectural viewpoint, and ask some questions:

Who are the Individuals in this case?

Isnt architecture mostly about processes and tool?
Can we build working architecture without comprehensive documentation?
Who are our customers when we build (or install) architecture components?
Do we have a contract?
Are we capable of changing our architecture when needed, instead of sticking to our
prescribed model?

My personal view on Agile

After almost 20 years working under the agile paradigm, starting with the early XP days by the
late 90s, as you might expect, I have some strong opinions about this model and its impact in the
industry and the community.
I dont think my ideas are particularly original or important, but as the book moves into the model I
found to put them to work into software architecture, I think it is important to tell you about some
of them, even if this serves to set some disagreement early on.
So here I go:
Chapter 1: Agile & Software Architecture 5

Agile is a cultural approach

I find the frequent usage of Agile Methodologies somewhat unfortunate. Some people still thinks
that Agile is just a different way to run projects, but it is way beyond this. As Kent Beck used to say
about XP, it is about social change.
As pretentious as social change might sound, Agile is mostly about moving from centralized
decision-making and high-specialization to an environment of shared decision-making and high-
collaboration. This is somehow subversive in the sense of potentially breaking chain of commands,
which quickly push for a different distribution of money, power, knowledge and so on.
Of course, this is an ideal, but it is there, and I believe that continuous improvement only can get
you close to that. Otherwise, improvement will slow down and probably stale.

Agility requires Quality

Quality in execution comes from avoiding shortcuts and being transparent about what you do,
without looking for someone to blame when things fail, but looking for underlying problem and
fixing root causes.
Transparency, introspection and improvement are core values of Agile, and thats what one things
brings to the other.
Moreover, Technical Excellence is one of the principles stated in the Manifesto, and is one of the
distinctive traits one consistently finds in succeeding Agile teams. Indeed, many teams adopting
Agile can get great results at first, but quickly get in trouble when neglecting technical improvement.
This pattern was so common that even Ken Schwaber (one of the fathers of Scrum) started using
the term Flaccid Scrum to describe the problem.
Chapter 1: Agile & Software Architecture 6

Software Architecture Recap

Software Development is a Complex human activity.

Angel Java Lpez

Of course I wont dare to define Software Architecture on my own, as this is an often debated topic,
and Im not planning to add a lot of heat to this.
Instead, I will try to present some commonly used definitions from several recognized authors, and
try to get some basic ideas to build upon during the rest of the book.
First, a meta-discussion on the topic from Luke Hohmanns Beyond Software Architecture
(Addison Wesley, 2003):

Software architecture is a complex topic. Because of its complexity, our profession has
produced a variety of definitions, each more or less useful depending on your point of
view. Here is a definition from my first book, Journey of the Software Professional:

A system architecture defines the basic structure of the system (e.g.,

the high-level modules comprising the major functions of the system, the
management and distribution of data, the kind and style of its user interface,
what platform(s) will it run on, and so forth).

This definition is pretty consistent with many others for example, [Bass], [Lerman],
and [POSA]. However, it lacks some important elements, such as specific technology
choices and the required capabilities of the desired system. A colleague of mine, Myron
Ahn, created the following definition of software architecture. It is a bit more expansive
and covers a bit more ground than my original (2002, personal communication):

Software architecture is the sum of the nontrivial modules, processes, and

data of the system, their structure and exact relationships to each other, how
they can be and are expected to be extended and modified, and on which
technologies they depend, from which one can deduce the exact capabilities
and flexibilities of the system, and from which one can form a plan for the
implementation or modification of the system.

We could extend these definitions from the technical point of view, but this wouldnt
provide a lot of value. More than any other aspect of the system, architecture deals with
the big picture. The real key to understanding it is to adopt this big picture point of
Chapter 1: Agile & Software Architecture 7

Another meta-vision comes from Ian Gortons Essential Software Architecture (Springer, 2006):

1.2 Definitions of Software Architecture

Trying to define a term such as software architecture is always a potentially dangerous

activity. There really is no widely accepted definition by the industry. To understand
the diversity in views, have a browse through the list maintained by the Software
Engineering Institute2. Theres a lot. Reading these reminds me of an anonymous quote
I heard on a satirical radio program recently, which went something along the lines
of the reason academic debate is so vigorous is that there is so little at stake. Ive no
intention of adding to this debate. Instead, lets examine three definitions. As an IEEE
member, I of course naturally start with the definition adopted by my professional body:

Architecture is defined by the recommended practice as the fundamental

organization of a system, embodied in its components, their relationships to
each other and the environment, and the principles governing its design and
evolution. [ANSI/IEEE Std 1471-2000, Recommended Practice for Architec-
tural Description of Software-Intensive Systems]

This lays the foundations for an understanding of the discipline. Architecture captures
system structure in terms of components and how they interact. It also defines system-
wide design rules and considers how a system may change. Next, its always worth
getting the latest perspective from some of the leading thinkers in the field.

The software architecture of a program or computing system is the structure

or structures of the system, which comprise software elements, the externally
visible properties of those elements, and the relationships among them.
[L.Bass, P.Clements, R.Kazman, Software Architecture in Practice (2nd edi-
tion), Addison-Wesley 2003]

This builds somewhat on the above ANSI/IEEE definition, especially as it makes the
role of abstraction (i.e. externally visible properties) in an architecture and multiple
architecture views (structures of the system) explicit. Compare this with another, from
Garlan and Shaws early influential work:

[Software architecture goes] beyond the algorithms and data structures

of the computation; designing and specifying the overall system struc-
ture emerges as a new kind of problem. Structural issues include gross
organization and global control structure; protocols for communication,
synchronization, and data access; assignment of functionality to design
elements; physical distribution; composition of design elements; scaling
and performance; and selection among design alternatives. [D. Garlan, M.
Shaw, An Introduction to Software Architecture, Advances in Software
Engineering and Knowledge Engineering, Volume I, World Scientific, 1993]
Chapter 1: Agile & Software Architecture 8

Its interesting to look at these, as there is much commonality. I include the third mainly
as its again explicit about certain issues, such as scalability and distribution, which are
implicit in the first two. Regardless, analyzing these a little makes it possible to draw
out some of the fundamental characteristics of software architectures.

Finally, Stephen Albin comes to his own terms in The Art of Software Architecture (Wiley, 2003):

Software architecture involves the integration of software development

methodologies and models, which distinguishes it from particular analysis
and design methodologies. The structure of complex software solutions
departs from the description of the problem, adding to the complexity of
software development. Software architecture is a body of methods and tech-
niques that helps us to manage the complexities of software development.

Software architecture is a natural extension of the software engineering

discipline. In early literature it was simply referred to as programming
in the large. Software architecture presents a view of a software system
as components and connectors. Components encapsulate some coherent
set of functionality. Connectors realize the runtime interaction between
components. The system design achieves certain qualities based on its com-
position from components and connectors. The architecture of a software
system can be specified in a document called the architectural description.
Software architecture design is not entirely different from existing software
design methodologies. Rather it complements them with additional views
of a system that have not been traditionally handled by methodologies like
object-oriented design. We will learn that software architecture fits within
a larger enterprise architecture that also encompasses business architecture,
information technology architecture, and data architecture.
Chapter 1: Agile & Software Architecture 9

Agile Architecture Challenges

Now that I discussed the Agile paradigm and Software Architecture, lets talk about the intersection
between the two.
Even while agile methodologies are getting widely accepted in the development world, there is still
a lot of debate about how to apply them to the architectural space. One of the most conflictive
issues stems around big design upfront, which is strongly discouraged by agile practitioners, and
the traditional approach to architectural design.
In our original paper from 2010 , Diego Fontdevila and I proposed a set of team dynamics, conceptual
practices, and specific technologies to embed software architecture within the agile approach
keeping up the shared goals of technical excellence, streamlined development practices, and a
constant and ever- increasing flow of business.

Architectural Dynamics in Agile Teams

One of the 12 principles of the Agile Manifesto states that the best architectures, requirements, and
designs emerge from self-organizing teams. We took this to heart especially, the reference to our
shared specialization.
While architecture is an activity that is historically performed with an emphasis on the early stages
of a project, the main focus of agile development is on emergent design and iterative production
creating a series of interesting challenges down the road.
First of all, agile makes a big push toward shared responsibility and, thus, dilutes the traditional
role of the architect as the one who defines the higher-level design of a solution. In this new
approach, architecture (as most other development activities) is something that is performed by the
whole team -preserving its multidisciplinary nature. This does not imply that the architect profile
goes away, as with all the other roles; it means that while someone contributes with a broader and
probably more experienced perspective (usually leading in this aspect), the whole team participates
and understands the implications of the design decisions that it makes, and continuously evaluates
In our experience, key considerations -such as the modularity strategy, how communication is
handled within and outside the application, and how data and services are accessed and abstracted
- are successfully defined and implemented when the whole development team establishes a
consensus about these issues. In this way, team members fully understand the consequences of the
selected alternatives, remain aware of their initial assumptions throughout the solution life cycle,
and quickly raise concerns when their validity is affected.
Most of these challenges are usually tackled by folding architectural discussion and revision into
the regular meetings that take place over the course of an iterationsuch as planning and review
meetings, and frequent sync-ups and design meetings with plenty of white boarding and open talk.
Software Architecture in the Agile Life Cycle, by Diego Fontdevila and Martn Salas; published in The Architecture Journal, Issue 23, 2010.
Chapter 1: Agile & Software Architecture 10

It is also worthwhile to have the most important guidelines permanently exposed in an informative
space, including diagrams, checklists or reference charts around the walls, and semipermanent flip
charts that are used as posters.
This article does not cover in detail specific techniques that apply to coordinating several subteams;
mainly, it mirrors the standard guidelines about Scrum of Scrums. The addition to such activities
is a stronger focus on the preservation of conceptual integritythus, planning frequent high-
level design meetings between teams. Again, these meetings should avoid becoming architect
meetings; while the contribution of team members who have a stronger architectural background is
obviously important, it is very important for other members to participate. Even the less experienced
team members can provide a somewhat nave perspective to some discussionpromptly flagging
complexity excesses that are a professional malady among us architects.
To close on the team dynamics, as the agile perspective goes over the standard view of the devel-
opment team and extends to customers, operations personnel, and other stakeholders, expectation
management is a big deal also for the solution architecture. In the strategy I present in this book there
is a strong emphasis on mapping the needs and goals of these actors to the architectural constraints
and converting the most important ones into strong metrics to be evaluated.
Chapter 2: Architecture Flow
The traditional approach to Software Architecture has been to work for quite a long time defining
the scope, laying out components, archetypes or layers, and sometimes even building parts of the
architecture blocks before the actual solution starts.
Of course this is a mismatch to the idea of adaptive design that Agile brought us. If we are supposed
to discover the details of the product we are building during the project itself, and following Lean
principles, deferring decisions to last responsible moment, then Big Design Upfront cant apply to
Architecture either.
Indeed, what we know now is that every time we defer some of those technical decisions to the
moment we learned more about the problem domain, our stakeholders expectations and also about
our own solution, we are creating more possibilities. Every time we take a decision and start working
on its premise we bound ourselves a little to that. Over time, hard technical decisions are hard to
change, as we always knew in Architecture, but instead of trying to take them right, we will start
to take them late. Sometimes late means that we might get lucky and might never have to decide
about it at all.
Another turn we take from the traditional approach is that instead of trying to figure out the right
architecture with our stakeholders in the beginning, we typically discuss the basics, but then we dont
press them with details they dont know, or they cant never be sure enough. As we are supposed to
discover the product features in detail over time, and release early versions to be used in production
and learn from them, the architecture would probably need to be discussed and evaluated from
actual data from the design process and runtime.
Most than anything else, my strategy is to keep the conversation about architecture (mostly
discussing quality attributes) open and intertwined with functional discussions, as both things go
along in the system development and usage. To do that, I will explore some lightweight alternative
practices that can be added to standard planning and review meetings, as well as how much to
advance at products inception.
Chapter 2: Architecture Flow 12

Emergent vs. Adaptive

Even while this books title is Agile Architecture to try to convey the main ideas from which my
model arises, I like to use the term Adaptive Architecture also, as there are a lot of ideas that could
be used even in the context of not-so agile projects.

Emergent behavior
In Complex System Theory, emergence is the process where a system composed by several smaller
entities shows properties that are not explicitly present in its parts. In Software Development, we
used the idea of Emergent Behavior quite a few times, trying to explain how smaller functions,
objects or components build up to a system exhibiting some features that are beyond the sum of its
While the metaphor is nice and powerful, most software systems (with the exception of some
Artificial Intelligence approaches) have not real emergent properties, because causality is too high
on them, as we design components and the way they interact with a very specific purpose.
Growth of software projects and products is better explained by looking at Complex Adaptive
Systems, which -although usually based on emergent behavior- have a difference in purpose and
specialization (typically to foster survival). Adaptive Systems are complex in the dynamics of their
interactions, and they dont just happen, but self-organize to achieve a goal.

Adaptive Systems
In the highly multidisciplinary realm of Complexity Theory we as software developers or architects
join economists, politicians, ethologists, entomologists, and a plethora of other professions dealing
with loosely coupled relations and varying contexts.
Software is adaptive both from the development perspective, as development teams are comprised
of humans dealing with a creative process, surrounded by changing conditions, subject to volatile
restrictions and with unpredictable input (from other humans).
The Agile paradigm recognizes these factors and thus applies an empiric process where all this
factors are constantly observed, following the scientific method of formulating hypothesis, trying
to prove or discard them, then building on that learning to formulate further hypothesis.
In that sense, Architecture should follow the same principle, and to that end, I prefer to come up
with architectural hypothesis when there are concrete experiments to run in order to prove them.
And this hardly appears before actual functionality is built.
Chapter 2: Architecture Flow 13

Quality-Driven Architecture
Beyond the different definitions found for Software Architecture, Quality Attributes (also mentioned
as non-funtional requirements) are always at the core of the field.
This is completely independent of the Agile approach, as seen in many different formal approaches
used over time to base architectural decisions on this attributes.
In particular, I always liked the Quality Attribute Workshop (or QAW) from SEIs Software
Architecture in Practice . The QAW follows an eight-step approach to discuss about the Quality
Attributes for a system during a Workshop event at projects inception, where business and technical
people discuss these matters. The steps are the following:

1. QAW Presentation and Introductions

2. Business/Mission Presentation
3. Architectural Plan Presentation
4. Identification of Architectural Drivers
5. Scenario Brainstorming
6. Scenario Consolidation
7. Scenario Prioritization
8. Scenario Refinement

What I like from this approach is it pays attention to the business goal first, and then focus on
scenarios discussed among business and technical people.
The main problem I found, as you can easily imagine, is that the workshop is an activity designed to
be run at the start of the project, when all involved people know very little about the actual system
being built, beyond the conceptual model and it assumptions. For the most part, little to nothing has
been built, and no single feature has been used yet.

Iterative approach to Quality Attributes

Taken the previous idea and breaking it down to smaller, frequent discussions best fit to an Agile
team, I came up with a lighter plan to achieve the same effect:.
First, we might have a brief discussion about high-level Architecture and Quality Attribute
prioritization as part of the Agile Inception Workshop (more on this later in the Practices chapter).
But we wont try to define anything about this too much, but having an overall idea and a starting
strategy instead.
Then, we will have some time to discuss about Quality Attributes in every Iteration (or Sprint)
Planning meeting; not as an aside, but potentially around every User Story (or Backlog Item). So,
Software Architecture in Practice, 3rd edition, Len Bass, Paul Clements, Rick Kazman, SEI Series, Pearson, 2013.
Chapter 2: Architecture Flow 14

for each small feature (or the bigger feature it is included in) the team will review what the quality
expectations are.
For example, given a User Story relating to a Book Purchase, they will analyze (after the functional
details) with the stakeholders:

Is there any specific performance or security consideration?

Is this something we will need to change frequently, where maintainability will be important?
Is there any specific regional or accessibility concerns?

Of course, some of these concerns might have appeared previously (in previous User Stories), and
some of them might have become part of the Teams Definition of Done .
Whenever one of this issues appears the Team (together with the involved stakeholders) might take
note in some artifact like this:

Response Time

Once a Purchase is confirmed, the user should not wait for confirmation.


After confirmation, Keep shopping page should take no more than 0.4
seconds to render.


Operations are queued, and eventual failure will be informed by email and
site notifications.

Notice that in the example above the decision is generalized from Book Purchase to Purchase
operations in general. This card should be ideally pasted on a board in the Team Room (instead of
going to die on a Wiki Page) to be frequently seen. It might also generate some specific technical tasks
under the Book Purchase user story that will later be re-used, but this decision and the corresponding
implementation are directly tied to a feature, and will be tested and reviewed in this context, rather
than in a conceptual model.
The Metric field in the card should become an automated test which can be executed either
continually (in every commit) or in a nightly profile (for load or performance testing requiring
The Definition of Done is a set of criteria that an Agile Team agrees upon to consider a Backlog Item completely Done. This typically include
things like committed to source code, all unit, integration and regression test passed (probably executed by the Build Server), and some other important
validation or tasks the Team consider important for the product they are building.
Chapter 2: Architecture Flow 15

long-running or heavy processes which you dont want to compromise your network during the

Automatically validating your architectural decisions and testing those continually is one
of the main focus of an Agile Architecture approach. The Team needs to know if anything
they do (either changing an architectural component or adjusting some business logic)
breaks some of the expectations about quality they discussed with stakeholders, and be
able to quickly find what happened and fix it.
Chapter 2: Architecture Flow 16

Business Value
As we recognize that delivering value early and often is what makes agility attractive to our
customers, then we have to be able to justify our technical decisions following the same principle.
In that sense, non-functional requirements should be derived from the same kind of experimentation
we use to build the most appropriate product over time, by staying lean and refusing to include
features just in case some possible event happens.
We strive to make architectural discussion with stakeholders, and the corresponding design decisions
and implementation continuous tasks, the same way as analysis, functional design, coding, testing
and deployment.
We want to have a permanent relationship between stakeholders and architecture (represented by
the team, not necessary architects).
To do this, we have to develop a common language accessible to everyone like other pattern
languages. Among other ways to encourage this, I developed over time a deck of cards which finally
became the Architectural Tarot (you can see the whole deck in Appendix I). The cards provide a
visual approach that better engage non-technical stakeholders in architectural discussions.
We do this by using the deck not only during an Agile Inception or other kind of kick-start
workshop, but frequently in iteration planning meetings, as we keep finding about the non-
functional requirements as we develop the product and start using it.

Architecture in an Agile development cycle

To better illustrate how architectural discussion gets integrated as part of the expected osmotic
communication of an agile environment, I will use the Scrum diagram drawn by my friend and
colleague Martin Alaimo:
Chapter 2: Architecture Flow 17

Scrum - a framework (by @MartinAlaimo)

Even if you are not following Scrum, this diagram shows high level view of most iterative flows.
Below I list the Scrum names and then the generic description which can apply to any other agile

Product Backlog - a dynamic list of prioritized work to do

Sprint - an iteration (usually of fixed lenght)
Planning - session at the start of each iteration
Definition of Done - shared agreement on when an item is Done
Review - session to evaluate the product increment at the end of the iteration
Retrospective - continuous improvement session (usually on every iteration)

How can we mix architectural stuff all over there?

Planning and Reviews

While discussing every item with stakeholders, the team can use the Architectural Tarot (or any
other technique) to better understand the quality attributes involved.
Chapter 2: Architecture Flow 18

Based on the expected behavior, the team might come up with some quality metrics which may
become either (a) Acceptance Criteria for this particular item or (b) something to be added to the
Definition of Done, as it will be expected on several different contexts.


As part of the focus on improvement, the team can review how the architecture is doing so far,
trying to figure out potential problems and spot common excesses on time.
Some inductive reasoning questions I use for that are:

What we feel is too fragile so far?

What is being to hard to do?
What can be simpler in our current architecture?

A few recommendations before closing this section:

Keep architectural ideas coming from the retrospectives on the lookout for next planning
Beware of polluting the Definition of Done
Remember the Definition of Done should be understood and agreed with the customers/s-
Chapter 3: Agile Architecture
Chapter 3: Agile Architecture Practices 20

Architectural Inception
Agile Inception is currently a widely used technique used to create a shared vision among the
Development Team and the rest of the stakeholders for a given product. First documented by
Jonathan Rasmusson in The Agile Samurai (Pragmatic Bookshelf, 2010), it involves 10 activities
which can be run in a single workshop, sometimes picking some of them or complementing them
with other, depending on the project/product at hand.
I facilitated dozens of these workshops over the years, for organizations ranging from small startups
to corporations in different industries, and they have always been key to creating an collaborative
context among all involved parties.
In short, the 10 activities I run are:

1. Why are we here?

A check-in round with a twist, were every participants states not only their name and
role, but what they understand it is their involvement with the product.

2. Elevator Pitch

The group design a very short phrase explaining what the product is, whom its users
are, its main features, its competitive advantage and some other relevant detail. As an
alternative I can use a Product Vision Board (PVB) instead, depending on the audience.

3. Vision Box

We use a physical box (cereal-type) to design a fictitious box for their product, thinking
about it as a retail product (even if its not).

4. In/Out/Maybe

The group creates a simple chart about the very high-level scope of the product, stating
what it should have, deciding what it shouldnt, and leaving some features in a group
to be reconsidered later.

5. Community

This is a diagram about the different groups which need to be involved in the product
development, and their different levels of participation, in a visual way.

6. The Solution

This is the activity were we talk about the high-level technical decisions we can define
up-front to build the product. As some architectural discussion takes place here, I will
expand on it later in this section.
Chapter 3: Agile Architecture Practices 21

7. Fears

We chart all the important risks related to product development and delivery from all
the perspectives represented in the workshop such as Technology, Market, Cost, Team,
Legal issues, Security and others.

8. Size

Here the group discuss the perceived size of the project from several angles: Team Size,
including if the is a need for several teams; estimated duration or deadline, sometimes
including an expected release plan.

9. Trade-Off

This activity involves prioritizing the main non-functional concerns of the project,
debating which ones will take precedence in situations where some design decision
targeting one of them conflicts with others. This is the other activity related to
architecture strategy, so I will expand on it later in this section, too.

10. How much?

At this point the group makes a shopping list of all the important expected costs,
including salaries and fees, hardware and software, services, facilities and anything
else that can have an impact in the total cost, and perhaps when or how the cost will
impact (initial investment, weekly or monthly, tied to releases, etc). We dont typically
try to include the actual cost, but have a clear list to produce an actual budget later.

As you can expect, there is a lot more involved in this workshop, but my goal in this section is to
provide you with a general idea and get slightly deeper in the two highlighted activities:

The Solution
While the technical participants will be leading this activity, the main purpose is for them to clearly
explain to the rest of the group several things that they better understand and agree on as soon as
possible. For example:

Types of clients for the application (web, mobile, desktop, APIs, special devices)
Supported platforms (browsers, desktop or mobile OS, form factors)
Integration (with services, corporate applications, databases, sensors or networks)
Dependencies (with other products, projects, technologies)
Chapter 3: Agile Architecture Practices 22

Expected behavior for particular scenarios (should the mobile apps support offline usage? are
there some kind of distributed transactions? there are some extreme load situations? some
critical time-sensitive operations?)

What we try to achieve here is a shared understanding about implementation/architectural details

and how they will support the main business requirements. As the group sketches diagrams and talk
about the implications of different parts, a lot of assumptions from the different participant areas
come to light and new ideas retrofit this early draft of the architecture.

The starting point for this activity is to agree on a set of 5 to 8 attributes representing the main
non-functional concerns about the product. Most of these are the typical Quality Attributes we use
in Software Architecture, but I often let the group add some they find important. For example, I find
these in real-life Inceptions I facilitated: Total Cost of Ownership, Time-to-Market, and even Team
Life Quality.
As I like to run this, once we agreed on list, I make the group write each one on a sheet of paper
(big block letters filling the whole page) and then I make one person for each attribute to hold the
paper, showing the name to the others. Then they stand in line, one next to the others, like in a
police suspect line (which is a fun moment) and we discuss the relative positions, from left to right
(choosing which side means MOST important). The group keeps discussing and swapping the people
in the line to reflect the priorities. As a facilitator I help them come up with some potential conflict
scenarios between most attribute pairs, so everyone understands they cant make the cake and eat
it, too.
Once there is an agreement that the line represent their best bet, I usually ask the people in the line
to slightly turn so I can snap a picture of them where faces and signs are clearly seen, in order. I
found over time this picture showing what I call the Quality Strategy for the product, with faces
the actual team members building the product (and most stakeholders) can recognize, is way more
powerful to align decisions than any standard document.

Weirdly enough, the latter was agreed to be the most important issue in that project, as this was the third attempt at solving the same problem,
and the pressure had burned the teams on the previous attempts.
Chapter 3: Agile Architecture Practices 23

The concept of slicing or breaking down User Stories (although the general idea can be applied to
any other unit of work you use) into smaller ones is one of the most important aspects of Agile
Software Development.
As a community, we agree that the smaller (but valuable) a User Story is, the better, for several

More understandable
Simpler to prioritize (or re-prioritize)
Easier to estimate
Easier to decompose in implementation tasks
Fewer acceptance criteria; easier to test

Above anything else, when we break down a User Story into several smaller ones, we have more
chances to find less valuable items that can be deferred for later, and eventually discarded if they are
not valuable enough as the development goes on. This is exactly the Agile Principle of Simplicity,
defined as the art of maximizing the amount of work not done.

About Technical User Stories

Before moving forward I want to highlight that I dont believe in Technical User Stories.
My point is that a User Story should be valuable to the end user, not to the team, which is
typically the case for technical items.
But to properly solve User Stories, the dev team needs to break it down in Implementation
Tasks. Most of the time, architectural issues appear at that level.
Even if you are building Development Tools and Frameworks (something I did many times),
then all your User Stories might be technical in nature, but they need to cover real user
Chapter 3: Agile Architecture Practices 24

Functional Splitting Patterns

One of my favorite resources to help teams to slice (or split) User Stories is Richard Lawrences guide
Patterns for Splitting User Stories .
The guide proposes a three-step approach:

1. Check the User Story quality and fix other problems before splitting
2. Try a series of patterns to find ways to split it
3. Evaluate the resulting User Stories to be sure everything is fine

Whats most important for us now are the patterns themselves. I recommend you to read the original
post and even find out some additional patterns based on your experience, but lets list the 9 original
patterns before extending them.

1. Workflow Steps
2. Business Rule Variation
3. Major Effort
4. Simple / Complex
5. Variations in Data
6. Data Entry Methods
7. Defer Performance
8. Operations
9. Break Out a Spike

Even without getting into details you can see the focus is to try to break down functionality in more
granular parts, trying to be able to take the most valuable and ideally thinner part of each need, and
provide the earliest and more valuable implementation, trying to prove or discard the hypothesis
behind each User Story and also leveraging all the learning from this early delivery to better select
whats next, the best approach to implement it, and even whats not needed at all.

Architectural Splitting Patterns

Once you broke down your User Stories into smaller ones, you can still apply slicing strategies based
on architectural concerns.
You may have smelled some architectural patterns in the list above. For example: Variations in Data
can be considered also as Variations in protocols, message format, encoding, and other messaging
attributes. Also, Defer Performance, which tries to solve first the functional aspects of a User
Story and leave a potential optimization as a later Story, can be applied to several other Quality
Chapter 3: Agile Architecture Practices 25

Then, you can apply further splitting patterns when breaking each User Story down to its Tasks.
Whats important is to reflect in the resulting User Stories this restriction, and keep being explicit
about the remaining value.
Some of the extended Splitting Patterns I found useful from experience are:

User Experience level

This approach is actually a huge topic in itself, but basically focus in providing the simpler UX
approach first, iteratively test it with real users and keep refining for as long as needed, depending
on the product.
The UX field is so large and important right now that I prefer to point you elsewhere, probably
starting with the books Lean UX, by Jeff Gothelf and Josh Seiden, and User Story Mapping, by
Jeff Patton.

Reliability Constraints

User Stories related to reliability (when properly analyzed) tend to have strong acceptance criteria
about accurate data input and data transformations, error-free state management, and non-
corrupting recovery from detected failure condition.
This is not typically the kind of User Stories you get at first, but they appear through Backlog
Refinement and usually come from observed behavior after the application is already in use (or
under specific testing conditions).
The different constraints related to this normally have a highly different business value and
implementation costs, so separating each constraint base on its calculated Return of Investment
can be a smart move, and just doing this analysis can provide many insights for both the involved
stakeholders and development team members.

Manageability / Security levels

Configuration aspects can be split over time, deferring complexity from (hopefully short-term) hard-
coded values, config files/resources, admin dashboards, cold or hot reconfiguration mechanics, and
In a similar way, Security can be split along different axis like internal/external, authentication/au-
thorization, user-level, api-level, component-level, code-access-level, resource-level (like DB and
services accounts) and much more. Security is always a complex and sometimes very restrictive,
so the ability to spread various security concerns over a long period tends to be a good idea. In very
sensitive scenarios, each User Story can have very specific Security Acceptance Criteria, or can be
checked against a specific set of Security concerns gradually added to the Definition of Done.
Chapter 3: Agile Architecture Practices 26

Defer Performance / Availability / Efficiency / Scalability

As important as these factors can be in different scenarios, they are usually pretty difficult to plan
ahead without over-engineering. As we will see in other sections, a recurring pattern is to agree on
some baseline value as part of the User Story Acceptance Criteria and build an automated test to
verify this. Of course such tests are not always trivial, and that encourage good conversation with
stakeholders about the real importance of these attributes in a given context.
It should be also noted that building the first few testing scenarios for these Quality Attributes take
more effort, but the required environments and tools and scripts used tend to stabilize over time and
further automation effort usually decrease.

Staged Portability / Interoperability / Internationalization

For every User Story dealing with these attributes tend to be breath goals like:

target platforms
systems, protocols, messaging, data sources
languages or locales to support

But each of these dimensions have also depth goals:

versions (or version ranges) within each platform

versions, encodings, message formats
static text, dynamic text, localized media, date and currency formats, calendars

In many cases there can be a complex matrix for each of this Quality Attribute that can be split over
time. Staging this changes usually break down functional and technical implementation.

Taking / Paying Technical Debt

I like to take this as a separate pattern that can encompass any of the previous attributes, and it uses
the Technical Debt metaphor coined by Ward Cunningham.
Following the initial idea, when the team takes Technical Debt, it should be explicit and managed.
This is very different than implementing just what is needed. If you write clean code without
extensibility points that you dont need yet, this is not Debt at all. You will just have to spend a bit
more refactoring whenever (and if) the extensibility is needed later on. This kind of decision is not
incurring on any interest.
Now, if the team is explicitly leaving a substandard or partial implementation of a component (one
with known risks and issues) then they have to track this, and my favorite way to do it is by thinking
what is the problem/risk it generates for the users, discussing it with the stakeholders, and then
coming up with a User Story expressing that need: not the technical detail, but the need to prevent
the unwanted circumstance the current implementation leaves open.
Explained at Martin Fowlers bliki:
Chapter 3: Agile Architecture Practices 27

Design and Validation Levels

Symmetry and Integral Consistency

Validation Techniques

Validation Technologies

Quality Stream Mapping

Chapter 4: Architectural Styles
The Monolyth



The Cloud
Chapter 5: Architecture Stages
Greenfield Projects

Brownfield Projects

Legacy Systems
Especially, core systems.
See Fowlers StranglerApps.
Chapter 6: The Agile Architect



Architectural Tarot

Architectural Radiators