OOPSLA '09 Workshop: Architecture in an Agile World
Workshop date:
Sunday October 25, 8:30am - 5pm
Location: OOPSLA '09
Conference in Orlando
Website
Contents
Workshop
Overview
This is the website for the OOPSLA workshop on
software product development issues.
The world is moving faster than ever, and our software development
techniques are struggling to keep up. We feel we need to have an agile
feature set, but without a well-defined and understandable
architecture, we feel like everything is in chaos. How do we manage
the balance between architecture and agility?
Practitioners of agile development are promoting "less documentation" -
architecture is viewed as "big design up front", and therefore it is
something too costly to develop and maintain.
This workshop will explore the intersection of agility,
architecture-centric design, team organization, re-architecting,
reengineering, and long-term evolution issues. Some questions and
topics we will consider include:
-
Prototyping: Exploratory development (one of the areas where
agile development is very strong) is hindered by a strict
architecture documentation process - the architecture choices
made in prototyping are informal, and the documentation is
minimal. But when a prototype is "scaled up" to production,
what will happen? Will there be a greater need for a more
architecture-centric view of the system?
-
Reusability: Without some internal architectural
standards, it becomes impossible to reuse existing
modules or subsystems.
-
Reliability and Availability: Some of the most
important features of an architecture - the
architecture provides an organized structure to
assure conformance to architecture requirements
(such as reliability, availability, and other
related "ility" requirements). What are some of
the ways that agile approaches address these requirements?
-
Contracting and Outsourcing: How can you contract for the implementation of
subsystems unless there is a solid way to specify each subsystem with
well-defined interfaces and concrete specifications for acceptance tests?
-
Team organization: Agile development emphasizes
interaction and collaboration, which makes communication about
architecture an important issue. Teams need to come up
with effective ways for communicating architectural
decisions within a team or across multiple teams,
geographical locations, and time zones.
-
Understandable architectures and information overload:
Architecture-centric practices may sometimes
lead to software architecture that is
excessively complex, while agile methods may
help keep things simple - reducing the
potential for cognitive overload in systems
development and maintenance.
-
Long-term evolution: An architecture-centric
process can be most useful when a software
product will have a series of planned
changes over the product's lifecycle. In
mature products, this cycle might even include a
one-time radical re-architecting of the system.
How can we define architectural roadmaps that will be agile
enough and yet support planned evolution?
-
Architecture evaluation: In an agile
approach, the developers are constantly
aligning the system value proposition to customer's
needs. In mature or large scale products with minimal
or inaccurate documentation, this might be cumbersomeo
and dangerous.
What are the minimal set of documented artifacts and
processes that are required in order to maintain
a "hands-on" agile grip on the architecture, enough
to sustain architectural decision-making?
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
Are you
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 -
alcatel-lucent.com. (The original position paper
due date was September 4, 2009 -- but we will still accept
position papers until September 30. But please contact
Dennis Mancl by email as soon as possible to confirm your interest.).
- The position papers were 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
architecture process.
- Or, you might also describe some specific problems that
you encountered in an agile software project because of inadequate
architectural planning.
- 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.
The workshop is organized as a
set of interactive brainstorming and discussion sessions. The
workshop participants will prepare a poster to present at the
OOPSLA poster session on Monday afternoon.
Workshop committee:
- Dennis Mancl (mancl - AT - alcatel-lucent.com)
- Ethan Hadar (ethan.hadar - AT - ca.com)
- Irit Hadar (hadari - AT - mis.haifa.ac.il)
- Bill Opdyke (opdyke - AT - acm.org)
- Steve Fraser (sdfraser - AT - acm.org)
Link to the original workshop proposal: architecture_agile.pdf
Position Papers
The following position papers have been submitted to this workshop:
Extra material
Other useful articles to read before the workshop:
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,"
Agile 2007)
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
testing
- 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: October 21, 2009