Thursday, 6 June 2013

TOGAF principles for an imperfect world

The Open Group Architecture Framework (TOGAF) is a marvellous thing in its way. Recently, after many years of working as an ICT solution architect, I've qualified as a TOGAF practitioner. But TOGAF has such an air of lofty other-worldliness about it that I can’t resist presenting the following little case study.

On a desert island, a technical project manager, an ordinary solution architect, and a TOGAF specialist are marooned. They have the means of making fire, they have a tin of beans to eat, but they have no tin opener. 
The technical project manager remembers a bit of school science, and proposes immediate action: “Let’s build a fire. Then we’ll put the tin on the fire. After a while, the beans will boil, and the tin will explode. Then we’ll have cooked the beans and opened the tin. Simple!”
The ordinary solution architect spots the flaw in that plan straight away: “No, no, the beans will all go in the sand. See, here I have an old umbrella that I salvaged from a previous project. Just when the beans are going to explode, we’ll hold the umbrella over the fire. Then we’ll catch the beans in the umbrella, quickly turn it the other way up, and we can eat them. That’ll be £500, please.”
But the TOGAF specialist was wiser: “No, no, that’s not going to conform to any sensible architectural principles, is it? What we need to do is this: we shall assume a tin opener.”

But I don’t want to be negative about TOGAF. It’s a good idea, really. It just isn’t quite as grounded in everyday life as it might be. TOGAF wisely says that it’s a good thing for architecture work to be governed by more or less constant principles. TOGAF goes on to define a ‘for example’ set of twenty-one principles. They’re all very worthy: things like “service orientation” and “primacy of principles”. I’d just like to offer some more grounded architectural principles, to supplement the airy grandeur of TOGAF. Here’s the first one.

TOGAF++: Principle 22: Delivery above all else


Delivering a solution architecture in time to meet the market opportunity is more important than any other principle.


All architecture products are intended to address market opportunities, even if the market is internal to an organization. An architecture product that’s delivered too late to enable the organization to address the opportunity effectively would be as bad as having no architecture product at all.


Where there are insufficient resources to deliver architecture products that comply with an organization’s architectural principles and in time to enable the organization to get to market in good time, it is necessary to deliberately break as many architectural principles as is needful.

Similarly, it can be necessary to deliberately omit as many architectural design processes as is needful.

A probable outcome is that the resulting architectural products will be sub-optimal (for example, inefficient, incomplete or unmaintainable). That is usually an acceptable cost of meeting the market opportunity, but the organization just needs to be made aware of it.

(More pedestrian principles will follow in later blogs, I hope.)

1 comment:

JDB said...

In Politics and the English Language, George Orwell gives 5 rules to "cure the decadence of our language":

1. Never use a metaphor, simile or other figure of speech which you are used to seeing in print.

2. Never use a long word where a short one will do.

3. If it is possible to cut a word out, always cut it out.

4. Never use the passive where you can use the active.

5. Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.

And then a 6th rule: "break any of these rules sooner than say something outright barbarous".

Perhaps TOGAF should consider Coming Up for Air.

Post a Comment