Zachman and capability

An interesting (well, interesting to me, anyway 🙂 ) enterprise-architecture discussion on the position of ‘capability’ in the Zachman framework.

This was triggered by a post by Microsoft architect Nick Malik: “Why Business Capabilities Are Not In The Zachman Framework”. (My thanks to Bart Leeten for the initial link.) Nick uses the common analogy with the Periodic Table of the Elements to point out – correctly – that there’s no primitive for ‘capability’ in Zachman (though he doesn’t actually explain why…). The result, as Malik warns, is that some architects think that there’s no need to model capabilities:

But here’s the rub: business capabilities do not appear in the Zachman framework.  This causes confusion among new architects first learning the Zachman framework.  The confusion goes like this: If the ZF is comprehensive, and defines everything that an architect needs, then why does an Enterprise Architect need a capability?  Are capabilities non-architectural?  Should the notion of capability mapping be disregarded by Enterprise Architects because capabilities are not part of the comprehensive Zachman framework?  Should the development of a taxonomy of capabilities be considered a pointless exercise because it isn’t architectural?

As he explains, capabilities are an essential part of architecture: “capability hierarchies are necessary, nay, essential to modern Enterprise Architecture”. From here, though, he draws the conclusion that because ‘capability’ isn’t a primitive in Zachman, it must therefore be a composite, and that we should necessarily model it as a composite: “are business capabilities part of enterprise architecture, even though they cannot be seen on the Zachman framework?  Yes.  For the same reason that molecules are part of chemistry.”

But one possibility he doesn’t seem to consider is that Zachman is just plain wrong. It’s not a viable taxonomy: the rows – ‘Owner’, ‘Designer’, ‘Builder’ and so on – make practical sense, but for the columns he starts with a set of interrogatives – ‘What’, ‘How’, ‘Where’, ‘When’, ‘Who’, ‘Why’ – and then seemingly hunts around at random finding real-world things that vaguely align with those interrogatives. The result is a kludge that sort-of works for a basic and now rather out-dated approach to IT-architecture, but falls apart as soon as we try to use it as a proper structural taxonomy – a ‘Periodic Table of Elements’ for any true enterprise-scope architecture.

Others have pointed out some of these problems: Jean-Paul Vooght, for example, commented on Twitter that Zachman “misses intra-row cross-tables”, whilst CapGemini’s Mike Turner was a bit more sardonic:

Zachman vs business capability is a bit like “why doesn’t my 8-track have I-pod docking station?”

But the problem here isn’t that Zachman is outdated, like an 8-track tape-player: it’s that it’s structurally flawed. To make it work, we need to replace the crude interrogatives with proper taxonomic categories. As I’ve described elsewhere, my recommendation for the respective categories is as follows:

• Asset (‘what’)
• Function (‘how’)
• Location (‘where’)
• Capability (‘who’)
• Event (‘when’)
• Decision/Reason (‘why’)

Each of these ‘column’-categories will crosslink to a set of Zachman-like rows and at least one other distinct dimension of action-categories – physical (‘things’ etc), virtual (information etc), relational (people etc), aspirational (brand, morale etc) and abstract (finance etc). For capabilities, we need to add crosslinks to another set of categories, for skill-levels: rule-based, analytic, heuristic, and principle-based. Linking capabilities to functions defines services; a business-process is a choreographed pathway through sequences of services; and so on.

A ‘business capability’ can be either the same as ‘capability’ in this sense, or merged with organisational structure (in essence, a map of relational locations) as the capability of a business-unit, and so on: the term is often too blurry to be usable reliably within an architecture taxonomy. But by layering different composites of the underlying primitives, we can build up different views of the enterprise that enable us to describe whatever structures may be needed.

So yes, ‘capability’ is not part of Zachman; but Zachman is not usable anyway – not for enterprise architecture, at any rate. We need a better, more robust taxonomy than Zachman to describe the context and scope of each aspect of an enterprise and its architecture.