20 January 2010

Agile Architecture – Some Random Musings

In a recent blog post entitled "Enterprise Architecture - The big catch up" James Gardner (a.k.a. Bankervision) posed the question “How did you get your architecture ahead of project’s demands for it?” and invited those with direct experience to contribute. This is of course a subject dear to my heart, and I duly posted my comments. I have since received numerous requests to post my comments as an article directly on my blog, and so here they are (with minimal editing).

Less is More
Rapid development of architecture in order to stay ahead of the project demand curve is a common dilemma, and one which I believe it is essential for all architects to understand (and more importantly to solve). Bankervision moots decentralization as one possible solution, and I would certainly agree that this can accelerate generation of content. Decentralisation on its own, however, does create its own problem in that the more people you have contributing to a common model, the more work is required to rationalise the result and avoid conflicts and contradictions (which in themselves give the appearance of an incomplete architecture and we are back to the original problem).

For me the real answer here is to have less architects, not more, but it is essential to ensure that they are extremely strong characters with a wide range of experience and the courage and confidence to make the necessary decisions quickly in the absence of hard data. They also need to be brave enough to get it wrong as a mistake in architecture is visible to all. (The fear of being seen to be wrong is a character trait that an architect cannot afford to have).

These strong architects need to have a deep understanding of the world of projects and delivery. They need to have experienced it for themselves in order to know what a project wants and what it doesn't want. (A project wants hard answers and ready-made solutions, not vague ideas and lengthy documents). Give them 80% of what they need and they will have time to help you fill in the other 20% (and so the architecture becomes more complete). People don't mind the gaps as long as the bits that are there are of true value to them (and most importantly make their jobs easier).

Now - this doesn't mean you don't involve a greater community in the production of the architecture. A good architect will be talking to a wide variety of people both inside and outside your organisation, and will have their fingers in many pies. They will already know much of what is required and will be able to talk directly to the people who will give them the information they need.

The Crowd versus the Committee
One concrete example of community involvement in architecture is in the Business Architecture I produced in my current role mentoring a newly formed Business Architecture.

Here, in a nutshell is how we did it:

We brought together a variety of people from across the organisation into a hotel for two days with the remit to "Create the Business Architecture" (They of course didn't believe this could be done, but were hoping to plan out how to do it).

I facilitated the two days and on day one put up a straw man domain model for the business based on their core value chain (from their vision/strategy papers) and invited them to tear it down and rebuild it.

Free discussion and copious post-its gave us their version. (Coffee was, of course consumed in large quantity, and the Danish pastries helped enormously).

In the afternoon we had open discussion (arguments?) in which everyone was invited to add to the model the services they as a business wanted to provide to their customers in the future. We asked them to think to the future (an aspirational date of 2015 was used) and be as unconstrained and inventive as they could be (regular reminders were required to ensure this future focus was maintained). The big question was "What would you like to do!" not "What do you do today" or "What do you think can be done". The constant reminder was "Don't worry if it can be done or not - let us worry about that later"

We then looked at what we had as a group to remove duplicates, resolve conflicts and reach a consensus.

By the end of the second day we had the big picture.

We had a single sheet of paper on which the entire business could be clearly seen, in language familiar to the business. There were no gaping holes around the edges as we did not get shoehorned into focussing on the core services in detail to the exclusion of everything else, and we had a happy (if very tired) consensus around the table that we had a picture of how we would all like the business to look in the future.

We also had a framework that would allow individuals to work on the detail of each service without having to worry about the whole, and in the full knowledge that their work would fit neatly into the jigsaw.

Most importantly, we had created the belief in all those involved that architecture was something you could do (and benefit from) extremely quickly and that decisions were there to be made then and there, not to be passed to a committee to discuss.

This BA has now received wide acclaim across the organisation and has been used successfully and in anger on more than one occasion.

Are there gaps? Of course there are, but these no longer seem to matter. People are seeing the value, getting excited about it, and seeing the opportunity to help us to fill in the gaps as a positive thing.

And Finally... Some Tweets
James’ post also prompted some related tweets from myself, which I include here for completeness:
An architect should always have the answer (even if they're not sure its right ;-)
An architecture should be crowd-sourced, not designed by committee. The architect is filter, scribe, diplomat and evangelist.
Everyone has thoughts, ideas and opinions - it is the job of the architect to condense these into deliverable answers.
The Enterprising Architect