Tom Graves / Tetradian

Following along the ‘Assets and enterprise architecture‘ theme, one of the questions that came up in the matching thread on LinkedIn was from Mike Stewart, which in effect illustrates well some of the distinctions about physical assets versus data-assets. His practical problem was in defining the right insurance for a data-centre; my response follows:

One question which has caused me a fair bit of pain in the last few weeks – how much should my organisation insure our data centres for? I can get my hands on apps, infrastructure etc.. But if data really is an asset (which should really have a known and quantifiable value, but in reality…) then surely most of the insurable amount of a data centre is in this.

Mike – “How much should our organisation insure our data centres for?”

Yes, agreed, “most of the insurable amount of a data centre is in [the data itself]” – except there’s no means to insure it in the same way as for the bricks-and-mortar, the servers or even the apps.

Conventional insurance covers physical, replaceable ‘things’ or replicable services (the apps fall into that second bracket). An app is ‘frozen data’, in effect a physicalised virtual-asset providing a service: it’s replaceable. (Mostly, anyway – a whole load of tangles around escrow and duplicable function, but that’s detail for another time.)

But the raw data itself is not replaceable: it’s a virtual asset, not a physical asset. It’s created / amended etc at specific points in time, and you can’t go back in time to replace it. (Ask me somewhen about painful experience in an engineering lab with hardware-encrypted data and the consequences of throwing away ten years later the ‘outdated’ computer used for the original encryption. ).

You could possibly insure against loss of use of data – impact on business processes and the like. But that won’t replace the data.

Since the data itself is not replaceable, the real ‘insurance’ for the data is all the effort you put into backup, system-redundancy, remote storage, data escrow, data/information-architecture and so on. It would be entirely reasonable to class all of that as part of your insurance budget (and the much larger overall-enterprise insurance-budget, for that matter) – and might make some of the funding-arguments easier, too!

Hope this helps?

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.