Spot the difference (short version)

“How do I loathe thee, TOGAF? Let me count the ways…”

Okay, maybe not quite that bad – and, to be fair, TOGAF does have definite valid uses. But an enterprise-architecture framework, in the literal sense of ‘the architecture of the enterprise’? Definitely not.

To illustrate the point, let’s play a quick game of ‘Spot The Difference‘…

Let’s first have a quick check of the criteria for a framework that could actually work at a true whole-of-enterprise scope:

  • It needs to be able to cover any scope and context.
  • It needs to be able to work on any subsets of the overall scope, whilst still retaining full connection to that overall scope.
  • It needs to be able to work with and develop for often-extreme uncertainty.
  • It needs to support the full range from big-picture to detail-level, and from vision and strategy to implementation and operation.
  • It needs to support continuous-learning and continuous improvement.
  • In a business-sense, it needs to support real business-value.

Given that list, let’s play Spot The Difference on the TOGAF ADM, versus an alternate methodology that follows what, on the surface, might seem to be the same structure:

(Click on the graphic to expand it, if need be.)

No doubt you’ve noticed all of the differences. But have you noticed why the differences exist, and what they imply in practice?

The graphic on the left summarises a method – the standard TOGAF9 ADM, or Architecture Development Method. And as a method, it works best with precisely one type of context. To be specific, a context which:

  • needs a large-scale, multi-year programme of change (Phase A)
  • applies to business-concerns that centre solely or primarily around IT (Phases B, C, D)
  • changes are built primarily around waterfall-type projects (Phases E, F, G)
  • do not need to concern themselves with benefits-realisation or lessons-learned (absent in Phase H)
  • the only information-items needed in an architecture-repository are change-requirements

Implicit from the arrows on the graphic is that it can be used in a non-linear way – though this is barely described in the documentation, with no actual instructions on how to do it.

The graphic on the right summarises a metamethod. And as a metamethod, it can be used to create context-specific methods for any type of scope and context – including (though with a sort of matrix-inversion in Phases B, C, D) the TOGAF ADM itself. The key differences are:

  • identifies the scope, duration and purpose of each cycle (Phase A)
  • identifies and describes the needs and changes for the context, as per the identified scope (Phases B, C, D)
  • changes are built around recursive/iterative change, enabled via scope-reassessment in Phase A (Phases E, F, G)
  • emphasises benefits-realisation and lessons-learned as well as context-review (Phase H)
  • all architectural-information will need to be managed via the repository

Implicit from the arrows on the graphic is that it can likewise be used in a non-linear way – but also fully-recursive, via the structure of Phases A to D.

(To be pedantic, the graphic on the right is itself an instance of a metametamethod for continuous-change and continuous-improvement. of which, for example, PDCA, OODA and the classic Tuckman ‘Group Dynamics’ project-cycle are other instances.)

Nothing much wrong with having a method that only works well with one type of scope and context, of course – as long as that scope and context are all it’d be used for.

The catch is that, courtesy of the hype-machine that is behind TOGAF these days, the graphic on the left is insistently marketed and ‘sold’ as if it’s the graphic on the right – as if the tiny subset of scope that it can cover is all that anyone would ever need in enterprise-architecture. Which it isn’t. Which, since it can’t actually handle anything more than a very narrow type of scope – because that scope is hardwired right into its very structure – makes life very difficult indeed for those of us who do work at wider scopes and the rest of that list of criteria near the start of this post, and have to spend inordinate effort tidying up the TOGAF-created mess.

Why do I loathe thee, TOGAF? Let me count the ways…” Well, that above is just one of the ways, one of the ‘whys’, that drives me to really loathe TOGAF at times. And yes, there are plenty of others, as you see in the full version of this post, coming soon…

1 Comment on “Spot the difference (short version)

  1. Tom

    The method on the right looks much better!! Thanks for the thinking and effort to produce it.

    I have previously undertaken a comparison of the “method” that I apply to architecture assignments, to identify gaps in my method or gaps in the TOGAF method (which identified far more gaps in TOGAF than in mine – I know you will be so surprised to hear that!).

    I propose to do the same between the alternate method you have outlined and mine, to see what gaps / issues might be identified as a means of improvement of either method. First step for me is that I will consideration to the “cycle” that I might articulate within the TOGAF ADM metastructure (ie. entry point plus eight step cycle).

Leave a Reply

Your email address will not be published. Required fields are marked *