Modelling people in enterprise-architecture

As mentioned in the previous post, one of the key characteristics of ‘crossing the chasm’ to a viable whole-of-enterprise architecture is the explicit inclusion of people. In short, we need to be able to model and map where people fit in relation to the architecture.

But there’s a catch. A big catch. People should not be ‘designed in’ to the architecture.

We can see this well in building-architecture: there, the only case where people have been literally part of the architecture is that of the anchorite in the mediaeval church. An anchorite would choose to be permanently walled into a cell that was part of the fabric of the building, to act as a spiritual anchor for the people’s faith. Somehow I don’t think we’ll be likely to find many people willing to do the same for today’s for-profit enterprises… 🙂

Yet in most building-architecture, evidently, people are everywhere. Other than in certain special-cases – the equivalent of an IT-specific ‘enterprise’-architecture, perhaps – the building and its purpose and design will centre around people, about what people do, why they do it, what the building represents to people, and so on. And the equivalent of that ‘people-centrism’ is what we need in a viable enterprise-architecture.

But if we can’t design people into the architecture itself, how do we map people within the architecture? I would suggest four key themes:

• vision and values
• relational-assets
• roles and responsibilities
• capabilities and competencies

Let’s look at each of these in some detail.

Vision and values

Conventional enterprise-architecture is not good at this. TOGAF, for example, uses the term ‘vision’ to mean a particular goal, a description of the desired ‘target state’ of the IT-architecture: it’s one valid meaning of ‘vision’, I suppose, but not much use in relation to people. Business-architecture frameworks are often less helpful: the BRG/OMG Business Motivation Model, for example, describes as a similar ‘future state’ for the organisation, but framed in terms of some kind of ghastly marketing-puff – “to be the best provider of…!” etc – that really is worse than useless in practice.

What’s needed instead is something that provides a permanent stable anchor that is also ‘greater than’ any individual or the organisation as a whole. Daniel Pink refers to this aspect of motivation in his book Drive, as ‘purpose’; this is also the sense of ‘vision’ used in the ISO9000:2000 quality system. In my own EA work – as described in the section ‘Identifying the enterprise’ in the post ‘Context-space mapping with the Enterprise Canvas‘ – I use a distinct three-part structure to define this form of vision:

• a descriptor for the content or focus for this enterprise
• some kind of action on that content or focus
• a qualifier that validates and bridges between content and action

These components may occur in any order, but all of them need to be present. The aim is to identify a short phrase that gives sufficient motivation for anyone involved to ‘want to get out of bed in the morning’ on behalf of the overall enterprise. One particularly clear example is that for the TED conferences, “ideas worth spreading”: ‘ideas’ [content]; ‘worth’ [qualifier]; ’spreading’ [action]. Note that none of these components describe the organisation at such – but do describe the focus, the area of action, and the key value-metrics which define the meaning of ’success’.

Another key point revolves around the crucial distinction between ‘organisation’ and ‘enterprise’ – because although many business-folk view their organisation as ‘the enterprise’, they’re not synonymous. As noted above, vision is also the anchor of the quality-system, and in effect the hierarchical structure of ISO9000 provides us with a useful way to clarify that distinction:

• ISO9000 ‘vision’ :: architecture ‘vision’ – anchor for the overall architecture
• ISO9000 ‘policy’ :: architecture ‘enterprise’ – loose often-dynamic affiliation, bounded by shared values and shared commitment to the vision
• ISO9000 ‘procedure’ :: architecture ‘organisation’ – formal collective entity, bounded by usually-explicit roles and responsibilities
• ISO9000 ‘work-instruction’ :: architecture ‘process’ etc – practical context-specific entity and/or activity

The point here is that the organisation is merely a means to implement the vision, in relation to the broader shared-enterprise within which the organisation exists – its supply-chain, market and broader social context. Other than in terms of its declared or implied responsibilities towards this shared-enterprise, the organisation does not ‘own’ the enterprise at all – another crucial point that is frequently misunderstood in business-architectures and business-models. The organisation does choose the shared-enterprise to which it relates and within which it operates: but having done so, it in effect commits itself to the respective vision and values – and will be assessed by other participants in the shared-enterprise in terms of those values.

