More on assets and enterprise architecture
Another cross-post from the discussions on LinkedIn. Over there, Pat Ferdinandi has been throwing me some really valuable challenges around this whole issue of assets in enterprise architecture – for example:
hmmm…service is not an asset? That made my mind crank a bit.
Is service tied to Intellectual property?
Is IP the asset delivered in different formats? (this would go against your assumption that employees are not assets).
Granted, I’m still thinking within the confines of an organization. But a service does have value (however it is measured).
In executive-speak, services are assets, just as people are assets – it’s a useful shorthand for something which is architecturally much more subtle and complex. As with ‘people are assets’, that colloquial shorthand contains some truly horrible boobytraps if we try to use it too literally.
Think ITIL: “people do not want products or services, they want the satisfaction of a particular need”. The ‘satisfaction of the particular need’ is the perceived value. To the customer, it’s not that the services are value but that they deliver ‘that which is valued’. The service gains value because it is the contact-point for that-which-is-valued – in other words, a relational and/or aspirational link (e.g. brand-as-implied-service-as-implied-value).
To the organisation, the service delivers value, both to the customer, and to the organisation. That value may (should?) be measured. In the colloquial sense, the service ‘has’ value, because it delivers measurable value. The value is derived from or through the service. But architecturally that’s not the same as saying that the value is inherent in the service itself.
Assets are used / referenced / changed / created / whatever in functions. It’s in the function that value is created (or destroyed), in the attachment of value to assets. A service is a conjunction of function and capability – the function can’t operate without the capability, and the capability has no function on its own.
The capability ‘has’ value in the same sense that a service ‘has’ value – in fact it’s where the service’s perceived value comes from. But the capability is embodied in an ‘actor’ or agent; and the agent itself is embodied / embedded in a physical asset (e.g. server, shop) and/or virtual asset (e.g. website) and/or via a relational-asset link to a real person. In a service, the service has perceived value, but the value itself is ultimately embodied in assets.
‘Services are assets’ is okay at board-level. (Even ‘people are assets’ is okay there if it gets the …s thinking about people as people rather than as interchangeable / disposable ‘resources’… 🙁 ) But in our own thinking we need to be able to be more precise – especially if / when we’re facing down-to-the-roots redesigns, which ain’t at all unusual in the present circumstances. ::wrygrin::
“Is service tied to Intellectual property?” – it’s one possible linkage, yes, but service could be linked to any type or combination of types of assets.
“Is IP the asset delivered in different formats?” – IP is a type of asset, and can be delivered in different formats or composites, yes.
“(this would go against your assumption that employees are not assets)” – not at all. All I’m saying there is that people themselves are not assets, but the relational link to/with that person is an asset – and needs protecting and preserving just like any other organisational asset. ‘Our people are our assets’ is a useful colloquial shorthand for ‘The relational links we have with the people who have employee-relationships with us are the assets which permit us access to that person’s capability / competence”. But it’s critically important to recognise that the ownable asset is the relationship, not the person: if we try treating people (or IP, for that matter) in the same way that we ‘possess’ physical things, they’re gone. Hence the need for the deep-level precision about this stuff at an architectural level.
I have a lot of material in my last book on the relationship between the device (asset) and the commodity of the device (service). This is one of the techniques I use to define a simple loosely-coupled business architecture.
My analysis is ultimately based on the work of Albert Borgmann. Borgmann provides a powerful critique of a simplistic view of technology that confuses the relationship between Device and Commodity, which he calls “the Device Paradigm”, and I can strongly recommend his 1984 book (Technology and the Character of Contemporary Life).