A question of Who

Back at the launch of TOGAF 9, some eighteen months ago, one of the Open Group leads took me aside to a quiet corner of the hall. He looked around, as if to make sure that none of his colleagues could overhear. “You know what’s missing in TOGAF?” he said, in a near whisper. “People. There’s nowhere for people anywhere in the architecture.”

And he’s right: there isn’t. But it’s not just TOGAF: it’s the same with just about every other mainstream ‘enterprise’-architecture framework. Unlike TOGAF, the FEAF PRM does include a placeholder for what it calls ‘People’ or ‘Human Capital’ – but in essence does nothing with it. The Oracle EA Framework [PDF] includes a section called ‘People, Process, Tools’ – but it’s only about the people who do the architecture work, not the people within the architecture itself. CapGemini’s Integrated Architecture Framework covers What, How and With What – but there’s no mention of Who. (Oh, unless you look in the respective ‘Business Architecture’ sections, which in essence, as usual, are a jumbled-up, meaningless, unusable grab-bag of ‘anything not-IT that might impact on IT’.)

The only mainstream architecture-framework that does explicitly include people is the granddaddy of them all: Zachman. The original version, it’s true, only addressed What, How and Where; but the first revision, completing Kipling’s set of ‘Six Honest Serving Men‘, did make a point of emphasising the importance of Who.

The problem, as I’ve explained elsewhere, is that Zachman’s structure doesn’t really work in practice. Sure, it looks good, it’s easy to read, and those six interrogatives make immediate sense (in English, at least, if not always in other languages). But despite Zachman’s own insistence that the framework covers the whole enterprise, the examples given are all for IT only; it’s based on a metaphor of ‘engineering the enterprise’ that almost by definition cannot work in any real human enterprise; and it’s actually missing an entire dimension – distinctions between fundamental asset-categories and the like – without which it cannot be made to make sense for key architecture-concerns such as implementation trade-offs, load-balancing and disaster-recovery.

Back about three years ago I did a lot of work on ‘Rethinking Zachman‘, ending up with a revised taxonomy-framework that looked like this:

I’ve continued to tweak the various labels since then, and they’re still not quite settled, but the current single-row version that I’ve used in my ‘Enterprise Canvas‘ series looks like this:

The point here is that there are at least five fundamentally different things going on around ‘Who’:

• what the person does – which is what I’ve labelled ‘Capabilities’
• how we connect with the person – which is what I’ve labelled ‘relational Asset’
• how people (or roles) relate with each other, in terms of organisational structures etc – which is what I’ve labelled ‘relational Location’
• what each person is responsible for – which is part-implied here in ‘Decisions’, but is better described in a crossmap with a RACI matrix or equivalent
• who the person is – which isn’t described here

To me, Zachman’s ‘Who’ is a muddled mixture of all of these, which we can sort-of get away with as long as we can safely assume that people and IT and machines each do entirely different things. In terms of skill-levels, each of those groups tend to work on different things, too: machines follow simple rules, IT can also use algorithms, and people tend to be asked to take over for anything that the machines and IT can’t do. But if we use Zachman’s ‘Who’-merge, if there’s a context where they do all have to do the same things – such as when real people have to take over IT-type tasks, in disaster-recovery or the like – we suddenly find that we have no way to describe what’s actually going on. Hence we do need to rework the taxonomy and ontology, to put all of these different items in their respective places.

(The ‘Who’-merge kludge sort-of works because, within IT and machines, function and capability are structurally merged – so at first glance it can seem that we don’t have to assess them separately. Unfortunately, for architectural abstraction and redesign, we do need to treat them as separate: function uses assets, which are acted on by capability, which when linked together provides service, which when linked together provides process, and so on – all of which items can, may or should be interchangeable according to context and need.)

In principle, part of that exclusion of actual people from the frame is deliberate:  people are not assets or ‘units of production’ or whatever, but are themselves as themselves. (The relationship that an organisation has with a real person is an asset – and an extremely important asset at that, which needs to be maintained as an asset.) If we treat people as assets, we find ourselves straight back into the worst of Taylorism, regarding people as interchangeable objects – which is not a good idea.

(There’s also a danger, though, that describing capabilities separate from people would again lead us back into Taylorist temptations. We build capabilities into machines and IT, and those capabilities are [usually!] distinct and definable, associated with the entity-type as itself – the entity does the function using the capability. Each entity of that type is interchangeable with any other – in principle, anyway. But real people carry or express or enact or whatever a very complex mixture of capabilities: in terms of those capabilities, each person is different from any other – and even different from themselves, varying day to day, or even from moment to moment – so they are not interchangeable in the same way. The intersection of different capabilities within each person enables and requires fundamentally different approaches as to how we structure and partition work: treating people as interchangeable ‘production-units’ with fixed capabilities and skill-levels quickly guarantees a lowest-common-denominator result, leading to very low overall effectiveness. But that’s another story requiring another very long post! 🙂 )

As a result of all of this, I tend to regard real-people as somewhat orthogonal to the architecture – they cut across it, but are not in it as such. There are a lot more places where we describe architectural themes that relate to people, and with people, and about people. Yet they’re still not in the architecture – and arguably shouldn’t be.

But the catch is this means there’s still no explicit place for people as people within the taxonomy of the architecture itself: instead, we need to describe them kind of separately-and-in-parallel-with the architecture. Yet is this a problem, in real enterprise-architecture practice? And if so, how much of a problem is it? What impacts does it have?

Suggestions/comments, please?