Which, in turn, leads us to the centrality of values in enterprise-architectures. The values are what determine ‘success’ within the shared-enterprise, especially in the longer-term. Any for-profit business in a money-based economy needs to ‘make money’, of course, and hence concerns such as monetary profit and ‘shareholder-value’ are of real importance to such a business. But value is rarely measured solely in monetary terms within a shared-enterprise: attempting to measure ‘success’ by monetary profit alone is a sure-fire way to kill the company, especially in the longer-term – hence Michael Porter’s warning that the obsession with shareholder-value is “the Bermuda Triangle of strategy” [PDF], within which companies sink without trace. The point here is that are three distinct sets of values in play in the architecture:

• required values – the values implied by, inherent in and derived from the enterprise-vision, and against which the organisation will be assessed by the broader shared-enterprise
• espoused values – the values that the organisation purports to live by, and against which it and its members supposedly expect to be assessed
• actual values – the values that are actually expressed by the organisation and/or by individuals within the organisation, and against which actions and inactions of individuals are actually assessed, rewarded and/or punished

It is rare for these sets of values to match exactly… in fact there are often glaring disparities between them, often unconscious, yet critical all the same. One of the most difficult and politically-explosive aspects of enterprise-architecture is to map these value-sets, the disparities between them, and the practical implications and risks of those disparities, and identify appropriate means to resolve them. Difficult though it may be, this is probably one of the most essential tasks of a whole-of-enterprise architecture.

Relational-assets

People are essential to an architecture, but should never be included as such within it. To resolve this requirement, we turn to an old computing tactic: we include people not ‘by value’ – as ‘objects’ within the architecture – but ‘by reference’ – via relational assets.

That much-used phrase “our people are our greatest asset!” may be well-meant, but it’s actually an insult of the most extreme form: the only time when people are ‘assets’ is when they are slaves… Instead, the relationship is the asset: the ‘asset’ in context is the relationship that the organisation has with each other player in the shared-enterprise, not those people themselves. (This relationship is what a Customer Relationship Management system and the like should assist in maintaining, yet so very rarely does…)

As described elsewhere, I use a model in which there are four distinct categories of assets that an organisation and enterprise will need to maintain: physical (things), virtual (information), relational (real person-to-person links) and aspirational (person-to-abstract links, such as brands, beliefs, goals etc). Many real-world entities – perhaps most – are composites of these categories: a book or a video-disc, for example, is ‘thing that carries information’, and hence a composite of physical and virtual. These four categories of assets are fundamentally different: an object is alienable (if I give it to you, I no longer have it), whereas a virtual entity is non-alienable (if I give it to you, I still have it). Failure to understand these fundamental differences within an architecture will guarantee failure of that architecture: hence, for example, the inherent invalidity of media-industry business-models which try to ‘control’ virtual-only information-assets (digital-only books, music and video) as if they’re still in their old partly-physical ‘pre-digital’ form.

People are physical, yes: but they are not solely physical ‘things’, ‘units’, ‘consumers’ – even though too many employment-models and business-models seem to treat them that way.

People may be represented by information, yes: but they are not solely information-entities – even though too many CRM- and HRM-systems seem to treat them that way.

People have relationships with other people. These relationships – relational assets – are direct, and personal: they cannot be exchanged directly with anyone else.

People have relationships with emotive ideas, often an idea or image as proxy for person or for a desired memory or future (such as the relationship with someone deceased, or the aroma that brings back memories of another place and time). In a business context, such proxies include logos, brands, and the reputation of the organisation itself. These relationships – aspirational assets – are indirect, but personal: they cannot be exchanged directly with anyone else.

