Architecture in an Agile World
This "Architecture in an Agile World" project started in fall 2009,
with a discussion-based workshop at the ACM OOPSLA 2009 conference.
This workshop explored some of the basic ideas of how best
to use architectural thinking and software models in the context
of agile development.
Agility is an important characteristic of product development
in the business world - but in many problem domains,
architecture is valuable too.
The combination of agile and architecture-driven approaches
is often essential to success - it creates some opportunities
for discovering potential problems early in the development cycle.
There is a fair amount of disagreement about the nature of the
relationship between agility and architecture.
Philippe Kruchten and George Fairbanks have probably the most
moderate points of view on this topic.
- If you read articles from some of the Extreme Programming founders,
you will see that most of them think that formal architecture is
unnecessary and wasteful -- developers should follow the
"YAGNI" principle (You aren't going to need it). If the
developers keep their code flexible and refactor often to handle any new
scenarios or performance requirements, the system will continue
to support new functionality without major development headaches.
But the more pragmatic view is to always include some architecture
planning activities in the "product backlog," because you need to
"pave at least some of the runway ahead of your airplane if you
want to take off."
Some architecture planning may forestall potential problems in
supporting non-functional requirements, particularly performance,
scalability, reliablity, and security.
This article (arch_agile_notes.html)
is an overview talk on Agility and Architecture (from March 2016).
There are two major OOPSLA/SPLASH workshops that discussed many of
Architecture in an Agile World - workshop at the OOPSLA 2009 conference:
Architecture in an Agile World - workshop at the SPLASH 2010 conference:
Useful articles on Agile and Architecture
The following articles provide useful background to understand
the costs and benefits of doing some architecture work in agile projects.
Useful architecture techniques for agile projects
The following articles explain several useful techniques to use
in order to build lightweight and flexible architectures:
A good quote from Kent Beck:
"Since most of the cost of a program will be incurred after it is
first deployed, programs should be easy to change. The flexibility
I imagine will be needed tomorrow, though, is likely to be not what
I need when I change the code. That's why the flexibility of
simplicity and extensive tests is more effective than
the flexibility offered by speculative design."
(Kent Beck, Implementation Patterns, p. 12)
A good quote from Eric Evans:
"Design free-for-alls produce systems no one can make sense of as a
whole, and they are very difficult to maintain. But architectures can
straitjacket a project with up-front design assumptions and take too
much power away from the developers/designers of particular parts of
the application. Soon, developers will dumb down the application to fit
the structure, or they will subvert it and have no structure at all,
bringing back the problems of uncoordinated development."
"Therefore: Let this conceptual large-scale structure evolve with the
application, possibly changing to a completely different type of
structure along the way. Don't overconstrain the detailed design and
model decisions that must be made with detailed knowledge."
(Eric Evans, Domain-Driven Design, chapter 16)
A good quote from Luke Hohmann:
"The role of architecture in agile software
development is pretty interesting. Some practitioners
equate architectural planning to "Big Up Front Design"
(BUFD) and minimize its importance. We believe that
this is inappropriate, and instead believe that up-front
architectural analysis and design is critically important
to the long-term success of agile projects.
That said, every architecture, no matter how well-designed,
must be maintained. This can be a challenge
in agile teams who focus their attention on backlog
items that are most associated with top-line revenue
growth and/or customer demands. To combat this
tendency, we advocate anthropomorphizing the system.
This enables the system to literally "have a voice" in
its own "care and feeding" and helps encourage agile
teams to make architectural investments that are every
bit as important to the long-term needs of the business
as various features are to other customers."
(Luke Hohmann, "Agile Program Management: Lessons
Learned from the VeriSign Managed Security Services Team,"
Is my agile project doing an adequate amount of architecture work?
One way to tell is to look for "architecture smells" -- indications
that you are doing extra work that could be avoided with more
attention to architecture.
The following partial list of architecture smells was proposed in
the SPLASH 2010 workshop:
A number 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.)
Last modified: Oct. 25, 2018