People, assets, relationships and responsibility

A great meetup yesterday with Shawn Callahan (@unorder) and Kevin Bishop (@kevinbishop) of Australian consultancy Anecdote, and their upcoming launch of Zahmoo – a new web-based tool to manage stories and narrative-knowledge, for organisations, communities and families.

Over lunch the conversation wandered onto my work on enterprise-architecture and the Enterprise Canvas, and my latest book Mapping the Enterprise. We talked about how to describe assets in modelling an enterprise-architecture – during which we touched on one of my hobbyhorses, that the often well-meant phrase “our people are our greatest asset” is actually a very dangerous thing to say. Shawn tweeted that part of the conversation as follows:

unorder: “The only time people are an asset is when they are slaves.” @tetradian great lunch with Tom Graves and @kevinbishop

Which is a bit unfortunate, as it half-implies that I think that people are slaves (or worse, should be slaves) within a business context – which isn’t what I mean at all… 🙁 🙂 The point I need to make here is that, in architecture especially, the person should never be viewed as an ‘asset’: instead, it is the relationship with that person that is the asset – and it is a real asset to the enterprise that needs to be managed as an asset, much as with any other type of asset. It’s clear, though, that there’s a lot of confusion around this point, and a lot of understandable anger, too, as can be seen in the Twitter-exchange that followed:

tetradian @unorder *people* are not assets – it is the *relationship* with those people that is the asset (and a real asset, too)

emovere: @tetradian @unorder …and “the relationship” is always two! relationships: A>B and B>A. So… there are two “assets” to deal with!

unorder: @emovere @tetradian @kevinsbishop said that in one of the corporates he worked in the UK they often said “we need to sweat the assets.” Yuk!

ImaginaryTime: @tetradian Even that has a nasty ring to it. Relationships should be motivated by what you can contribute, not by what you can gain.

tetradian: @emovere re relationship as asset, disagree slightly: not two assets ‘A>B’ ‘B>A’, but *one* asset ‘A:o:B’ maintained by *both* parties A B

tetradian: @ImaginaryTime agreed re ‘nasty ring’ of term ‘asset’ i/r/t real people, but for #entarch relationships are real assets

ImaginaryTime: @tetradian I’d just not use words like ‘asset’ at all when talking about human beings. ‘Human Resources’ is gauche enough, don’t you find?

tetradian: @ImaginaryTime using relationship as asset helps us *not* treat people as possessed-‘assets’ – will write blog-post on this later today

I’ve written about this a fair bit now, such as in the post ‘The relationship is the asset’ on my Sidewise blog, from back in mid-2009, but it’s worthwhile doing it again, to explain a bit more about my current thinking on this crucial architecture-issue.

I usually take a service-oriented approach to architectures – see The Service-Oriented Enterprise or Mapping the Enterprise – in which everything in the enterprise is a service that is (or should) deliver value in terms of the vision and values of that extended-enterprise. Even the organisation as a whole can be viewed as a service in that sense. This then draws on and/or leads to the following assertions or definitions:

• a service implements the interface of a function (business-function, infrastructure-function, whatever) in accordance with an appropriate ‘contract’ or service-level-agreement, by linking that function to an appropriate capability [the service is also triggered via specific events at specific locations, but we don’t need to go into that detail here]
• a function delivers identifiable changes to assets – for example, the CRUD (create, read, update, delete) actions often associated with information-assets – in accordance with appropriate business-rules, algorithms, metrics etc
• a capability acts on specific categories of assets with a specific degree of competence or skill-level [associated with categories of decision-types – rule-based, algorithmic, guideline-based or principle-based, though again we don’t need to go into that detail here], delivered via an agent
• an agent is an active entity with the requisite capability, embedded in and/or accessed via an asset
• an asset is a resource of any type for which the service is responsible

There are four distinct categories of assets:

• physical – objects, material ‘things’
• virtual – data, information, ideas, so-called ‘intellectual property’
• relational – linkage between two tangible entities, usually but not necessarily real-people
• aspirational – linkage between a tangible entity (usually a real-person) and a virtual entity (such as a belief, an idea, a brand etc)

