Zachman and TOGAF revisited
Anyone who’s tried to use either of these ‘standards’ in real-life enterprise-architecture will know that they both have severe limitations which make them all but unusable for anything beyond a strict IT-centric view of the enterprise. Trying to use them for anything outside of that IT-centric scope – in other words, for real enterprise-architecture – is an immediate exercise in extreme frustration. Much of my work for the past year – and particularly for the past four months, for my client down in Sydney – has been to find ways to sort out the resultant mess. But since most enterprise-architects come out of the IT space, and Zachman and TOGAF are what they know, that’s where we need to start.
Zachman has six rows, representing views into the architecture space, and six columns, representing fundamentally different categories of ‘primitives’ or architecturally relevant entities. (Most real-world items are ‘composites’ – combinations of architectural primitives. Creating mappings between theoretical primitives and real-world composites can get very tangled, and way too abstract if we’re not damn careful. But I digress…) The key principle that Zachman introduces is that architecture and governance depend on primitives, whilst real-world solutions are based on composites; or, as Roger Sessions put it in a recent podcast, “the job of a developer is to introduce complexity and the job of an architect is to eliminate it”. The catch is that whilst the Zachman framework is still (just about) usable for IT development, beyond that space many of its ‘primitives’ turn out to be a muddled mess of covert composites. We need much more clarity and granularity to be able to cover the interactions of the whole enterprise, beyond the narrow constraints of IT. We also need to fix a number of subtle but extremely important mis-framings in Zachman’s core descriptions of the framework columns.
I think I’ve cracked that, as I’ll describe in a series of posts over the next few days. As a quick summary, the framework needs one extra row, a fundamental change to the meaning of one of the columns (‘Who’), and an entire new dimension to split each column into segments. More on that later, anyway.
On the TOGAF side, the only real problem is that the ADM (Architectural Design Method) is rigidly IT-centric – so much so that the label ‘Business Architecture’ is used for everything that’s not identifiably IT. And in the present TOGAF spec (version 8.1, “Enterprise Edition”), the ADM sequence of Phases assumes that the only purpose for the Method is to create or review the entire architecture: there’s no means to handle anything smaller or simpler, such as any of the routine day-to-day review and analysis work of the enterprise-architecture team. But we can make it not only usable for any scale of work, but any scope of architecture-work, just by tweaking the definitions of the first four Phases:
- Phase A:
- was: Architecture Vision – big-picture view of what the iteration aims to achieve for the entire architecture
- new: Iteration Scope – identify the core business-question being addressed, and the amended-Zachman scope to be covered in the analysis
- Phase B:
- was: Business Architecture – identify business drivers, business processes, everything outside of an IT-centric scope – a muddled mixture of high-level, mid-level and low-level Zachman layers
- new: Current-State Architecture – establish the current-state for the scope and business-issue identified in Phase A
- Phase C:
- was: Information Systems Architecture – a somewhat confused mixture of IT applications-architecture and data-architecture, mostly in the mid-levels of the Zachman framework, without much in the way of links to business concerns on their use, such as in information-architecture
- new: Future-State Architecture – establish the required future-state for the scope and business-issue identified in Phase A
- Phase D:
- was: Technology Architecture – an IT-specific subset of physical objects and functions, mostly down at the low-level regions of the Zachman framework
- new: Gap Analysis – establish the gaps between the current-state (from Phase B) and desired future-state (from Phase C), and the resultant change-requirements in relation to the scope and business-issue (from Phase A)
We then continue with the rest of the ADM, pretty much as per the original spec, moving on with Phase E “Opportunities and Solutions” to assess the requirements elicited in Phase D – but with whatever scope we needed, and for any appropriate business-issue, rather than only the sledgehammer of ‘redesign the entire architecture in order to do anything’.
The other point is that this modified cycle now maps in well with PRINCE2 and other programme/project management methodologies and governance. For example, we now have just one explicit stakeholder-review at the end of each of the Phases A to D – not the almost-random, largely-implicit stakeholder-reviews that appear from time to time in the original TOGAF spec for those Phases.
Anyway, more later. Probably sounds picky and pedantic to most people, no doubt, but I’m certain it’ll give us a means to open out the entire discipline of enterprise-architecture to a broader, more genuinely enterprise-wide scope.