SPLASH '10 Workshop: Architecture in an Agile World
Monday October 18, 2010, 8:30am - 5pm
Location: SPLASH '10
Conference in Reno
This is the website for the SPLASH workshop on
Agility is important 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.
The goals of this workshop are to explore the issues and obstacles in
doing agile development - with an eye on building and maintaining a
sound architecture. We plan to delve into these subjects:
For example, Agile development techniques are best for highlighting
issues that are linked to the "uncertainties in customer requirements."
But some architecture practices can help surface some of the key
"technical unknowns" in a complex product development effort.
Understanding some of the risks and opportunities of blending agile and
architecture-driven software devel-opment practices.
Determining how architects establish credibility with software
Definitions of some key characteristics of good archi-tects and good agilists.
Discussion of why agile groups have problems with architecture-driven
processes and why architects have problems with agile project
How both agile and architecture-driven practices are used in
technologies such as cloud computing and soft-ware as a service.
Exploration of some of the "good practices" that should be part of the
toolkit of agilists and architects - "how to get just the right amount
The workshop will explore the tension between agile and
architecture-centric philosophies, and some practical ideas for
combining the two approaches.
How to join the Workshop
interested in the juncture of agile and architecture?
You can join in on the discussion. Here is
how you can become part of the workshop:
- Contact one of
the workshop organizers listed below.
- Prepare a
one-page "position paper" -- containing your ideas, questions, and
experiences. Send your position paper to mancl - AT -
(The original position paper due date was August 27, 2010 -- but we will
still accept position papers until September 27. But please contact
Dennis Mancl by email as soon as possible to confirm your interest.).
The workshop is organized as a
set of interactive brainstorming and discussion sessions. The
workshop participants will prepare a poster to present at the
SPLASH poster session on Monday afternoon.
- The position papers will be used as a starting
point for planning the workshop's activities.
Some suggestions for what to put in the position paper:
- Your position paper might explain some of your personal
experiences (positive and/or negative) with agile/lean/lightweight
- Or, you might also describe some specific problems that
you encountered in an agile software project because of inadequate
- Or, you could describe some of your own philosophy of
architecture thinking and planning -- to contribute to the discussion.
- Finally, you could use your position paper to ask some
questions -- some of the things that puzzle you about the
intersection of agile and architecture.
- Dennis Mancl (mancl - AT - alcatel-lucent.com)
- Bill Opdyke (opdyke - AT - acm.org)
- Steve Fraser (sdfraser - AT - acm.org)
Link to the original workshop proposal: architecture_agile.pdf
The following position papers have been submitted to this workshop:
Some useful links with post-workshop discussions:
Reports from the OOPSLA 2009 conference:
Useful articles to read before the workshop:
Other interesting articles, videos, and books:
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,"
Some interesting questions:
- What is architecture?
- Simply the high-level design of a system.
- The part of the design that endures as the product is evolved to meet new needs.
- The organization, structural elements, and interfaces of a software system.
- A description of the subsystems and components of a software system and the relationships between them.
- System structure, behavior, and "ilities" (such as usability, reliability, portability, security, performance).
- Stuff that's hard to change later.
- How does the principle of "you aren't gonna need it" (YAGNI) apply to architecture?
- Architecture of the system is the result of a number of refactoring steps.
- Architecture is the result of up-front architecture planning -- it is
a small up-front plan to define an overall structure, but
the parts of the architecture that are not needed immediately are
scheduled for much later iterations.
- Who are the "customers" for the architecture?
- Not just the developers...
- Testers need architecture information in their test planning -- and
testers may want certain architectural features to support efficient
- There is a link between architecture and requirements -- some of
the requirements can't be written until some architectural choices
have been made
- Executives should be a customer for the architecture: because
they need to understand both the present and the future of the product,
and the architecture contains information about possible future features
Last modified: Oct. 19, 2010