Rethinking Zachman – replying to Michael Ellyett

Michael Ellyett brought up some very good points in his comments on rethinking Zachman and TOGAF. The reply is going to have to be long, so I’ll put a ‘More’ link in at this point. 🙂

On EA overall:

You need to be clear that by – “enterprise-architecture” – I think you mean the design of the enterprise i.e. not the design of ICT systems. Unfortunately I don’t think a lot of people practicing in EA focus beyond ICT. In fact many sadly seem to think EA an extension of CASE (and will immediately start talking design oriented modelling languages like UML, ER).

Yup, exactly. Huge problems are created whenever a key term is ‘hijacked’ by a self-selected sub-group who constrain the broader natural meaning of the term to the far narrower scope of their own interest, and mangle all related terms as a result. For one painful example, look at ‘business-architecture’, in which high-level strategy is frequently muddled together with operations-level processes and everything in between, just because IT folks use the term as generalised grab-bag for “anything not-IT”. (And just don’t get me going on my hobby-horse of the hijacking of the term ‘domestic violence‘, or we’ll be here all night… ::wrygrin:: )

The catch is that there really isn’t any other term for what we do than ‘enterprise architecture’. To try to get round this ‘poisoning’ of the term, I’ve been positioning EA as a support-function for an enterprise-wide programme-management office (PMO) – but we really need somehow to reclaim that term from IT. Any suggestions on how to do this would be gratefully received… ‘cos until we do, much of our market and marketing is screwed… 🙁

Zachman doesn’t have a columns suited presentation/interfacing – because it developed in 1987 (when systems had a very different audiences, purposes and mechanisms for systems and user interfaces). These problems become increasingly acute… [snip]

True, Zachman doesn’t have a column for interfaces – but it shouldn’t have one, because ‘interface’ is not a primitive but a composite (usually of Who and How).

You’re right, the problems will indeed “become increasingly acute” if people try to use Zachman as a solutions framework, and hence ‘need’ to shoehorn extra columns and/or rows into a structure that’s simply not designed to take it. (Various examples around, but I have of course lost the links: Michael’s argument for a ‘presentation’ column will do for now.) Similar “acute” problems will inevitably arise if people try to cram composites into a single cell – a problem compounded by Zachman’s unfortunate definition of the Why/motivation column as a composite (“ends / means” is Why + How) and inappropriate constraints on the What and Who columns (as “data” and “people” respectively). The problem’s compounded again by the way that several toolsets – Casewise, Holocentric and Telelogic System Architect come to mind – use the Zachman grid as a main or even their only front-end for model-selection: this is valid enough for column-based models such as data-architecture, but definitely not for inherent composites such as process-models. Troux Metis‘ MEAF [pdf] framework handles it better, with multiple ‘domains’ to guide viewpoints and views, but unfortunately it doesn’t really provide any means to distinguish between primitives and composites, or for that matter (as with most toolsets) between the layers of responsibility and abstraction.

These days Zachman himself pushes the line that “primitive models are architecture; composite models are implementations” (ref: course-material from Zachman’s current seminar “The Business Case For Enterprise Architecture” – no online link available). I think he’s right: we need the primitives for the architecture, but they’re no damn use on their own for implementation; likewise we need to be damn careful not to try to do architecture with composites. We need both; and we need to use both correctly, in their correct contexts.

Let’s have no illusions on this: Zachman’s framework, on its own, is utterly useless for implementations. It’s not a CASE tool, or even a CASE framework: on its own, it cannot, and must not, be used, for solution-design. It’s an architectural tool, to model primitives, to provide anchors for compliance and for root-level impact-analysis, and to enable us to restructure the composites we need. That’s its only purpose: and as with any other tool, if we use it in the wrong way, we really can’t complain when the “problems become increasingly acute…” 🙂

Ironically location is becoming more important for other reasons. Likewise the who column is used for most of the control mechanisms (oriented around security) – because in 87 many forms of attacks where essentially not possible on the closed systems of the day.

Yup – and note how this in itself illustrates the importance of separating primitives (the taxonomy) from composites (the implementations). If we get the taxonomy right, it doesn’t change – and it provides a stable reference and checklist through which we can assess contexts that are in constant flux. Without this, we’re stuck with trying to make sense of a changing world via things that themselves are changing all the time – a surefire recipe for failure, illustrated all too well by IT’s track-record to date. Hence my hammering on about the low-level taxonomy: boring to many, I know, but all too important if we want to get our systems to work.

