TOGAF and SDLC

Another item from the LinkedIn conversations.

We’d been having a detailed discussion on the internal structure of TOGAF 9, when the following comment came from one of the other participants:

“I see TOGAF 9 as an SDLC method with a bit of knowledge management. Am I missing something?”

It was clearly meant as a snarky putdown, but it’s worthwhile answering at face value.

TOGAF is a method, a framework and various other components that, together, form a quality-system.

As a metaphor, or a very approximate analogy, every quality-system is “an SDLC method with a bit of knowledge management”. COBIT is. So is ITIL, Deming’s PDCA, ISO-900x, Six Sigma, the US Army’s ‘After Action Review’, and many many other examples.

Beyond the metaphor, TOGAF is a (much larger) superset of “an SDLC method with a bit of knowledge management”. In some cases software may be involved in the end-result, but it’s not about development of software as such – it’s about development of the enterprise as whole (hence ‘enterprise architecture’, not ‘software architecture’). There is quite a bit of knowledge involved, but also a strong emphasis on business purpose (i.e. emotional/relational/aspirational, not virtual), and also on dialogue, emergence and ecosystems – i.e. proactive rather than solely reactive.

When assessing the quality concerns within a quality-system itself, the devil is in the detail. Hence there’d been a lot of reference to detail in that LinkedIn thread [and hence the putdown – he couldn’t be bothered to read the detail, so he decided to heckle instead]. Once we’ve identified and cleaned up the flaws and inconsistencies in the detail, we can simplify, clarify: simplicity is a desirable characteristic for an SDLC-like quality-system.

At the end, we’re after simplicity without being simplistic. Describing TOGAF as “an SDLC method with a bit of knowledge management” is a usefully simple analogy; but unless there is awareness of the detail behind that simplicity, it risks being dangerously simplistic.

By analogy, trying to build a house with virtual bricks and imaginary girders is not a good idea: looks good on paper, perhaps, but doesn’t work in practice. Likewise, trying to develop an enterprise with a software-development method is not a good idea. That’s the real distinction here.