A ‘primitive’ is an asset of only one category; many (most?) real-world assets are actually composites of more than one type – a book, for example is a bundling of ideas (virtual) in a physical object (the book). There are fundamental differences between the categories: for example, physical-assets are ‘alienable’ (if I give it to you, I no longer have it) whereas virtual-assets are ‘non-alienable’ (if I give it to you, I still have it – in fact it’s quite difficult to not still have it). Relational and aspirational assets are different from physical and virtual in that they exist between two entities – not as characteristics of the entities themselves.

Many of the reasons why enterprise-related architectures – particularly organisation-architectures, security-architectures, business-architectures and business-models – so often get into such a mess come down to two core mistakes:

• trying to manage non-physical assets as if they’re physical (or otherwise attempting to manage assets in ways to do not align with their ‘natural’ constraints)
• using a possession-based approach to assets, rather than a responsibility-based approach

Many intellectual-property models and related business-models fail because they try to treat information as if it’s physical. This is why the business-models currently preferred by much of the media industry are inherently doomed to fail. Their old models depended on physical bundling (a physical book, a physical record, a physical seat in a physical cinema), but the moment their ‘product’ becomes all-virtual (i.e. data) it has to operate by the rules for virtual-assets, not physical-assets. Trying to force the virtual-world to fit physical-world constraints – such as via DRM and the like, or even via laws and regulations – is just not going to work: by their nature virtual-assets are transferred by making copies, so ‘copy-protection’ and the like will not only always fail somewhere, but will also inherently act against the object of the exercise of ‘use by copy’. The result is that companies often end up making ‘pirated’ copies the preferable solution for end-users, not just in terms of end-user cost, but also in terms of greater usability: not a wise move…

(A related example of confusion about asset-types is the whole concept of pricing or valuation. What we think of as ‘money’ is actually a composite of virtual-asset [numbers] and aspirational-asset [a belief about ‘worth’]. As a virtual-asset, it is, almost by definition, infinite. Pricing, however, frequently relates to physical resources – which are not infinite. This mismatch leads directly to problems such as inflation, bubble-valuations [tulip-mania, anyone?] and the very serious dangers of the current ‘financial-derivatives’ markets, which have no anchor in any physical reality at all…)

The same frequently applies to relational-assets, typically ignoring the real asset (the relationship) and instead treating the real-person as ‘possessed property’. Employees are treated as (disposable) ‘human resources’ – hence that obnoxious expression above, about ‘sweating the assets’ – whilst clients and customers are described and even derided as ‘consumers’, with companies fighting over the ‘market share’ of those purported ‘possessions’. Nowhere in this model is much if any understanding of people as people: instead, people are regarded either as objects to be controlled, and/or as subjects that ‘should’ place themselves as subject to the corporate will.

A possession-based model of economic relations is essentially the mindset of a two-year-old: ‘Mine!!!” (It’s kind of embarrassing to realise that most of ‘capitalist economics’ is little more than a pseudo-adult version of the possessive temper-tantrums of the ‘terrible twos’…) But whilst mainstream economics depends on delusions of possession, we already know that those delusions don’t work and should not apply within much of the business context. A process-owner or project-owner, for example, is not the person who ‘possesses’ that business-entity, but is the one who is responsible for its appropriate operation – in fact it’s when someone tries to to claim exclusive ‘possession’ of it that everything goes wrong.

In essence, a possession-based model tries to split an entity into ‘property’ (that which is desired, and therefore held onto, sometimes literally to death), and ‘anti-property’ (that which is undesirable, and therefore dumped onto others as quickly as possible – hence a two-year-old’s attitude to an ice-cream wrapper, for example). By contrast, a responsibility-based model accepts responsibility for the entity as a whole – because at a whole-of-system level, that’s the only way that works. Responsibility may and often will be transferred, but in each case it should ideally be explicit, a transfer of responsibility rather than partial ‘possession’ – because again anything less than that will not work over the longer term.

Resources are entities that are available and that could be used and/or useful in some way. Resources become assets by taking responsibility for those assets. Resources often rapidly become ‘anti-assets’ – causing more harm than good to the overall enterprise – wherever someone tries to take a partial ‘possession’ of a resource without acknowledging full personal responsibility for every aspect of that resource. Architecturally, every resource needs an identified ‘owner’ who is responsible for the use of that entity as an asset – other words, a complete architecture would include a dynamic RACI matrix for everything that is described in that architecture.