(The latter, by the way, is the reason why the accounting concept of ‘goodwill’, which purports that aspirational-assets can be transferred directly from one ‘owner’ to another, is only marginally better than outright fraud. In essence, the ‘goodwill’ is mostly dependent on ‘relational inertia’, the perceived physical, virtual, relational and aspirational effort required to abandon one aspirational-asset relationship and shift to another. For aspirational-assets, much of that inertia is linked to reputation, but is also dependent on the medium through which the relationships take place: for example, the ‘friction-coefficient’ of a web-relationship is far lower than that in an in-store relationship – hence one of the key drivers for the ‘dot-com bomb’…)

In the architecture, we would map real-people primarily via relational-assets and/or aspirational-assets. (Virtual-assets describe those links, but not are those links: the distinction is important! Likewise some aspects of architecture may need to describe people as if ‘things’ – for example, space-allocation in buildings, or workspace in manual-processes – but should never describe people as things: that distinction is important too…) Within the architecture, an employee ‘is’ a complex composite of many ‘sub-assets’, such as (physical) space-allocation plus (virtual) employee-record plus (relational) personal-relationships with peers and co-workers and managers and suppliers and customers and many others, plus (aspirational) sense of belonging to a team, a business-unit, an organisation, the core enterprise of the organisation, and any number of professional or other affiliations. Of these, only the physical-asset is directly exchangeable: everything else is linked to the person, not solely to the organisation.

Note also that relationships have to be maintained at both ends: the asset exists between the respective entities, not as an attribute of either of them. In effect, it exists as an asset only as long as it is maintained: and all of the usual asset-lifecycle concerns also apply to relational and aspirational assets. A customer may choose to drop the relationship – and there is nothing that the company can do directly to prevent that from happening. If strong person-to-person relationships are maintained, a customer may well follow a (former) employee to a new employer: a classic problem in consultancy organisations, for example. If there is strong aspirational attachment to a brand, there is likely to be a ‘customer revolt’ if the brand is changed or dropped’ – as in the Gap logo debacle.

So in Enterprise Canvas, for example, we would model all of these as assets of the respective primitive and/or composite types, using the single-row extended-Zachman frame:

Each asset also implies a responsibility for the asset-lifecycle of that asset: its creation, usage, maintenance and, where appropriate, destruction. (The latter being a key reason why not to refer to real-people as ‘assets’!) Responsibility, in turn, implies real-people to enact those responsibilities, either directly or by proxy. Real-people to whom the organisation must link via relational- and//or aspirational-assets… This might seem somewhat circular at first, but it does make sense once we think about it for a whole! 🙂

Roles and responsibilities

It’s not just assets that require responsibilities: in principle, every entity in the architecture should have its own ‘responsible owner’. And each of those owners, as above, is a real-person – and ultimately can only be a real-person, not an IT-system, a machine or an amorphous ‘the organisation’.

The architecture should link to each respective ‘responsible real-person’ via a relational- and/or aspirational-asset. In principle, each of these relationships should be modelled and mapped within the architecture itself. In practice, it’s huge job, requiring near-real-time links to HR systems and/or CMDB systems – so it’s unlikely anyone would attempt to do it for everything. Instead, we need to use the architecture to identify the criticality of each entity, assigning priorities appropriately. For true business-critical items, we do need to be able to identify the ‘responsible owner’ at all times; for the rest… well, we do what we can, really, guided by the usual trade-offs of diminishing-returns.

Within the organisation – where legal or similar boundaries of responsibility will usually apply – these responsibilities should typically be mapped in terms of a RACI-matrix:

• responsible – the one person formally responsible for the entity (legally a ‘delegate’ of the CEO or equivalent, who in principle has ultimate responsibility for everything in the organisation)
• assists – any number of additional people who do the actual work related to that responsibility
• consulted – other people whose work and/or responsibilities may be directly affected by any changes or status-issues associated with this entity (two-way engagement)
• informed – other people who have a ‘need to know’, such as for indirect impact on their work (one-way broadcast)

We may also need to note other categories of (non-)responsibility such as not-consulted or not-informed – for example, a senior manager who does not need to be distracted by detail-level status-changes.

Responsibilities often overlap – another set of concerns that should be identifiable via the architecture models. Some of the overlaps occur at intersections of different architectural layers or domains – for example, a senior manager having responsibility for a ‘business capability’, with operations-layer managers responsible for the underlying infrastructure, the equipment in use, the data and applications referenced by that equipment, the processes that traverse through that equipment, and then also managers for other ‘cross-cutting concerns’ such as security, safety, quality and cost-assurance. A layered architecture helps to clarify the respective boundaries of authority and responsibility, and the need for negotiation at each of those boundaries and intersections.

Note too that for many entities – especially business-critical ones – the effective ‘ownership’ and RACI-matrix will need to change often, with handovers of responsibility at each change of shift, or whenever the respective people go on vacation, or whatever. Particularly important are changeover-events such as joining or leaving a company: in particular, each person’s individual RACI-matrix must be reassessed and reassigned on exit from the organisation. Also important on exit is to ensure that relational- and aspirational-assets with each departing person are maintained as far as practicable: this forms a key link in the chain of long-term knowledge-management, and also many organisations find that maintaining an ‘alumni’-style relationship with former staff pays real dividends in both directions.

And note also that responsibility cannot simply be assigned to someone: it must be accepted and taken on by that person at a personal level, a personal commitment, otherwise it’s likely to fall back to ‘responsibility’ in name alone, with a concomitant increase in organisational risk. Again, this is where explicit linkage to enterprise vision and values can present real value to the organisation, because it provides an overt anchor for aspirational-assets – a sense of belonging, of being engaged in something ‘greater-than-self’ – that make it that much easier to take on and enact those personal responsibilities.

Finally, a person should be assigned responsibility only if they have the skill and ability – the competence – to take it on. This, however, can lead us into yet another architectural hornet’s-nest: modelling of capabilities and competencies in relation to real-people.

Capabilities and competencies

In principle, capabilities are straightforward: they represent the ability to act on specific types of assets in specified ways. That’s how we model the capabilities of machines and IT-systems, anyway. We can then map these capabilities to what might call a set of skill-levels:

• rule-based – simple real-time action and response, predictable and repeatable
• algorithmic – more complicated contexts affected by multiple dependencies, delays, etc, yet still follow a straightforward true/false logic (‘hard-systems’)
• pattern-based or heuristic – true complex contexts that are highly-sensitive to starting-conditions (wicked-problems etc), in which outputs can become inputs to the next iteration, and which often follow modal-logics (‘soft-systems’)
• principle-based – near-unique, unique or true chaotic contexts in which there is no actual repeatability, hence new ‘solutions’ most be created in each case

A given capability at a given skill-level is described as a competence. Capabilities are linked with functions, and appropriate business-rules (‘decisions‘) and the like, to present services that respond to specific events at the respective locations, as per the single-row extended-Zachman above. For a service-oriented architecture, we then assert that everything is or provides a service, and that any service could in principle be done by any combination of machines, IT-systems and real-people. This makes it possible, for example, to design IT-services such that real-people can take over in the case of IT-system failure or other disaster-recovery, using essentially the same service-interfaces, and then hand back to IT again when recovery is complete. And to a significant extent, I’d argue that this is how we should model our architecture – hence the design and structure and usage of the Enterprise Canvas model-type (two-page reference-sheet here).

Simple enough in principle: perhaps not quite so simple in practice…

To me, there are two key concerns here: the order/unorder dichotomy, and the Taylorist trap.

The order/unorder dichotomy mainly relates to that stack of skill-levels.

The first two skill-levels – rule-based and algorithmic – fall into what we might call the ordered domains – a world in which simple true/false logic is assumed to apply, and in which doing the same thing will always lead to the same result.

The other two skill-levels – pattern-based and principle-based – operate more in the unordered domains, in which modal logics (should, could, may, might, etc) usually apply, where simple true/false logic can be dangerously misleading, and where doing the same thing often leads to different results or doing different things can end up with the same result.

Machines follow physical rules; IT systems usually follow a predefined true/false logic. That makes them very suitable for use in the ordered-domains – but not good in the unordered domains. Therein lies a key-cause of many ‘IT disasters’ such as IT-centric ‘business process-reengineering’: they tried to use IT as the sole means for managing unordered contexts for which, almost by definition, IT was not suited.  The two usual ‘solutions’ were either to try to control everything, planning for every possible exception or eventuality; or simply ignoring anything that didn’t fit with the system’s predefined logic. Both approaches were all but guaranteed to fail, and usually did so, expensively…

On the other side, real-people can be very good at handling the inherent uncertainties of unordered contexts. What they’re often not good at is ‘following the rules’ in a predictable, ordered way. Itr’s possible to force people to work in an ordered manner, but it’s rarely efficient or effective; and – as Daniel Pink and others have shown – if the work involves any cognitive skill, performance drops off rapidly if attempts are made to motivate people in any ‘mechanical’ way.

So although in principle service-handovers and the like should be a straightforward mapping between machine- or IT- capabilities versus human-capabilities, in practice it’s not quite that simple: we need to design-in appropriate balances for ‘unorder’ on the machine-side, and misplaced ‘order’ on the human side. Some nice architectural complexities there…

Then there’s the Taylorist trap – or rather, several of them.

One trap is implied from the order/unorder dichotomy. In classic Taylorism, manual-workers are essentially viewed as components in a machine: there is no concept of skill, only a strict separation between ‘brain’ (management) and ‘brawn’ (workers). All thinking and reevaluation is done by managers or by external ‘experts’ (e.g. the dreaded ‘time and motion man’). Every exception is escalated to the next higher level. Since (as lated pointed out by Deming) the knowledge needed to solve a problem usually occurs at the point o contact with the problem, one of the key results of Taylorism is for the problem to be ‘escalated’ to people who may have greater theoretical knowledge, but less and less practical knowledge, creating an apparently ‘unsolvable’  problem.

Another trap arises from the same source: treating workers as components in a machine. The competencies required by the work itself are listed in a job-description or the like, in much the same way as a functional-specification for a machine. Anyone who has the required competencies is likely to be capable of doing the work. This approach is extremely useful when designing services that may need to be implemented in different ways with different combinations of manual, machine and/or IT-based ‘actors. The catch is that in effect it defines a ‘lowest common denominator’, and takes no account of skill-levels or abilities beyond the specified minimum. The result is that innovations and creativity – such as would definitely be required in a ‘chaotic’-type near-unique context – may be all but designed out of the overall service, reducing the effectiveness that could otherwise be available. Treating workers as mindless ‘robots’ is also dangerously demotivating, frequently with dire results for overall performance and for overall risk. Hence although in the Enterprise Canvas we would typically model the nominal capabilities and competencies required for a given service, we need to take care to ensure that the relational-asset aspects are also full addressed in any enterprise-models that involve real-people.

One further Taylorist trap is rather more subtle and insidious, and relates to the process via which skills are learnt. The classic learning-process involves working the way through the skill-level stack, first tackling repetition of ‘simple’ rule-based tasks and problems, then moving on to ‘complicated’-type tasks, and thence to true complexity. But when all simple tasks and even many complicated tasks are automated, there is no routine method to learn complex-level skills: instead, people are somehow expected to take over when the machines fail – in other words, when ‘order’ moves into ‘unorder’ – but without any means to understand what’s actually going on. This trap is explained in more depth in the post ‘Where have all the good skills gone?‘

In summary, we can and probably should model capabilities and competencies within an enterprise-architecture: however, we do need to beware of the various traps and problems that can arise if we’re careful how we do this, and how we apply it. You Have Been Warned? 🙂

The next post will explore another key aspect of any architecture that includes real-people: the problem of power. Watch This Space?

See also:

• A question of who
• Principles, values, ends and means
• People, assets, relationships and responsibility
• The meaning of service
• Context-space mapping with Enterprise Canvas, Part 5: Service content
• Enterprise Canvas, Part 6: Models
• Economics as enterprise-architecture
• New economics models – what impact on enterprise architecture?
• Capabilities, reference-models and job-descriptions
• Zachman and capability
• More on Zachman and capability
• On EA ‘owners’ and primitives
• Rethinking Zachman – the ‘Who’ column