Skip to content

Strategy And Tactics And Architecture

A chance meeting with a friend this evening got me thinking…

He was undertaking (enthusiastically, it seems) TOGAF training. It was the end of the day and he seemed a little worn down. Not surprising really, he faces a herculean task.

The TOGAF version 9 book proudly announces announces it is 780 pages long:

And that’s just the framework!

I gather that the idea is he will become a “TOGAF Thought Leader” and can champion the roll out of TOGAF throughout the organisation.

It is assumed that things will improve when everyone can speak the same language about their architectural plans.

This got me musing:

[*1]

What? You didn’t catch that?

Oh well. Maybe you should take some Chinese Training. Then you can become a “Chinese Thought Leader” and can champion the roll out of Chinese throughout your organisation. Things are bound to improve once everyone can speak Chinese. [*2]

No?

Surprised?

The TOGAF approach is rooted in the time when we hoped that open standards would prevail. In this nirvana we were all running OSF/1 (distributed via ANDF, naturally) and programming in Ada.

Today’s world isn’t like that. We have brought down upon ourselves an increasing number of OSs, a plethora of different languages, some good interoperability technologies, and vendors that work both assiduously and insidiously to subvert any semblance of neutrality to ensure that their clients are locked in to their product set.

Here’s the hard truth from our industry’s history: you can strategise all you want but you won’t succeed unless you retain tactical flexibility.

IMHO, these days one should focus hard on tactics, not strategy. You can achieve something tactically, but the war is never ending (and thus can’t be won).

To put it another way (paraphrasing Helmuth von Moltke the Elder): No battle plan ever survives contact with the enemy.

More is not better. If your framework on its own amounts to 780 dense pages, you have simply no chance.
Your clients won’t understand it. Your team won’t follow it. Your vendors won’t tolerate it.

There is but one single Critical Success Factor here: simplicity.

KISS. It’s your only chance.

You can’t have a single all-encompassing architecture. You can’t expect everyone to get on board. The world will not stand still–you won’t even have time to formulate the Grand Plan.

Darn but this ‘architecture’ idea is soooo seductive though isn’t it: maybe it’ll all work this time

Not going to happen, though.

To get back to military terms…the strategy has been decided: you are already in the war; you now must focus on constantly adapting your tactics.

Gotta say I feel a bit sorry for my friend! The organisation under whose flag he labours was established precisely on the promise that it will control his clients’ worlds and guide them to a well-designed, static and completely regulated nirvana.

For them, there is no politically accepable alternative.

For them, Agile Architecture just isn’t possible.

And yet history shows us it probably is the only thing that might be useful, not to say appropriate.

A losing battle, if ever there was one.

[*1]: Maybe any problems you are having with your architechure aren’t actually related to the langauge being used to describe said architecture.

[*2]: I’m actually all in favour of learning Chinese…

C, Java Enterprise Edition, JEE, J2EE, JBoss, Application Server, Glassfish, JavaServer Pages, JSP, Tag Libraries, Servlets, Enterprise Java Beans, EJB, Java Messaging Service JMS, BEA Weblogic, JBoss, Application Servers, Spring Framework, Groovy, Grails, Griffon, GPars, GAnt, Spock, Gradle, Seam, Open Source, Service Oriented Architectures, SOA, Java 2 Standard Edition, J2SE, Eclipse, Intellij, Oracle Service Bus, OSB