Rethinking Zachman – the 'Who' column

Next in the columns of the amended Zachman framework is ‘Who‘.

Presumptuous of me, perhaps, but from my understanding of what the framework is aiming to achieve, this is one place where Zachman made a serious mistake in his taxonomy, and has kept on compounding the resultant problems ever since.

The ‘Who’ label sort-of fits, and gives a nice symmetry, of course; but describing the content as ‘people‘ – as Zachman does – is dangerously misleading. The actual content is closer to ‘Which’, or closer again to ‘By Whom’ or even ‘By What’, because what’s needed as the primitive here is capabilities, usually clustered into sets as roles and their responsibilities. The catch is that the role is still abstract: to bring it to life, so to speak, it needs to be linked in a composite with an appropriate ‘What’ – in other words as the agent, a term that Zachman does occasionally use for this column.

The point is that the agent can be anything active: the ‘What’ for the composite with ‘Who’ may be a person (relational), but it might equally be a machine (physical) or a software application (virtual). Linking an agent (Who + What) to a function (How) is what makes a process possible – as indicated, for example, by the swimlanes in a BPMN process-model, or the actor and use-case in a UML use-case model.

In order to model abstract-services, or the complex trade-offs between manual, machine and IT-based services required for process-reengineering, we need to keep the functions (How) distinct from the capabilities (Who, and the capabilities separate and distinct from any implementor (What) for those capabilities. So describing the content of this column as ‘Who’ – or worse, as ‘people’ – does create a risk of unnecessary confusion, by bundling together a composite of distinct primitives (Who + What) into a kind of ‘pseudo-primitive’ of the agent – and only human agents at that. Worse again, in the most common variant of the framework, Zachman compounds the difficulties by describing the primitive here as ‘relationships between people and work’ – which is actually a muddled composite of any combination of Who, What»relational and How. So although – for sanity’s sake – we’re best to leave the column-label unchanged, as ‘Who’, we do need to keep reminding ourselves regularly as to what it really represents.

I’ll admit I’m still struggling somewhat with the segment definitions here, because the boundaries seem a bit blurred whichever way I cut it. It’s easy to see that specific capabilities apply to the physical, virtual and relational domains from the What and How columns, for example; but most real-world roles – clusters of capabilities – require a combination across these segments. Perhaps a better cut, which does map indirectly to What and How but rather more closely to Why, is on what we might call skill-levels, drawn in part from the Cynefin model of organisational complexity:

• rule-based (Cynefin ‘known’ domain; aligns with physical segments): no choice or judgment permitted, hence little to no true skill (i.e. training only); real-time or near-real-time only, and strictly causal; may be implemented by machines, IT or people (the latter usually under protest, from incipient boredom!)
• analytic (Cynefin ‘knowable’ domain; aligns with virtual segments): some judgement required, with choices amongst variously complicated paths, which may include delays and disconnects in time, but still modelled in terms of assumed cause-effect relationships; cannot be implemented by machines without IT-based or human support
• heuristic (Cynefin ‘complex’ domain; aligns with relational segments): true skills, judgement always required – ‘probe / sense / respond’, in Cynefin terms – to assess patterns in contexts with high uncertainties, limited statistical probabilities , complex delay-loops and/or unknown or unidentified factors; apparent cause-effect patterns may only be identified retrospectively; cannot be implemented by machines or conventional IT-based systems without human support
• principle-based (Cynefin ‘chaotic’ domain; aligns with aspirational and/or abstract segments): very high skill-levels, extreme and inherent uncertainty in real-time or near-real-time; no cause-effect patterns identifiable (e.g. ‘market of one’); can only be implemented by humans

The key advantage of this cut is that it clarifies the kinds of What can be combined with a Who capability-set to create the respective agent: trying to set up an IT system to implement principle-based capabilities is asking for trouble, for example, though too many system-designs that I’ve seen over the years have implicitly made that mistake… It also helps to clarify the difference between responsibility in the sense of agency, and responsibility in the sense of accountability – because action and oversight often require different skill-levels for the same nominal business-function.

Right now there’s no obvious notation that can be used for modelling the many-to-many relationships between capabilities and roles. The nearest equivalent would be data entity-relationship diagrams, with roles as entities and capabilities as attributes; but this doesn’t quite capture the semantic independence of the capabilities themselves, nor the implied skill-levels. Suggestions welcome on this: an exercise for the student, perhaps? 🙂

To summarise, then, the appropriate primitive for the Who column is not ‘people’, as in the original Zachman, but capability, usually linked with other capabilities into one or more abstract roles.