Relational-assets are usually links between real-people; aspirational-assets are typically links between a real-person and an ‘idea’ such as a brand, or ‘belongingness’ in relation to a community, a work-team or an overall enterprise. The keyword here is ‘between‘: in effect, the asset is the responsibility of both parties, and will cease to exist if either party drops it. CRM (‘customer relationship management’) systems are meaningful only if the views of both parties are maintained within the system: in most cases only the view from the organisation’s side is maintained, and, worse, the other end is often viewed as a ‘possessed’ object or subject – which bluntly makes the whole thing meaningless, and in many cases succeeds only in damaging the relational asset. (How much spam-mail churned out by some so-called ‘CRM system’ has actually been relevant to you? What happened to your side of the relationship with that organisation as a result?) The asset is the relationship; and the relationship only exists if both parties maintain it. That’s an absolutely crucial understanding that needs to be embedded in every aspect of the enterprise-architecture.

It’s slightly different with aspirational assets, because the linkage is more directional: ‘to‘ than ‘between‘. Yet if the ‘to’ end does not exist, or is dropped, the relationship is lost: and since relational-assets are often strongly bundled with aspirational-assets (e.g. a sense of connection with a company – company-as-idea, as aspirational-asset – rather than solely a single person in that company, as relational-asset), the organisation needs to be careful to maintain those entities to which people will attach aspirational links. Hence the importance of brands and the like, in marketing to ‘outsiders’; but also, very much, the importance of vision and identity in providing aspirational anchors for employees and other ‘insiders’. Each of those aspirational-anchors represents a responsibility on the part of the organisation: because without that responsibility, those links will be lost. But again, those aspirational-anchors are not ‘possessions’ that can be bought and sold (as in the largely delusory concept of ‘goodwill’ and the like); instead, they exist because of and as an expression of the responsibility itself. If the responsibility is dropped, or not treated with appropriate respect, the links will dissipate rapidly – sometimes overnight, as can be seen with many ‘brand-disasters’.

The other point here is the role of relational-assets in context of the agent in a service-architecture. The agent carries and enacts the capability. We often refer to agents as ‘assets’, but in reality all agents are connected to the service via relational-links of some kind. Where the agent is a physical machine or an IT-box, the relational-link is embedded in configuration – the physical and/or virtual placement of the agent and its capability within within a system. A ‘configuration management database’ (CMDB) is actually a record of relational links of assignment: the active-resource (machine or IT-box) is viewed as an ‘asset’, although that term should really apply only to the static physical and/or virtual entities in which the capability is embedded, not the active capability. It’s the routine and largely unconscious bundling here that causes so many architectural problems.

Importantly, though, a machine or IT-box is not capable of taking responsibility, or expressing choice in its assignment (‘configuration’): that’s one of the reasons why it’s so easy to ignore the relational-asset in this context. However, real-people do have the ability to take responsibility, and do have choice – and hence the relational-asset needs to be explicit in the architecture. (The human equivalent of the CMDB is the work-roster, for example.) Hence, in turn, the crucial point that although the requisite capability is embedded in that real-person, in terms of how that capability is linked into a service it is the relationship that is the asset, not the person. Architecturally, the skills and responsibilities of real-people should never be embedded directly in the architecture: they must always be linked only via an explicit relational-asset. Where human skills and competencies are involved, the available capability is determined by the strength of that relationship, the integrity of the relational-asset. And that relational-asset is the responsibility of both parties: if either side drops it, or damages it – such as via the company describing those people themselves as ‘assets’ to be ‘sweated’ – the available capability will be reduced, perhaps even to nothing, even though the nominal capability of that ‘asset’ remains unchanged.

Hence whilst we may describe agents as ‘assets’, architecturally it’s actually quite dangerous to do so, even with physical-machines and IT-boxes, let alone real-people. The key asset in each case is the relationship via which the agent is linked to the service, and hence enacts and enables the delivery of that service. And although each of these ‘between’-assets involves two parties, there is only one asset in each case (not two), with matching responsibilities on both sides of the relationship.

Apologies if this has been a bit long and a bit pedantic – but this is one of those cases where that kind of pedantry really matters, because although it may seem abstract at first, it has real and often severe consequences in real-world practice.

Hope it’s of use to someone, anyways. 🙂