My Life As A Blog

Agile Architecture

with 4 comments

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?


Written by remark

February 19, 2008 at 10:37 pm

4 Responses

Subscribe to comments with RSS.

  1. Interesting one, I’ve been following a couple of threads on this myself recently.

    My current thinking is that Lean principles such as deferring the decision until the last responsible moment, XP practices, as well as basic principles such as YAGNI need to be considered carefully here.

    Your point relating to the need for a vision is an important one though. I think that it is the responsibility of an Architect to understand the vision for a product and to understand the standards in place at their respective company. However, they should (though as you suggest are forced in some respects by processes in place to do otherwise) allow the overall design / implementation to evolve and in that, take on a slightly different role, that of somebody that works closely with the developer to ensure that they understand the vision of how a product should be delivered from an Architectural stand point and to work to inform those of why the decision should or should not be taken to implement one way or another.

    I think I agree with you, whether this would work in practice, indeed if you could actually get an Architect to work in this way is what I am unsure of though.

    Hope all is well with you.


    February 20, 2008 at 11:26 am

  2. Dan,

    Thanks for your comments. Very interesting. What do think is blocking architects from working to create agile architectures?


    February 20, 2008 at 1:33 pm

  3. I’m not suggesting there is anything blocking them necessarily, I think that for them to be able to work in an Agile manner, there is a need for change (as is the case for any other role within an Agile team) and that in the case of an Architect, this has the potential to have slightly more impact than other roles that make up the team.

    I think in some respects, Lead Developers could do more on an Agile project and that the role of Architect needs to be re-focussed more towards the Enterprise so that they hold the vision not only for how any company will create products but also understand where the integration points between the products are.

    I guess put simply, they’re going to need to be less precious about the design as it stands at any given time and understand that it needs to be allowed to evolve to suit the development teams needs at any given time.


    February 22, 2008 at 10:54 am

  4. Ok, so I think we have a small difference in perspective. I would stress the agility of the architecture more than the agility of the process (i.e. the end is more important than the means.) The other issue where we may differ is addressing the dissonance between the project’s needs and the needs of the enterprise. I would suggest favouring the general (i.e. the enterprise) over the local. Of course, this does assume that there is such a thing as “the enterprise” and that it has articulated, understood needs – and I appreciate that this is not always the case.

    On your point about Lead Developers and Architects, I think there’s a danger of us talking at cross purposes. The subject of role definition is very important, but it’s not one I had intended to cover in my post. I guess I’m saying that the architecture exists regardless of who creates it. What I am interested in is if that architecture is itself agile – and whether an agile process guarantees an agile architecture (my opinion being that it doesn’t.)

    Good to have a discussion on this, so thanks for commenting.


    February 22, 2008 at 1:14 pm

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

%d bloggers like this: