More on Zachman and capability

This is in effect a continuation of the previous post on Zachman and capability, following on from some further comments on Microsoft architect Nick Malik’s original post on business-capability.

Nick kindly described my comments as ‘extremely interesting’, and perhaps even more kindly remarked that:

Your model is the first honest attempt I’ve seen to remove “Actors” from the ZF [Zachman Framework] and replace that column with Capabilities under the notion of “Who.”

He was concerned, though, that changing Zachman’s ‘Who’ to ‘Capability’ means that we then lock out what Zachman also parks under ‘who’, namely organisational structures:

I’d be concerned about your approach, however, because you leave no room for the combination of organizational structures with other architectural elements, because you replaced the organizational structures with capabilities.

But from my view he doesn’t need to worry, because organisational structures are in the wrong place anyway in Zachman: the correct place is under ‘Location’ – Zachman’s ‘Where’. Or that’s part of it, at least. The point is that organisational structures are kludged into ‘Who’ in Zachman because his model is missing an entire dimension (or more than one, in fact). We need to resolve this absence before we can make sense of org-structures in a Zachman-like taxonomy. The main ‘extra dimension’ that I use relates to asset-categories:

• physical (‘things’)
• virtual (e.g. information)
• relational (e.g. links between people and/or groups of people)
• aspirational (e.g. brand, morale, purpose)
• abstract (‘none of the above’, such as finance)

In essence, an organisational structure is a map of relationships between relational locations (i.e. ‘where : relational’ links), in much the sense sense that a physical network is represented by a map of relationships between physical locations. That’s the primitive, but we more often see it as a member of a broader composite: for example, a business-unit is typically a composite of ‘where : relational’ and ‘capability + function’ (i.e. ‘service’). Any change to any of the underlying primitives will change the composite, and hence – in that example – the role, purpose and placement of the business-unit.

Nick expressed some concerns about the relationships between primitives and composites, especially in relation to capabilities:

You have correctly stated that capabilities need to be combined with other things to be interesting, and that “molecules can be based on simpler molecules, in the same way that DNA is based on simple molecules.”

Just as you can take a molecule and add an atom to produce another molecule, I believe that you can take a capability and add a relationship to an architectural primitive and get another interesting composite.

But, can we say that capabilities are, or are not, constructed from existing primitives?  That’s an interesting problem, and one that I don’t have an easy answer for.  Just as the effort to move up or down a row in the ZF is more of a transformation than a construct, is it possible that the capability is a construction that sits on a fictional row, above row zero, that represents not one owner’s viewpoint, but ANY owner’s viewpoint?  That, in fact, the capability is a transformation above a composition of people and process?

To me this stems from a slight misunderstanding about the roles of primitives versus composites in architecture: we need to resolve back to primitives in order to understand our options for re-use and redesign, yet almost everything in the real world will be some kind of composite.

For example, on its own a ‘capability’ is almost meaningless: until it’s combined with a function (Zachman ‘How’) into a service, it literally has no function. But by modelling capabilities separately, as distinct primitives, we enable alternate combinations of capability and function to give different effective services (and hence support different processes). This also gives us a better understanding of what’s needed when we substitute one capability for another whilst maintaining the same nominal function, such as in process-reengineering or disaster-recovery.

To me, capability is a nominal primitive, though it has some characteristics of a kind of ‘compound-primitive’. On one side is the asset-type(s) to which it applies: physical, virtual, relational, aspirational, abstract, or any combination of these. (For example, a sales-capability applies primarily to relational assets, but is usually linked to other asset-categories as well – information, brand, product and so on.) On the other side is what we might call the ‘skill-level’: rule-based, analytic, heuristic and principle-based. Crucially, machines are only well-suited to the first skill-level, and IT to the first and second; IT can be used for decision-support (but not decision-making) in the third; and is all but unusable in the fourth. Capability-modelling allows us to determine the extent to which IT should and should not be used in a given context, and what human skills will be needed to fill in the gaps.

I would agree that any move up and down the Zachman rows is a transformation rather than a construct. As described in the framework summary – http://tetradianbooks.com/2008/12/silos-frame-ref/ – each row upward is another level of abstraction, and each row downward adds another component to the modelling-requirements. The vertical dimension is also in effect a spectrum of time, from nominally infinite (row-0) to unchangeable past (row-6). So the same nominal ‘capability’ can be viewed in multiple ways, sometimes as “one owner’s viewpoint”, sometimes “ANY owner’s viewpoint”, depending on the chosen level of abstraction – much as the multiple perspectives in data-modelling, from business to logical to physical and so on.

I do take Nick’s point that we could view a (business) capability as “a transformation above a composition of people and process”. Yet if we do so, we’re actually using the same word – capability – to mean two very different things: a primitive of “ability to act on something” (hence ‘capability‘), contrasted with the complex composite of people, business structure, business-relation, function, process, service and capability that we would describe as “the capabilities and role of a business unit”. We can get away with such blurrings in everyday business conversations, perhaps, but we can’t do so in a taxonomy for enterprise-architecture: we need the precision of proper usage of terms, or we’ll end up in an unworkable tangle.

Nick also dropped in a final comment about dimensionality of a taxonomy:

IMHO: The only real limitation of the ZF is the arbitrary notion that any three dimensional representation has to be in the shape of a cube.

I don’t agree that we have to presume a cube (or equivalent ‘pure’ n-dimensional structure) for an architecture taxonomy. For example, the modified Zachman I use is more like a wedge: that ‘asset-categories’ dimension (physical, virtual, relational and so on) is crucially important at the real-world levels (rows 5-6), but we deliberately focus and de-focus on those categories in reviewing the logical-to-physical trade-offs (rows 3-4), whilst the categories are often almost irrelevant in the true abstract layers (rows 0-2).

Some of these points might sound pernickety – as indeed they probably are for basic-level IT-architecture in information-centric industries, for which Zachman’s simple two-dimensional overview is probably adequate enough. But once we extend the architecture to other industries or contexts that deal more with other types of assets – such as manufacturing, logistics, sales, defence – we must cover the full range, or we end up with an artificially restricted scope that is riddled with gaps labelled ‘Magic Happens Here’, because we have no means to describe what needs to occur there.

This also applies to any business-oriented view of IT-architecture, such as SOA, security-architecture or Enterprise 2.0, or enterprise-scale uptake of cloud-computing capabilities. A true enterprise architecture is the architecture of the enterprise as a whole – not solely the architecture of the enterprise IT.