The no-plan Plan: people in architecture

Okay, time for the final theme in that ‘no-plan Plan‘ – which somehow seems to be turning into a kind of ‘manifesto for whole-enterprise architecture’ or something like that, for some reason. Oh well. Anyway, this part’s about what is perhaps the most-serious ‘the Forgotten’ in almost all current ‘enterprise’-architectures, namely people.

I’ll keep this one short(ish), but I can see at least four sub-themes here:

• people and enterprise
• people and story
• people as ‘actors’
• people as ‘assets’

Most of the people and enterprise sub-theme is about the ‘why‘ of the enterprise, which I’ve covered already in the ‘no-plan’ post on the ‘why of architecture. Just note that everything that’s described over there also has strong cross-links to here, that’s all.

Much the same with the people and story sub-theme: go look at the ‘no-plan’ post on ‘architecture as story‘. It’s pretty much all there: just note that all of that, almost by definition, is all about people too.

On the people as ‘actors’ sub-theme, I think of this as how people are engaged in the doing of an enterprise, and thence to what people do within an organisation. A few thin fragments of this are already covered in mainstream ‘enterprise’-architecture, such as ‘actors’ in use-cases, or clunkily-inadequate descriptions of ‘business services’ in Archimate and the like. It’s clear, though, that we’ll need a whole lot more than that if we’re going to get the enterprise-architecture to work well. A few examples:

• roles and responsibilities: who does what, who makes the decisions, and how and why and when do they do this?
• end-to-end processes: what happens in the largely non-automatable ‘Barely Repeatable Process‘ components of end-to-end processes? how do we ensure appropriate actions and handovers between all the stages within any end-to-end process?
• load-balancing and business-continuity: what are the trade-offs between manual and automated processes? what needs to happen when (not ‘if’!) the automated processes fail? what skills and capabilities are needed to make that happen?

I’ve drifted across this thread here already from time to time – for example, see the post ‘A question of Who‘ – but it’s clear that there’s a whole lot more that’ll need to be done. A lot more. Including how to get it down into the really practical, concrete, everyday, ‘this-is-how-it-works-just-do-it’ kind of stuff. Interesting. Very. To me, anyway… 🙂

On the people as ‘assets’ sub-theme, well, yes, I admit I do have a bit of a knee-jerk response to that dreaded if usually well-meant phrase “our people are our greatest asset”… Fact is, though, that it is a real asset to have the right people hanging around in any enterprise: it’s just that we need a very different understanding of ‘asset’, and how and where and in what ways real-people fit in with that notion of ‘asset’, in order to make it all work.

The first point here, and it’s a really, really, really important point, is that people are not assets. We should never describe people as ‘assets’. (In fact, in conventional economics terms, the only context in which people could be described as ‘assets’ is when they’re slaves – which is not a good idea in most business contexts…) Instead, the relationship is the asset – not the person, but the relationship between ourselves and each person.

And that’s a real asset: we can create it, ‘read’ it (access and use it), update it, delete or destroy it, generally manage it and its lifecycle and so on, much as for any other type of asset. But the catch is that that asset only exists between two entities – which means that it can be dropped from either end, without the other end necessarily knowing that it’s gone. Which means that although it’s an asset, it does need to be maintained in a much more engaged and active way than for a physical or virtual asset such as a building or a data-record. And because it only exists ‘between’, and can be dropped by the other end at any moment, it’s not an asset that we can ever truly ‘possess’, in the same sense that’s so often used for physical-assets and for the bad-joke of so-called ‘intellectual-property’. It’s an asset, but it’s a fundamentally-different type of asset: and we forget that fact at our peril.

I’ll use a couple of diagrams to explain what’s going on here. First, we start with that tetradian – four distinct axes or ‘dimensions’ in a kind of tetrahedral relationship:

Those axes apply to pretty much everything, and they’re quite distinct from each other. For example, physical-assets – tangible ‘things’ – are what’s known as ‘alienable’: if I give it to you, I no longer have it. By contrast, virtual-assets – data, information and so on – are ‘non-alienable’: in general, if I give it to you, I still have it. Entities will often be composites of dimensions: for example, a book is both a physical-asset (the book itself) and a virtual-asset (the information in the book).

