Six Principles of Agile Architecture (Part 1)

Posted on April 2, 2008 by Dean Leffingwell in Agile Architecture

Many interesting discussions and debates about agile architecture, whether it be emergent, intentional, intentionally emergent, (or whatever!), continue as agile marches across the chasm into the enterprise. This issue gets particularly entertaining as I encounter deeply experienced and very senior architects, systems architects, VPs, CTOs and the like who have strong views about imposing architectural plans on the natural entropy of all those newly empowered and energized agile teams. Most typically, these folks are quite competent and they have the experience and authority to back it up their knowledge. More importantly, they have deep, experience-based technical insights to add to the process and it would be downright foolish of us to leave them out of the mix of what “makes an agile team a team”.

Also, the continuous refactoring of emerging-only architectures in these enterprise-class software starships becomes less and less practical as the size of the ship grows and matures (Chapter 16 of SSA). Therefore there is an understandable and reasonable desire to minimize refactoring as well as build systems of components that work in a like manner to ease usability, extensibility, performance and maintainability. These are strong and practical motivations to apply some “architectural governance” to the software development practice.

The overly simple argument of “the architecture will emerge ─ let the component teams decide” does not always go so well in some of those offices. For the reasons I’ve indicated above, some of the concernis reasonable. Other reasons include the fear of loss of control of some of the most critical, IP in the company, i.e. that which reflects an understanding of how the system works now and how it is intended to be extended over time. Whether this fear is rational or not, (and I suspect that it often is), if not addressed it will kill the agility initiative as quickly as a routine 60 hour workweek or fixed price/fixed schedule/fixed functionality mandate.

With architecture, as with all things agile, I’m reminded to return to first principles, such as the agile manifesto and the derivative works, but these works are mostly silent on the topic of enterprise-scale architecture. That’s understandable, as the methods weren’t developed for large enterprises. However, as we extend them and achieve the benefits thereto, we have to take the challenge to the next level of scale, without losing or compromising the principles that have brought us to agile success so far. To this end, I suspect that there are a set of guiding principles that we could posit to help us down this path. I’ll take a first cut at such a set in the upcoming posts in this new series: Six Principles of Agile Architecture.

Here’s the set I’m going to start with.

Principle #1 ─ The teams that code the system design the system.

Principle #2 ─ Build the simplest architecture that can possibly work.

Principle #3 ─ When in doubt, code it out.

Principle #4 ─ They build it, they test it.

Principle #5 ─ The bigger the airplane, the longer the runway.

Principle #6 ─ System architecture is a role collaboration.

I’ll elaborate further in another post later this week. As always, thoughts and comments are welcome.