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
• Position Papers
• Extra material
• Workshop final report
• report on architect duties and skills (from an ICSE 2008 workshop)
• Workshop raw notes
• Notes from the "Architcture in an Agile World" Panel session

Workshop Overview

This is the website for the OOPSLA workshop on software product development issues.

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:

1. Contact one of the workshop organizers listed below.
2. 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.

• 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)

Position Papers

The following position papers have been submitted to this workshop:

• Position paper submitted by Ethan Hadar: Agile Evolution of Information Systems
• Position paper submitted by George Fairbanks: Risk-centric Software Architecture (also see one page summary)
• Short position statement by Dennis Mancl: Dennis Mancl position

Extra material

Other useful articles to read before the workshop:

• Agile Architecture: Strategies for Scaling Agile Development by Scott Ambler
• Agile Enterprise Architecture by Scott Ambler
• Software Architecture and Agile Software Development - An Oxymoron? by Philippe Kruchten
• Agile Architect by Philippe Kruchten
• Is Design Dead? by Martin Fowler (see the section "Growing an Architecture")
• Agilists and Architects: Allies not Adversaries talk by Rebecca Parsons and Martin Fowler
• Extending an architecture as it earns business value by Alistair Cockburn
• The Scatology of Agile Architecture by Robert Martin
• Second Generation Agile Software Development by Randy Miller
• Agile Architecting by Erik Philippus
• Evolutionary architecture and emergent design by Neal Ford
• Agile Architecture is not Fragile Architecture by James Coplien and Kevlin Henney (video)
• Handling Architecture in the Agile World by James Coplien (video)
• Once and Only Once balances YAGNI by Ron Jeffries and others (wiki)
• Field Study of the Software Design Process for Large Systems by Ralph Johnson and others (wiki)
• The eXtreme Programming (XP) Metaphor and Software Architecture by James Herbsleb, David Root, and James Tomayko
• eXtreme Programming Meets UML by Alan Cameron Wills
• Scaling Up Agility: The Architected Agile Approach by Barry Boehm (talk abstract for JAOO 2009)
• Agile Architecture or Accidental Architecture by Kirk Knoernschild
• Virtual panel session on architecture documentation with Grady Booch, Len Bass, Paulo Merson, and Eoin Woods

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