Agile Architecture

I’ve read my fair share of Agile literature and listened to the likes of Kent Beck and Mary Poppendieck.  And like many others I’ve been impressed at a project level.  At an architectural level, I’ve always had this nagging doubt that an agile process may not lead to an agile architecture.  For the purposes of this post, an agile architecture is one that accommodates change easily.  Before I go any further, let me say that the result of many years of non-agile processes has left many organisations with architectures that are anything but agile.

What has created the current architectures that aren’t agile? There’s a couple of possibilities.  The first is a resistance to change.  A waterfall process can lead to a false sense of stability and a rigid focus.  In this environment, in which the customer is punished for changing their mind, the architect may be encouraged to focus on the project and resist change – just like the process resists change.  The second is a lack of a joined up approach.  If every project is delivered individually without overall coordination, chaos ensues.  Systems will take different views of data, they may use different terminology and they may be built with divergent technology.  In this unplanned world with no standards, architecture is accidental and agility is an unlikely happenstance.

The temptation, of course, is to overplan and overthink.  We can identify the errors of the past as not having considered the whole and, thus, overcompensate by trying to accommodate every eventuality.  But this way leads to inertia and madness.  As Yogi Berra (might have) said, "It’s hard to make predictions, especially about the future."  George Orwell wrote: "People can only foresee the future when it conincides with their wishes, and the most grossly obvious facts can be ignored when they are unwelcome." And in this thought we can see the error of those who think that the best way to predict the future is to invent it.  For an architect, this aphorism is tempting but inverts responsibilities since it leads to the architect imposing future requirements upon the stakeholders.

So what’s the solution?  Well, first off having a clearly communicated vision for the application, enterprise and, subsequently, architecture is a pretty good start.  Secondly, knowing that change is inevitable means that the architect will realise that what is certain today may be questioned tomorrow and overturned the day after.  Thirdly, you need standards and coordination across projects (my favourite metaphor for this is town planning – the town planners don’t know what the future holds but if they’re worth their salt they’ll plan in such a way as to accommodate change as best they can.)  Of course, these standards themselves will need to change.  This coordination of projects and standards implies a healthy governance process (think planning permission.)  Finally, there needs to be a clear and concise statement of the principles underlying the architecture.

Here’s what some other people think about agile architecture:

Scott Ambler
Paul Browne
The Agile Architect

What do you think?