QCon San Francisco 2008 - Architects & Agilists

The QCon San Francisco 2008 conference was opened with an interesting keynote by Rebecca Parsons and Martin Fowler. In their talks they addressed the often strained relationship between traditional architects and agile development and how to improve this relationship to the benefit of both the agile development team and architects. These benefits include cross-project and cross-department knowledge exchange, sharing of the architects many years of experience with the developers, and only working on the architecture that is actually needed. The first part discussed the threat of agile development to the role of traditional architects and the distrust between developers and architects. Although many of the Ivory Tower Architect stereotypes may contain a grain of truth, the cause is often not the architects themselves. Many organizations put architects in a position that makes it hard or impossible to be successful:

• Goals like achieving 30% reuse - how to measure and promote this?
• Architects are not allowed to write code - so how can the architects keep up with the latest technology?
• Architects are often outnumbered by developers 30 to 1 or more - this leaves no time for being involved with projects or mentoring of the developers.

Traditionally this leaves the architects with very few options, like specifying a reference architecture and requiring all projects to adhere to it, even when the architecture is not a good fit for the specific project. Not only does this clash with agile development, but agile development may even threaten this model. It is not surprising that this causes distrust between architects and agile teams. But this adversarial relationship is not necessary. The second part of the presentation addressed how agile development allows the architects to be successful:

• Visibility in progress by delivering working software every iteration, allowing the architect to be involved and react.
• Up-to-date specifications of functionality through automated tests.
• Extracting reusable components from working code, instead of trying to build reusable components up-front that may never be used. "After the fact" instead of "design up front" reuse.

So how can you involve the architects into the agile development process? By treating the architects as another stakeholder, just like the regular customer. The architectural requirements will need to be prioritized just like any other requirement. And requirements like "the system must be maintainable" will have to become specific and implementable, making the work of the architects more concrete and valuable.