Tom Graves / Tetradian

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.

This one’s a pick-up from a ‘tweet’ by Colin Wheeler, replying to John Polgreen:

Depends on the true definition of each. One person said to me that there is no business without information, one and same.

Red-rag-to-bull time for me: in effect that “one person” is saying that business is only information, which is about as insanely IT-centric as one can get. So yes, I exploded:

“business=information” is VERY dangerous! business = transactions + conversations + relations + purpose

…which in classic Twitter style is probably too compressed and cryptic to make any sense at all… oh well. But worth expanding on here.

The line about “transactions + conversations + relations + purpose” is an expansion on the old Cluetrain tag-line that “markets are conversations”, using a crosslink to the ancient ‘four dimensions’ of physical, virtual, relational and aspirational that I use in most of my work on enterprise architecture (EA):

• physical ‘things’
• virtual information and imagined space
• relations between people
• aspirations for individual and shared purpose

Transactions may be physical, virtual, relational etc; conversations are a composite of virtual information and relations between people; and so on, and so on. The architecture of the enterprise must support every required combination of these themes.

But classic ‘enterprise architecture’ strips all of this down to a tiny subset: the small segment that can be handled exclusively by IT systems. It then turns this round, and says that business is computer-based information – hence the IT-centric delusion that IT is the sole centre of the business world. It’s true that we can just-about get away with this delusion when the business genuinely is information-centric – as in insurance, finance or banking – but even then it’s all too easy to forget about the other dimensions, as the banks did when they set out to dismiss the relational aspects of business by closing all their retail branches, and then wondered why they had no customers left… sure, it produced significant short-term savings but very nearly at a cost of killing the business. Not wise… In any other industry, from aviation to logistics to manufacturing to retail to utilities to pharma to telco to… well, anything, really… that IT-centric delusion means that the resultant EA rapidly becomes worse than useless: its blinkered view actively hinders the development of the business, because it all but ignores anything other than IT-based information. Which, right now, is precisely why so many organisations are challenging the value of their EA. Not wise, on either side…

So there’s a general warning here to every architect. If someone says “no business without information”, they’re right: information is an essential aspect of business – though it may come in many different forms, from conversations to scraps of paper to ideas drifting in from the aether as well as in electronic records sitting in a data-centre or on a screen. But whenever anyone throws in an exclusional rider, such as “no business without information, one and same” – that business is only information – that should set alarm-bells ringing straight away. The business and its architecture always involve all of the dimensions – physical, virtual, relational, aspirational – all of them, interweaving, always. Anyone who says otherwise is deluding themselves, and others, trying to take some over-simplified ‘easy way’ such as IT-centrism that always works out to be harder in the long run. You have been warned!