Cleaning up the TOGAF ADM

Yes, I know, I’m overdoing the posts at the moment… but it does seem to be relevant, though.

This one’s about the following Twitter exchange between myself (‘@tetradian’) and TOGAF training-specialist John Polgreen, starting from the Colin Wheeler ‘tweet’ discussed in my previous post:

• colinpwheeler Depends on the true definition of each. One person said to me that there is no business without information, one and same.
• tetradian “business=information” is VERY dangerous! business = transactions + conversations + relations + purpose
• JohnPolgreen the point here is that we’ve put the emphasis on the IT side of EA for too long, now we must see business and IT holistically.
• tetradian yes – IT is only 1 part of 1 dimension of business, but popular b/c it gives desired illusion of control
• JohnPolgreen back to TOGAF – what can we do to shore up Phases A and B to help create a more holistic approach to EA?
• tetradian we don’t ‘shore up’ TOGAF Phases A/B, we drop the idea of only 4 architectures – see http://bit.ly/Rl6tm
• JohnPolgreen what about a decision point after Phase A – light IT, your modified ADM; heavy IT, old ADM w shored up B

…at which point it’s clear we need to switch to an explanation that won’t fit in Twitter’s 140-character limit! 🙂

There’s a confusion here about the role of the initial stage in an architecture-cycle (TOGAF’s ‘Phase A’), caused by TOGAF’s inherent IT-centrism and its muddled notions about what an iteration is and does – blurring Waterfall and Agile styles in a way that really doesn’t work.

Classic TOGAF (version 8 or 9 – they’re essentially the same here) confuses the structure of the EA cycle – the iteration Phases, which are essentially a pair of interlinked quality-management cycles – with the content of the EA cycle – its scope and business-question. That’s what I aimed to resolve in the cleaned-up ADM.

The architecture method is a means to address any architecture-related business-question. In effect, TOGAF’s existing structure presumes that any business-questions to be addressed will be IT-related – hence John’s ‘heavy IT’. In particular, it presumes one of three possible requirements: clean up the IT-architecture, including IT-applications, IT-maintained information, and IT technology-infrastructure; identify the impact on IT of any change to business-strategy or compliance requirements; and use reviews of the technology / IT landscape to suggest and drive changes to business practice.

But it needs to be understood – hammered home, in fact – that this is only a small subset of enterprise architecture. As it stands, TOGAF may be IT-heavy, but it’s still EA-light. As I’ve described in my books – especially in Doing Enterprise Architecture – the real scope for EA is much broader. Yet once we understand that it is broader, paradoxically, we can also make the cycle structure much simpler. We drop any assumptions about a fixed scope (TOGAF’s Phases B, C1, C2 and D). We drop any assumptions about the scale and duration of the cycle (which shunts much of TOGAF’s Phase A into the special-purpose iteration represented by TOGAF’s Preliminary Phase). We drop any assumptions about the necessary scope and scale of implementations (simplifying TOGAF’s process-heavy Phases E to G). We drop any technology-centric assumptions about the final benefits-realisation / lessons-learned assessment (TOGAF’s Phase H). And we simplify the whole thing by using a classic IT trick: we make it recursive, allowing cycles within cycles within cycles, all under exactly the same governance rules.

Once we do this, it becomes clear that TOGAF is a special-case worked-example of the use of an enterprise architecture method, in which there are specific sub-cycles to address the detail of the required business-issues, manual-process issues, application and data concerns, and technology-infrastructure changes needed to address a specific type of business-question. So there’s no need for “a decision point after Phase A – light IT, your modified ADM; heavy IT, old ADM w shored up B” – more to the point, to do so would introduce unnecessary complications, enshrining unnecessary special handling for what is actually not a particularly especial case. Instead, the scope, the stakeholders and the overall assessment approach are all specified within Phase A.

Once you fully grasp that point – that TOGAF’s Phases B, C and D are simply examples of usages of a generic assessment-process which compares required or actual conditions at specified time-horizons, to derive change-requirements – it simplifies the whole procedure right down. There is no ‘light IT’ versus ‘heavy IT’: some architectural concerns may involve no IT, but it’s all the same architecture development process. We start with four straightforward questions:

• what things?
• what information?
• what relations with and between people?
• for what purpose?

…and build the architecture outward from there.

TOGAF complicates things unnecessarily. Keep it generic; keep control of any unwanted, unwarranted special-cases arising from unfounded assumptions such as IT-centrism; keep it simple, keep it simple, keep it simple. That’s why I keep pushing and pushing for a simpler, broader approach to enterprise architecture: because that’s what works.