Structure, story and relational-assets
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…
Over the past few weeks I’ve had a stream of very good questions from Eric Weinstein, about the nature and role in enterprise-architecture of what I’ve termed ‘relational assets’.
Unfortunately, the post that most fully describes ‘relational assets’ (‘The relationship is the asset’) was on my now-defunct Sidewise weblog. [Edit (19 April 2018): I’ve now republished that post today on this blog, as ‘The relationship is the asset‘]. 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?
The relationship between objects are the asset. Brilliant.
Many thanks on that, Pat! 🙂
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.”
In short fudge is something that makes the impossible possible. Such things are not possible. Not without magic.
So thus “fudge” is what we in Sweden call a “noaord” (what is the English term?) for magic.
But things that seems impossible are possible. We have all seen the impoossible happen.
Thus magic exists, regardless if we call it “fudge” or something else.
We live in a magic world were anything is possible.
It’s just a matter of finding the fudge and magic needed.
So what are we waiting for? Go out and make the world spellbound!
(and feel free to ping me, would love to chat!)
Great to hear from you, Johan!
“Thus magic exists” – well, yes, of course! 🙂 I’ll duly include a quote from a novel I’m working on at the moment, based in the 1880s, nominally hard-scifi, though with including what you might call a solid hint or two of the magic behind all technologies:
I hope that makes some degree of sense? 🙂
And yes, would likewise love to chat – have duly sent you an email to connect.
I note you define relational-assets to be between humans only in your response to Eric Weinstein. On the other hand you note AI systems will learn differently because they will be subjected to different situations. Will that make their behavior different enough to start treating their relationships as relational-assets?
Thanks, Jan. One of the cues would be where the experiences of AIs are sufficiently different to warrant person-to-AI connection with a specific instance. The movie ‘Her‘ ( http://www.imdb.com/title/tt1798709/ ) provides one description of this (though note that the AI there is both one instance and multiple instances at the same time). Or, to take the AI required for self-driving cars: vehicles in the North of the US would have very different learning-experiences (snow, ice, low-temperatures) than those in the South (high humidity, high temperatures, tornados/hurricanes): a ‘Driving Miss Daisy‘ ( http://www.imdb.com/title/tt0097239/ ) scenario becomes an interesting possibility. (For a more dystopian view of self-driving cars, see Isaac Asimov’s short-story ‘Sally‘ ( https://en.wikipedia.org/wiki/Sally_(short_story) )…
Thanks for the post about my questions!
I’ve read (and re-read) several times this post as well as a bunch of others on this subject by searching the blog and books. Starting to get it now…….
I think – perhaps – thinking of the ‘relational’ dimension in terms of the extended Zachmen content framework (http://tblog.tetradian.webfactional.com/wp-content/uploads/2011/01/single-row-extZachman.png) helps to cover all(?) the key points one would need to know on this subject. In addition, explain the key points first in the form of a list (row-1) and then in terms of relationships (row-2) would help with understanding. 🙂
Well, I’ll give it a try……
But first what does RELATIONAL mean in this context?
– it’s a LINK
– the LINK connects to (only?) tangible things (either Person-Person or Person-Physical asset)
– If one side no longer participates in the LINK, then the relational asset will cease to exist (your CRM to Person example).
– Besides slavery, people CANNOT be owned. People also cannot be owned like a Machine or IT App. Because People cannot be owned, we must have a formal link to access their capabilities. Does this mean IT and Machines do NOT require a link to access their capabilities?
– Assets are often composed of many dimensions, where one of the dimensions may be relational (e.g. the Person-Physical link of MY-BOOK where the book is also physical an contains virtual info).
– The relational dimension MUST exist for all assets – otherwise it’s not an asset. E.g. Assignment of RACI roles to a physical object is when it becomes an asset.
– Another cross reference: The link between the Governance/Direction Guidance service AND the main transactional service on the Enterprise Canvas represents a relational asset. Does this mean a Service itself is always tangible?
– a common misconception – The ‘ anchorite’ example. In this case, ‘anchorite function’ takes as input a human being and outputs the human embedded in a wall? This helps show why PEOPLE are almost never ASSETS.
Row 1 (list) All things ‘relational’ – Starting with the extended Zachman (left to right);
Relational ASSETS – the LINK between tangible things. The LINK between either:
a) PEOPLE to PHYSICAL assets (App, Machine, Pencil/Paper) or
b) PERSON to PERSON
c) Is PHYSICAL to PHYSICAL or VIRTUAL link possible? E.g. what is the link between my Apple Watch heart rate sensor and its algorithmic function that it uses to determine calories burned?
Relational FUNCTION – A very specialized ‘CRUD’ of the LINK between relational assets (People-Physical or Person-Person)
Relational LOCATION – I know the example you give is a particular employees position on an org chart. But how do we define this? What are other examples? Still not clear to me…
Relational CAPABILITY – The LINK to the ASSET that is actually performing the work. So, a Skilled Person to IT Application link means just that – a skilled person doing work using the application.
A Skilled Person to Person capability – means two people working together as a team for some purpose.
Relational EVENT – The trigger for work when the trigger involves a link of somekind. Perhaps an example is a handshake when friends meet, which triggers a conversation.
Row 2 (relationship):
“with Asset do Function using Capability at Location on Event because Decision”
So a few points here:
It is possible that the following extended Zachman coumns – Asset, Function, Location, Event – can ALL be physical or virtual – while the CAPABILITY may be relational. It maybe a person working making a copy at the copy machine (Person to Machine Link). Or a person meeting with another person (Person to Person) link.
– Linking to a person in a Capability is most useful for chaotic / wild problem contexts – those that rely more on principles and values than repeatable rules
– FUNCTION – CRUD – or say the CREATE operation of a link between to people. What is an example capability to link to this function here? Perhaps one person making a phone call to another? How would this work in Person-Machine links? Is the link created by walking over to the machine and pushing a button?
Thanks, Erik (my apologies again, struggling to get back on track with this, I’ve built up a terrifying backlog whilst I’ve been mostly-out-of-action…)
All pretty much there, I’d say (and again, most of the difficulties here have arisen because I’ve assumed a lot of things are ‘obvious’ when in fact they’re not…). A few added comments:
— A capability enables action on assets; the relational-dimension may apply to assets; hence yes, “a capability may be relational”. The trap here – and I’ve seen several people fall into it – is that we then think of that function or capability or whatever as if it’s the same as a function or capability for data-manipulation: which it isn’t. When you talk with someone, do you think of it in terms of a CRUD-type approach to the data that are exchanged between you? Yes, there’s data, and no, it’s different, isn’t it? When you meet someone for the first time, you Create a relationship; when you meet them again, sure, you Read and Update that relationship; but if you think of it in terms of a computer-type Read or Update function, you’d be in deep trouble – in fact almost guarantee a Delete from the other side. 🙁 🙂
— “Perhaps one person making a phone call to another?” – yep, mostly. Notice how that operation works, what the means are via which the Create / Read / Update of the relational-asset takes place. The same CRUD logic applies (with some adaptations), but the way it happens is very different.
— “How would this work in Person-Machine links?” – well, this is where we get into territory that’s more than a bit weird… Quick summary is that people do tend to relate to/with machines as if they’re other people: assign them names, speak soothingly or angrily to them, and so on. Most of the time, it makes no sense (what’s that old joke? “Don’t anthropomorphise computers: they hate it!” 🙂 ). But in certain types of skilled-work – one classic being to coax a lathe or other metal-work machine to deliver quality higher than it ‘should’ – that ‘relating’ seems to pay off in subtle yet important ways. (Probably because we ‘listen’ more carefully to the machines foibles etc? – I don’t know, so I’ll quietly sidestep that aspect of the argument!)
— “Is the link created by walking over to the machine and pushing a button?” – the short-answer is No. The several-week-long-answer is ‘It’s kinda complicated… or complex… or something…’ Probably best stick to the short-answer for now? 🙂
Hope that makes some sense, anyway?
Sorry for cross-posting the following (I meant to post it here! But there is no way to delete my other post).
Also, one other approach to view the ‘relational’ aspect:
Instead of writing about it directly (definitions, relationships, etc…), how about and simple clear example?
I’ll give it a try:
Scenario: A woman gets married and tells her employer she has changed her last name to her husbands last name.
We can represent (using Enterprise Canvas) with 1 service:
Notify HR of Name Change
Next, the extended Zachman framework for the service:
Notify HR of Name Change:
Asset (RELATIONAL, person TO person): Employee and HR person
Asset (ASPIRATIONAL, person TO virtual): Employee person and HR Employee HR database record
Function (virtual): Notify HR of Name Change
CREATE HR to Employee Relation (Employee, HR employee).
This function take two parameters – Employee and HR Employee – and returns the RELATION ASSET called ‘HR to Employee’)
Notify of Name Change (HR to Employee Relational Asset, New Last Name Employee Aspirational Asset)
This function takes two parameters – ‘HR to Employee Relational Asset’, ‘New Last Name Employee Aspirational Asset’ – and does not return anything.
Capability (virtual): Email HR about Name Change
The assets in the capability are used in the following way:
Email To and From Box: HR to Employee Relational Asset
Email Body: New Last Name Employee Aspirational Asset
Am I way off here?? Does this example make sense? Could you please provide a simple example that communicates the concepts here?
Thanks, Erik – I’ve cross-posted this same answer to the two places you’ve posted this question. (It’s a good question, I’m not complaining!)
The quick summary here is that you’re treating a relational-asset as if it’s data. It isn’t. That’s the whole point here.
What you’ve described above works pretty much what should happen with the data in this context – conceptual/virtual-dimension, not relational-dimension. That’s what we’d put in the HR system, which is an internal analogue for a classic data-centric CRM Customer Relationship Management system.
The only relational of all of this is the relations between HR staff and the employee. Here’s an exact analogue of that data-function:
— “Look, I got married!” (employee shows wedding-ring to HR staffer)
— “Oh, wow! How’d it go? Where did you go for your honeymoon?” (says HR staffer)
(probably Updates the relation to ‘happier both sides’)
— “Oh, you finally got hitched, did you? About time…” (says HR staffer)
(if the relation is strong, and the sarcasm is rooted in happy mutual ‘joshing’ [constructive-competition], may Update the relation even ‘happier’ both sides; if the relation is poor, or low on trust [destructive-competition], may Update the relation to even more damage than before)
— “Right. Fine. More unnecessary work for us. When’s the baby due? I’d better set up the paperwork right now.” (says HR staffer, dry, mechanistic, uninterested)
(I’ll leave you to work out what kind of Update that would do… 😮 🙂 )
In short, it’s sort-of a bit like data – but it isn’t data, and treating it like data will all but guarantee damage to the relation-asset.
Again, I hope that makes a bit more sense?
(Aspirational-assets and the interactions between relational-assets and aspirational-assets are another whole ball-game that I’d better not dive into here – it needs to be up at blog-post level, not buried down in the comments.)
Yes, making a bit more sense. 🙂
The HR staffer updates the Last Name in the HR System – that can be seen as a capability, right? Is it a capability where the CAPABILITY::AGENT is enacted a Human relational asset? While the CAPABILITY::ACTION is executed by a virtual IT asset?
Basically, I am trying to understand the very common scenario for a capability where a human enters data into an IT System.
For the Human Relational Asset for HR Staffer – what are the entities on each side of the LINK? Obviously one side is the HR Staffer.
But what is the most appropriate ‘other side’ of that link? Is it the relationship of the HR Staffer and her manager? Or is it the relationship of the HR Staff and the Organization?
Side question- can Organization (the company or department of the company) be seen as a proxy for a person? I would think yes – because each side can just as easily ‘walk away’ from the relationship.
🙂 OK, one more view into this:
In the extended Zachman, Assets are used in BOTH the WHAT and WHO:
1) ASSETS (WHAT)
2) CAPABILITY – ASSET as AGENT (WHO)
Whatever the TYPE (relational, physical, virutal, aspirational) of ASSET the AGENT is, it must first be CREATED somewhere. In a normal business sense (unless it’s baby making), People do not just get created. The LINK to the person is what gets created. Once the link is created and taken responsibility for, it can become an asset. Once it becomes an asset, it can be used in a capability.
That capability which uses a relational AGENT may OUTPUT another asset, which may also be relational.
“The LINK to the person is what gets created. Once the link is created and taken responsibility for, it can become an asset. Once it becomes an asset, it can be used in a capability” – yep, that’s it, Eric.
The complication is that ‘relational’ is more a dimension of assets, rather than a type as such – most real-world assets carry a combination of dimensions. (A wedding-ring, for example, is a physical-asset that also refreshes/clarifies relational-links (the relational-link with your spouse might weaken if you suddenly weren’t wearing it any more…) and provides/symbolises an aspirational-link (commitment to each other).)
“That capability which uses a relational AGENT may OUTPUT another asset, which may also be relational” – yes, though not just output, but any of the CRUD/CRUDE operations: see ‘ CRUD, CRUDE and other action-acronyms‘.
Yes, the concept of asset dimensions, rather than type is very useful for me.
Do you think a comparison using the Market Cycle and asset type vs. dimension is valid or useful?
Respect/Relations – In a marketing context, we would very much strive to CREATE a relationship with a potential client. In this sense, it may be useful to think of the relational asset as ASSET TYPE. Although, of course there can be other dimensions here too. In other words, the ‘core’ asset here is probably a relational one so distinguishing this Asset Type is probably appropriate.
Transactions/Exchange- Specifically, for Transactions, the ‘core’ asset type is usually physical or virtual. In this sense, the relational asset is probably best thought of as ASSET DIMENSION.
I would guess that the vast majority of EA work today is probably in the transactions/exchange area and so therefore ‘defaulting’ to ASSET Dimensions is probably the way to go..