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?

This entry was posted in Agile & Architecture, Thoughts on the World. Bookmark the permalink.

3 Responses to What Do I Mean by "Agile Architecture"?

  1. Hi, Andrew,

    Thanks for your comments. It looks like you read only a little of the book. I am a bit impatient with someone who publicly denigrates a work after reading just beyond the cover, but I trust your readers are smart enough to figure that out.

    Lean Architecture has a significant component called DCI: data, context, and interactions. It’s the brainchild of Trygve Reenskaug who invented Model-View-Contoller as well. Both MVC and DCI exist to support interactions between the end user and the system under construction. DCI facilitates easy introduction of new use cases in a way that is impossible with contemporary object-orientation. I think that’s what you’re looking for. It’s in the book. You have to get beyond the back cover. And it might be beyond some people. I’ll be watching to see if you ever make it.

    Unless you’re using a Humpty Dumpty definition of Agile, the Agile Manifesto is a good reference for the phrase. The number one provision of the Manifesto is “individuals and interactions over processes and tools.” The number one goal of Lean architecture is, and always has been, an “agile product.” The heart of an agile product is these interactions with end users. The second is working software: an architecture that can be understood is more likely to be right than one that is validated largely with testing. By giving explicit voice to use cases in the architecture, we support the second provision of the Agile values. Third, customer collaboration is everything focusing on end-user mental models. And, last, we want the end user to be in control of system evolution evolution that takes place along the natural shear lines of the system.

    When we laid the foundations for Agile we had people in mind. Number one is the end user. But programmers are people, too, and good architecture should make life easy for them. The original object vision didn’t separate these two.

    In your analysis above, you got one out of four. The Lean Architecture book goes deeply into all three. And I know you haven’t read the whole book, so you’re forgiven for your ignorance at this point. But if you read ahead to section 8.1.2, which develops a historic argument about why Agile with the four provisions of its values are relevant to today’s interactive systems in a way that they weren’t relevant to systems in the past. Even some contemporary systems don’t lend themselves to the Agile mindset, even if they have the property of being maintainable. To equate Agile with only “responding to change” is a caricature, though it seems to be your opinion. And in this piece, it’s an unsubstantiated opinion at that. I can Lean Architecture, and particularly its Agile component, is deeply human.

    This is at the heart of object orientation. Alan Kay created the Dynabook the precursor of object-orientation as a platform that children themselves could program. It takes a good architecture to do that. As Kay extemporises, such a system should actively support the creation and incorporation of “operational models” by the end user. Lean Architecture calls these “end user mental models.” Lean Architecture takes its cue from that ideology. It takes the experience one expects of an architect to understand that. One of the most important concepts in the whole book is the emphasised phrase in Section 8.1: There exists a fundamental, deep and incestuous relationship between Agile, object orientation, and Model-View-Controller-User. That’s because it’s all about end user.

  2. Pattern-chaser says:

    James Coplien has proved himself over years in our industry. That doesn’t mean to say that everything he says and does is right, only that he has earned our careful consideration of his work before we dismiss it. I think you may have ‘rushed to judgment’, as you put it.

    Is your point simply that the term “agile” is being used and abused throughout the software universe? The abuse and over-use of “agile” is lamentable, but not news.

  3. Andrew says:

    I think there has been a bit of a “rush to judgement” on both sides here. I will finish reading James and Gertrud’s book, and I promise to post a fair review based on a complete read when I have done so. I did acknowledge that this was just a “first impression”, and I will correct myself publicly if that first impression turns out to be incorrect.

    However on the other side it would be good if those commenting took time to review my long-standing work to try and advance the understanding of the relationship between “agile” and “architecture”, rather than accusing me of getting everything wrong just to make a quick profit, as has been stated on Twitter. That’s certainly not my intention.

    I absolutely understand the need for putting people at the centre of software development, and I’d hope my other writings make this very clear. However in terms of the agility of the architecture, things may not be quite that simple. I have seen agile developments generate systems which are not able to “respond to change”. I have seen classical developments generate systems which respond to change very well. My point is that to some extend the agility of the architecture is independent of the agility of the process, and I remain convinced (for now) that this is the case.

Leave a Reply

Your email address will not be published. Required fields are marked *