TOGAF’s audience and adherents are usually oriented at ICT and don’t usually purport to go beyond it. TOGAF illustrates its orientation by looking a lot like a CASE method (Cf. RUP), and not very much like a business planning method.

Yup, agreed about original-TOGAF’s ICT bias (‘obsession’ is probably more accurate…). Which is precisely why I redesigned it – particularly Phases A to D, because Phases E to H do align quite well to the usual principles for “a business planning method”.

What TOGAF fails to do most critically is put the control of the primitives and composites under their natural owners (who are almost always not the people doing the EA work)

Really important point: agreed. And identifying the owners via the primitives also identifies the stakeholders who need to be engaged in the respective architectural reviews: more on that in another post, ‘cos using Zachman as a framework for this mapping not only shows just how complex the ‘owner’-relationships really are, but also helps us to manage it.

i.e. it doesn’t focus on establishning mechanisms to allow the EA knowledge to be naturally accrete with out any additional cost to the enterprise (which is how successful knowlege bases operate). This requires adjustments to processes that produce/consume the knowledge. The result of EA is not an aftefact/document (Cf. Encyclopedia Britannica) – it is really a library (a knowledge base Cf. Wikipedia)

The original-TOGAF lumbers us with the ‘encyclopaedia’ approach, which is immensely time-consuming, and usually out-of-date and irrelevant by the time we’ve finally finished. But the restructure of TOGAF’s Phases A to D does allow us to take the ‘wikipedia’ approach and “naturally accrete” the knowledge, Agile-style, through many small, context-specific, context-dependent iterations. The catch is that to make that work, we first need an overall framework in which to categorise and maintain the content from our iterations – hence the need for something like the amended-Zachman that I’ve been developing here. Without that underlying framework, we’ll end up up with an unstructured muddle of impressions and images and nothing to link them together in new ways for repurpose and re-use. (Much like Wikipediaitself, if we’re not damn careful: easy to spend hours wandering the trails of connections and still get nothing done! 🙂 )

Agree with you also on the business role of the architecture: these days I describe EA as a way of capturing, structuring and re-using “the organisation’s knowledge of itself”.

A related issue is that none of the knowledge above can be managed in documents (Word, Powerpoint, Visio, stone slabs or papyrus etc.). It may be presented as/in documents – but that is a different issue. In well over a decade in this area I have never seen an organisation achieve an EA using documents that is: maintainable, accessible, current, accurate, affordable, etc.

What you’re talking about here, I think, is the need for a repository-based toolset to do EA modelling and linking. Agreed – in fact I would take it one step further than most of the toolsets at present, and say that an EA toolset on its own is almost useless (cf. Michiel Malotaux’s comment about ‘paper generators’) unless it’s also anchored into governance and programme-management processes, and provides automated links for traceability with governance and/or programme-management ‘products’ such as requirements respoitory, issues register, risk register, glossary, thesaurus and the like.

No one would today attempt far simpler modelling tasks i.e. with 3-4 primitives e.g. ER modelling, project planning – without the benefit of a knowledge modelling system. Zachman et al suggest not 3-5 primitives (as per project plans) but 30-50+. Another issue is that one uses the term architecture and in all other areas of complex design (PCBs/electronics, planes/trains/cars, cities/buildings, organisations/processes etc.) the need for visual representations is well recognised

To be useful for as a support for real-world solution design, a fully populated Zachman-style framework should contain not just a few tens of primitives, but tens of thousands of primitives, each linked not just to the composites in which they’re used (and re-used over time – another issue in itself), but to the respective ‘owners’ at each Zachman level, the respective policies, procedures, regulations, strategies, and on and on and on and on. No-one in their right mind would even think of trying to tackle that level of complexity without a visual tool which also allows arbitrary context-specific views into the overall ‘phase-space’ within the repository.

It’s not just the visuals: it’s the connections that are most important. The primitives and the composites are always relevant: but it’s from the connections between them that the meaning will arise. Again, more on that in another blog-post. Somewhen. When sanity permits. 🙂

But yeah, thanks, Michael: this has really helped. Collectively, we really do need to get clarity on these – and to reclaim our industry from the IT-types, too.