What we’re mostly concerned with here, in this sub-theme of ‘people and architecture’, is a swathe of architectural concerns around the relational and aspirational dimensions: relating with or to people in two distinct ways.

To put this into a more conventional ‘enterprise’-architecture context, take any single row from the Zachman framework – a single level of abstraction. Then tweak its ‘What, How, Where, Who, When, Why’ columns a bit so that we can use terms that actually make sense in real-world practice; and then add the tetradian-dimensions into the mix. What we end up with is the ‘single-row extended-Zachman’ checklist for service-content – the ‘service-content map’ used in Enterprise Canvas:

Conventional ‘enterprise’-architecture handles most of the ‘virtual’ row very well indeed, for IT-maintained information at least: in other words, data, functions that act on data, virtual-locations such as IP-addresses and the like, algorithms, and information-based events. It handles some of the ‘physical’ row quite well, too: in essence, if it’s an IT-box (physical-asset) or a network-infrastructure (physical-location), it wants to know about it. But to be blunt, conventional ‘EA’ varies between not-much-use, to useless, to worse-than-useless, on just about everything else. Which is a serious limitation – to say the least. (Which is why those of us who want work with whole-enterprise architecture get so darned frustrated with most of what claims to be ‘enterprise’-architecture… though that’s another story for another time.)

Relational-assets are person-to-person links between people; and not only are they non-alienable, but they’re also non-exchangeable – for example, I can’t give you my relationship with my cat, or the postman, or the guy who sells cheese in the nice corner-grocery, or anyone else. (Of course, that blunt fact doesn’t stop businesses trying to claim that they can sell you relationships, as ‘goodwill’ etc, but that’s another story too.) The point is that it’s personal – it doesn’t exist without the person – and it also exists only between individual real-people. So, a relational-function acts on relational-assets; a relational-location indicates some kind of positioning or whatever (such as the dreaded org-chart), relational-events are events that are associated with, well, relational events, and so on. It is all straightforward, once we make the jump to realising that the asset in context is the relation between people – and not the people themselves.

Aspirational-assets are person-to-abstract links – a personal sense of relationship with (or to) something abstract. In the business-context, the obvious example of this is a brand – or rather, a brand-relationship, the personal connection to brand. I’d probably best not go into any more detail here – this is supposed to be just a summary, after all – but one of the key concerns for any business here is the interweaving and trade-off between relational versus aspirational: the former connects with the person (such as an employee), which makes things happen, whilst the latter connects with the organisation, but in itself is too abstract to make anything happen at all. Anyway, long story, another time: leave it for another post, I guess. Get back to the no-plan Plan.

So, last part: architecturally speaking, the capabilities – the ability to actually do something – are always associated with some kind of asset. Some capabilities can be built into machines and software – particularly physical-capabilities and virtual-capabilities respectively. We access that kind of capability via direct access to the respective asset. But when those capabilities reside in a real-person, we can only access the capability indirectly, via a relational-asset and/or aspirational-asset. If the link with that person is lost, so is the capability. And that still applies even if the person is physically present – a condition known as ‘presenteeism’ (or one of the variants of presenteeism, anyway).

To summarise all of this: from a business-perspective, we need all kinds of people around in the enterprise, in a wide variety of roles: customer, employee, prospect, partner, whatever. There are also a whole range of other people-roles – employee-spouse, regulator, tax-auditor, anti-client, whatever – who may either seem irrelevant or we don’t want to know about, but who are in the broader shared-enterprise whether we like or not, and to whom we therefore do need to pay attention as well. All of these are relevant to a whole-enterprise architecture: and the key means by which we can model what goes on in our architecture in relation to people is through modelling those relational links – the relational- and aspirational-assets.

Okay, stop there: more for another time – a lot more, as you can see. But that’s the overall set of themes for now, anyway.

Comments, anyone?