Architecture in an Agile World: SPLASH Workshop Report
SPLASH 2010, Reno, NV
October 18, 2010
The role of an architect can be very important in an
The workshop attendees addressed the following four questions:
- What is the role of an architect in an agile project?
- How can an agile project schedule architecture activities?
- Team and project characteristics: how do they impact the role
of the architect?
- What are some of the "architecture smells" to watch out for?
Role of an architect
- Balance YAGNI and long-term / business value
(YAGNI stands for "you aren't going to need it" -- which is the XP idea of
only designing and implementing based on the items in the current iteration.
The YAGNI principle advises developers to "do the simplest thing" that will
complete the user story.
An architect can be the person who says "when you do not do the
- Architects lead and communicate (they have stronger interpersonal
skills than the average team member)
- Set up the architecture infrastructure
(Architecture infrastructure might be the items the team identifies
in "iteration 0", or it might be a series of 3 or 4 exploratory early
iterations to stabilize the initial architecture.)
- Work across multiple levels of abstraction
(It has been generally observed that not all software professionals
are equally capable of working with several levels of abstraction --
many get lost after two or three levels. Architects often need to
work with 5 levels of abstraction or more.)
- Communicate with customers and stakeholders (such as the project
(In agile projects, direct communication between customers and all
team members is encouraged.
Architects might have a more intense focus on collecting and
understanding requirements that go beyond the normal "functional
- Set up guide rails -- these may be some decisions that guide
future design-level decisions
- Advise people making priority decisions (so they are more
aware of the future)
(In some agile methods, such as Scrum, the decisions about priorities
are made by the Product Owner -- usually with input from
customers, stakeholders, and team members.
Product Owners often need help to get familiar with architecture
issues -- what architecture choices might block future features,
how implementing some stories might have positive or negative
impact on performance, scalability, reliability, and so on.)
(Some teams decide to dedicate certain iterations to do refactoring
work -- architects might help recommend when a refactoring iteration
- "Combat the forces of evil"
(In the workshop discussion, participants noted that certain
business organizations -- Human Resources (HR), Information
Technology (IT), procurement, marketing, and sales organization --
might sometimes be a drag on the process... through
obfuscation, delays, and bad excuses.
Architects aren't always able to solve these problems, but they
sometimes have more authority to put up a good fight.)
How to schedule architecture activities
There is always a risk that essential architecture activities are
delayed because the customers or Product Owner put a higher
value on new functionality than infrastructure.
What are some ways to increase the visibility of the
risk and value of architecture work?
- Identify technical risk for each item in the backlog
The "technical risk" value might simply be high, medium, or low.
- Identify dependencies on "-ility" stories.
The term "-ility" refers to a number of "extra-functional requirements"
(sometimes called "architectural requirements") that span a large
number of customer-facing scenarios.
This category of requirements includes:
- Use more functional and acceptance tests (for some of these -ility
requirements) to drive architecture work -- to get more
architecture work scheduled in the iterations.
If there are automated tests for some of the -ility requirements,
it is more likely that these items will be given some
priority in the planning -- because they become more visible.
Gap: Not enough materials on acceptance testing.
The current training materials and books on automated testing for
"functional and acceptance tests" is pretty weak -- so many
agile team members don't really learn how to write good tests
for these -ility requirements.
We need more examples, experience reports, and training for
ATDD practices, especially aimed at a wider range of requirements types.
(Much of the literature is focused on simple database-centric
web applications -- but there are much richer functional testing
problems in other domains.)
Architecture-affecting business requirements
One way to approach the process of defining adequate -ility requirements
and testing is to narrow the focus on a subset of the business
requirements that are collected from the customers.
- Don't just wait for the customers to tell you about -ility requirements --
probe the customers to get more information.
- In other words, if you get a new or changed Business Requirement from the
customer -- and the requirement is in this "architecture-affecting" subset --
then the architect (or other team members) can open a dialog
with the customers to define some extra -ility tests.
Two smells from -ility requirements
We discussed two smells (which are really "agile process smells" more
than "architecture smells") that agile teams should be aware of:
Not enough time spent on architecture in iterations
Get the business people to articulate the missing -ility requirements
as user stories, then convert stories into functional/acceptance tests.
Use these tests to drive architecture work into each iteration.
Unbalanced test suite (the test suite is too heavy on
unit tests and TDD, or the test suite is narrowly focused on
certain facets of the architecture)
Get architects and lead developers to elicit more -ility requirements.
Side discussion on avoiding Big Design Up Front
One common fear of agilists -- the architecture documentation
might become an undesirable "Big Design".
This is a somewhat rational fear... because standard architecture
practices often push architects to try to be complete -- to specify
as much as they can.
But... one standard agile practice helps to reduce the risk: Timeboxing.
- Timeboxing in agile methods includes the mandate that each
iteration produce some real working code, even in the first iteration.
So you can't force the creation a document of hundreds of pages without
having at least some code to show that the architecture might really work.
Another interesting practice to try: Pageboxing.
- Pageboxing is deliberately limiting the initial architecture
documentation to a very small page limit -- for example, no more
than 20 pages in iteration 0. This is a good strategy, because
a short and concise document is more likely to be read and understood
by the entire team. (Why do you want to write a 100 page document
that no one will read? It is just a waste of time and effort.)
Team and project characteristics
Some combinations of team characteristics and project characteristics
might increase the importance of architecture and architects.
A "new team" is not a team of inexperienced developers, it is just
a group of people who have never worked together before.
An architect helps build trust within a new team
An architect helps train and establish a common vocabulary within the team
An architect acts as facilitator / catalyst, to get the
team to think about business issues, regulatory constraints,
and customer needs
Over time, an architect gains credibility and becomes a
technical leader for the team
This kind of team has experience working together, so
an architect isn't as important
But an architect can help the teamlearn what is new and
novel in their new project
There are some important project characteristics to watch for -- that
increase the value of having an architect on the team:
- constraints (e.g. regulatory constraints)
If you have higher complexity, larger size, and so on, the value
of the architect is higher.
Suppose your team is developing yet another web application.
The problem domain is very familiar to the team -- there isn't
much that is novel.
The size of the project is small, complexity is low, and there
are no serious constraints.
Does the team need an architect?
No -- probably not.
On the other hand, suppose this web application is for a
medical application -- and there will be some regulatory
approval required from the government.
Is an architect more valuable here? Yes, absolutely.
In the analysis of these factors, we think these three cases
- Highly-complex projects
- Highly-novel projects
- Significant constraints
For highly-complex projects, we need more architect involvement, especially
in "setting the roadmap" for the team.
The architect can help the team decide where to schedule
the definition, implementation, and testing of key pieces of
For highly-novel projects, there is some value in "encapsulating the
novelty" -- defining modules or components that make the novelty
easier to work with.
Again, the architect can contribute to building the roadmap or
schedule of architecture-centric features.
Finally, an architect can identify which parts of the problem
might be addressed later -- with an "emergent architecture".
For projects with significant constraints, the role of the
architect is mostly "communication" about the consequences
of the constraints plus "governance" -- ensuring that appropriate
reviews, tests, and other procedures are in place
to ensure the constraints are met.
The following list of architecture smells came out of
many parts of the Architecture in an Agile World discussion.
It isn't a complete list, and many of the smells in this list
are sometimes caused by problems unrelated to architecture
But these smells are a good place to start in looking for
architecture gaps in an agile project.
- Code that nobody wants to change (they are afraid to change it because
it is complex or cryptic, and they don't want to break anything)
- Missing metaphor (the team and customers need a common shared
understanding and vocabulary about the problem)
- Overreliance on "refactoring iterations" to fix technical debt
(It is generally OK to have some refactoring iterations that are
driven by architecture changes and evolution.)
- Abstractions that are hard to understand or communicate
- Missing -ility stories / tests / strategies
(A related issue: If you have many successive failures of -ility tests
in a series of iterations, it might be a sign of a lack of progress
on making improvements to the architecture.)
- Untestable code
- Unbalanced test suite (too many unit tests, not enough functional tests)
- Test churn
(Small design changes trigger a number of changes in the
automated tests -- could be caused by poor technique in the implementation
of tests, but there might be some architecture issues as well.)
- Problems in design evolution -- the problem is sometimes called
"you can't get there from here". You have a design that is too
- Inconsistent use of infrastructure
(For example, there are some modules that use a standard messaging
component while other components use some special local messaging code.
It isn't really "wrong", but it increases the learning curve for new
project members, and it might cause long-term maintenance issues.)
- General violations of architecture standards
- Missing boundary stories
How does your system interact with other systems?
What end-to-end stories do you need to write to understand the
interface requirements between your system and external systems?
- Duplication without reason
(Examples: using two different databases, multiple interface
- A mumber of incidents in operations
(If the system is hard to use, easy to make configuration mistakes,
or it is easy to get things into an error state -- this might
indicate that you missed some requirements or you might have
some other architecture gaps to address.)
Some "agile development advocates" reading this report might
ask the question:
- "Why are you advocating an architect role
in agile projects?
We have always found architects and architecture organizations
to be a source of many problems for agility.
For example, they are always trying to act as a 'central control'
of the design -- a kind of design rule dictator.
Shouldn't we just get rid of architects completely?"
We discussed this point a year ago: in the 2009 workshop.
for the full report of the 2009 workshop.)
We came to the conclusion that although there are many architects and
architecture organizations that abuse their powers, there
can still be a lot of value from having architects within
The 2009 workshop defined a list of characteristics of
"good architects" and "bad architects" -- also called
"architect patterns and antipatterns."
We assume that an overcontrolling architect is really bad.
Effective architects work in a more collaborative model:
they may be strong advocates for the "architecture", but
they must act more as a coach and teacher than as a dictator.
The 2010 workshop started with the recognition that some
architecture work needs to be part of any good iterative
Most of the established agile methods, such as XP and Scrum,
put up some obstacles to getting important architecture
planning and implementation into the iteration workflow.
Instead of making architects into outcasts in the agile development
process, they really need to be full team members, with
responsibilities for real coding as well as planning and
- Henry Baragar (Instantiated Software, Canada)
- Wim Couwenberg (Oce Technologies, Netherlands)
- George Fairbanks (Rhino Research, USA)
- Steven Fraser (Cisco Systems, USA)
- Gail Harris (Instantiated Software, Canada)
- Kenji Hiranabe (Change Vision Inc., Japan)
- Eric Lindberg (Teachscape, USA)
- Sonya Lowry (University of Arizona, USA)
- Dennis Mancl (Alcatel-Lucent, USA)
- Gerard Meszaros (independent consultant, USA)
- Chris O'Connor (Xtrm-Nrg Consulting, USA)
- Bill Opdyke (JP Morgan, USA)
- Barbara Prusiewicz (Verifone, USA)
- Dave Rathnow (Zedi Inc., Canada)
- Thomas Ritter (SAP, Germany)
- Vanessa Santanna (Globo.com, Brazil)
- Martin Buhl Svanum (Saxobank, Denmark)
- Harald Wesenberg (Statoil, Norway)
- Werner Wild (Evolution, Austria)
- Anders Winthereik (BankInvest, Denmark)
Thanks to everyone for a great discussion!
Last modified: Oct. 26, 2010