Six Principles of Agile Architecture (Part 1)

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.


One thought on “Six Principles of Agile Architecture (Part 1)

  1. Hi Dean,

    This looks like it will be a very interesting series of posts. At the beginning of this introduction you mention that architects, VPs, CTOs have a contribution to make and then in principle #1 you say that the teams that code the system design the system. I look forward to seeing what you have to say about how those go together. Are you saying that an architect has to be part of many teams or does it mean that they should establish a good relationship with the Agile teams such that the Agile teams naturally consult with the architect as they work on the design?

    I’m also interested to see how this plays out with the frequent statement of “architects must code.”

    FYI, I am a CTO who is also a product owner and I rarely write code these days.

    You and your readers may also be interested in participating in the new Agile Reddit: .


    P.S. – I really enjoyed reading your book.

    Note from Dean Leffingwell:
    Thanks Damon. With respect to:
    “Are you saying that an architect has to be part of many teams or does it mean that they should establish a good relationship with the Agile teams such that the Agile teams naturally consult with the architect as they work on the design?”

    Both of these models make sense to me. (or maybe its really one model: the architect is part of (many) teams and as a team member with a substantive contribution to make, teams will naturally “pull” from the architect rather than “receive” as perhaps they did in the past)

    It seems that you are an agile architect. What is your experience and perspective on this topic?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s