This is an attempt to get back towards ‘Normal Service Will Be Resumed…‘ – I don’t know how coherent it will be, but it’s a start, anyway…
Unfortunately, the post that most fully describes ‘relational assets’ (‘The relationship is the asset’) was on my now-defunct Sidewise weblog, but there’s a fair summary in my 2011 post ‘The no-plan Plan: people in architecture‘. There’s also a fair bit of detail on how relational-assets intersect with other asset-types (or, more accurately, other asset-dimensions) in the post ‘Fractals, naming and enterprise-architecture‘:
The crucial point is that people are not ‘assets’ – it is the relationship that we have with that person that is the asset. And like any other asset, we can create it, read it, update it, delete it, and more. The tricky part is that it only exists between people – hence, for example, that asset can be ‘deleted’ from one side, without the other knowing that the deletion has occurred. (This is one of several reasons why CRM [Customer Relationship Management] systems are a lot more problematic than most people seem to realise…)
If we don’t understand how it is the relationship with the person that is the asset, which then makes it possible for that person to seem to be an ‘asset’, then we’re likely to make very serious mistakes in our enterprise-architectures. IT-centric architectures in particular tend to assume that relational-assets either don’t exist, or can be subsumed into other asset-dimensions such as information (another common conceptual-error underpinning many misuses of CRM systems):
Although we talk about relational-assets, it’s often more accurate and more useful to think in terms of the relational-dimension of assets in general. For example, a printed book is a physical ‘thing’ (physical-dimension), contains information (conceptual-dimension), probably belongs to someone (relational-dimension) and may well have meaning for that person (aspirational-dimension – identity and purpose).
In terms of architecture, relational-assets could be said to be a kind of fudge. But it’s a fudge in much the same way that Heisenberg’s Uncertainty is a fudge, or Schrodinger’s Cat is a fudge, or the imaginary-unit i (square-root of minus-1) in complex-numbers is a fudge – it makes it possible to describe something real and concrete yet ‘bizarrely’-complex and often counterintuitive, in a way that would not be possible otherwise.
We don’t and shouldn’t describe people as assets to enterprise-architecture. (The only physical-architecture equivalent is the anchorite, which is extremely rare in spiritual-architecture and probably unheard-of in secular-architecture.) Failure to recognise this point leads to fundamental design-errors such as the concept of a ‘job’ in the Taylorist sense – a bundle of predefined characteristics and performance-metrics that may or may not apply appropriately for different people, (‘non-fungibility’), and are especially problematic in high-uncertainty / high-complexity / low-repeatability contexts when the work relies on specific skills, competences and experiences for successful outcomes.
(Few people seem to realise that the exact same will be likely to apply to true-AI systems in the near-future: each system-instance will necessarily learn in subtly-different ways, from exposure to different learning-experiences. For those contexts, relational-assets will start to apply to AI-systems as much as to human actors.)
To give a real example, treating people as real-people (with all of the concomitant complexities), and ensuring that the required relational-assets (person-to-person links that also link to the task in hand), are central to the concept of Crew Resource Management. This originated from the airline-industry, but now used in other areas as well, such as described, for example, in Atul Gawande’s The Checklist Manifesto.
Wherever the ‘human factor’ is involved in any kind of work, relational-assets are required to link the people to/with that work and to/with each other. If this doesn’t happen, ‘the math doesn’t add up’, and failure is likely to occur. Two incidents from the film ‘Sully’ illustrate this well – one about the dangers of ignoring the human factor in simulations, the other right at the end, a comment that it was the dynamically-created teamwork across all of the human-actors in that incident that created the successful outcome.
Also crucially, including relational-dimensions in the assets-checklist also helps to remind us of ‘the other side of enterprise-architecture’ – the role of story, in parallel with the role of structure. (Technically-speaking, the linkage to story is probably more via the aspirational-dimension for assets, but the relational-dimension plays a key role in making it a person-with-person shared-story.) In this sense, relational-assets pervade through an architecture, in much the same way that the capability dimension of service-content in Enterprise Canvas service-modelling supports fractality and recursion for a service-oriented enterprise-architecture.
I hope this makes some degree of sense? – if not, perhaps let me know in the comments?