Jiri’s Notepad

This is the fourth part in the series on architecture governance of projects. The first installment introduced the subject, second part spoke about accountability and the third part was about organisation structures.

I find it strange that people spend so much time discussing things like REST and Web Services and virtually no-one really talks about who should be ‘doing the architecture’. I mention this because some of the most persistent arguments I have had in the past were not about the solution, functionality or technology, but about who should be doing what. I find it strange but there is always someone who is willing to spend more time arguing about this than doing actual work. The larger the project or organisation, the more likely you are going to meet someone like this.

Defined responsibility is important, not only because it can help neutralise people like this; it also helps improve the efficiency of delivery and quality of the solution to be delivered. The following quote from the Power of Product Integrity (paid-for registration required) sums up the essence for me.

“Companies that consistently develop successful products - products with integrity - are themselves coherent and integrated. Moreover, this coherence is distinguishable not just at the level of structure and strategy but also, and more important, at the level of day to day work and individual understanding�

Architecture is often mistaken for design, which is understandeable considering the similarities between those two.  But this similarity also gives rise to a potentially dangerous misconception, which is that architecture done only during the stage immediately preceding design. In reality, there are few more stages before design in the solution lifecycle and architecture has a place in each of them.

When I was thinking about this recently, I realised there is an interesting anomaly in our language. We often talk about the architecture, as if it was a single compact thing. Yet in reality,  there are several architecture document developed at different stages in the lifecycle, each serving a different purpose:

• Problem exploration: What could we do differently in our business?
• Feasibility: How could a potential business and technical solution work, what budget should we set up for it?
• Scope: What is the scope of the solution to be delivered?
• Design: How should the solution work?

So rather than a single architecture document, you are likely going to have a set of powerpoint presentations, requests for proposal, solution scope and requirements documents, all of which make up the evolvoling solution architecture.

Who is responsible for architecture, anyway?

In large organisations, architects may specialise not only according to the technology or part of the ISO stack but also according to the lifecycle stages. This makes sense because different stages in the life-cycle require skill-sets (for more detail see the summary of the discussions from some time ago on whether architects should code). Assuming your architects do specialise in this way, you are likely to have three teams responsible for architecture: enterprise architecture team, often aligned with the ‘corporate’; programme/business unit architects team and project architects.

In this model, the answer to the question ‘who should do it’ is relatively simple:

Of course, reality blurs up this rather pretty model - some people like to see projects throughout the lifecycle. Quite a few of my fellow architects turn they nose up at ‘delivery’, but I personally think it is important to eat your own dogfood. Personal accountability for the end product is the best cure to the ivory tower syndrome. Secondement is the way to deal with this kind of situation.

Something’s missing!

This is the second category of ‘interesting’ discussions you are likely to have as a practicing architect. To decide on whether something is really missing, we need to define what should be the content of the architecture.

To start this exploration, it seems natural this should be defined in one of the architecture frameworks. Surprisingly, it is not the case. Let’s take, for instance TOGAF (see an overview at Sjaak Laan’s weblog), which strikes me as one of the more pragmatic frameworks.  It defines three stages to the architecture effort: business, information systems, technology architecture. In fact, I find term ’stages’ misleading, because they are not aligned with the normal stages in the IT lifecycle. In reality all three architectures - business, information syste, technology one - are developed or addressed to varying degree during all architecture-relevant solution lifecycle stages. It would be probably more fitting calling them ‘aspects’ than ’stages’.

Normally, it is the level of detail of the architecture that changes alongside the lifecycle stages. In other words, architecture moves down a level of abstraction in each progressive lifecycle stage, from “why” to “what” to “how” and finally to “with what”.

So the level of detail as well as responsibility can be roughly illustrated as follows:

If you think this is complicated, just spare a thought on possible project paths through the matrix of B, IS, T/why, what, how, with what. Complexity can be mind boggling as long as you forget that such frameworks cannot are more like a signpost on a desert trip, rather than a GPS navigator. So any frameworks really need to be tempered by listening and responding to your customer.

Conclusion

Structuring the delivery lifecycle and defining the criteria for architecture deliverables for individual solution life-cycle stages helps efficient delivery. The larger your organisation or project, the more important it becomes. But don’t hold my breath thinking it will change people and turn your Wallies into hard working motivated geniuses. That’s why it is better to start with people and only then add governance.