What Do I Mean by "Agile Architecture"?

A little while back I was approached by EITA Global, a global provider of on-line training, and we have now agreed that I should present for them a webinar entitled "Agile Architects, and Agile Architecture". The current plan is for this run on 8th April. I’ll keep you all posted with any changes.

As part of my preparation, I decided to do a literature scan to see how this topic may have moved on since the last time I did some significant work on it, a couple of years ago. I have to say that based on my initial research I’m not that impressed… I don’t know whether to be flattered or slightly perturbed that AgileArchitect.org comes up squarely at the top of a Google search. There are a few decent web articles around, although most are several years old and I’d seen them before. The Google search also turns up several dead links.

Amazon turned up a couple of loosely-related books, and the most obvious candidate appeared to be "Lean Architecture: for Agile Software Development" by James O. Coplien and Gertrud Bj�rnvig. I’ve now read a couple of chapters, but my first impression is not very favourable. I may be rushing to judgement, in which case I’ll apologise later, but the book seems to somehow equate "architecture" with "code structure" with "project structure", which isn’t right at all, missing a number of the most important dimensions of any true architecture.

This led me to ask myself a very basic question. "What do I mean by ‘Agile Architecture’?". In Coplien and Bj�rnvig’s book they seem to answer "an architecture which facilitates agile development". That may be one definition, but it isn’t mine.

I think the confusion arises from the difference between "agile" applied to a process (e.g. software development), and applied to a product. In the former case, the Agile Manifesto undoubtedly applies. In the latter, I’m not so sure. I think that for a product, and especially its architecture, the primary meaning of "agile" must be "able to respond to change". The larger the change which can be handled quickly and cheaply, the more agile the architecture. An architecture which has been built in a beautifully run agile project but which needs new code the first time a business rule changes is fragile, not agile. The system which can absorb major changes in the business rules without a single line of code is genuinely agile. The integration architecture which allows multi-million pound system A to be upgraded with no impact on adjacent multi-million pound system B, or which allows the company to be restructured just by re-configuring its services, is the most agile of all.

I’m slightly worried that "agile" may have become a "reserved word", and this "architecture in the large" definition may run counter to accepted practice. Is that right, or am I reading too much into a few examples?