More on EA and asset-types [1]

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

[I know I usually write too long, so as a kind of trial-run, I’m splitting up this original long-post into four smaller ones: please let me know if this works better for you? Thanks!]

This one is a sort-of follow-up to the earlier post ‘Charisma, connection and brand‘, which looked at two lesser-understood asset-types, relational and aspirational. It’s also a pick-up on the article pointed to by the following Tweet, with my explanatory comment attached:

• SAlhir: Brand vs. product: what really drives reputation? http://bit.ly/sLf4hs >actually, she says, it’s neither: it’s delivery on promise that matters most – agree.

I usually define an asset as “anything that the organisation uses and/or is of value to the organisation, and for which it is responsible”. In essence, if we can do some form of a CRUD (Create, Read, Update, Delete) to it, and the organisation ‘owns’ it in a stewardship sense at least, then it’s an organisational asset – and hence relevant to the architecture. So this is deliberately broader than the usual definitions of ‘asset’, to enable the architecture to cover the full range of assets, both tangible and intangible.

Overall, there are four different types, or more precisely, four distinct dimensions of assets:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

So any asset may be or represent not just one of these dimensions – i.e. as an ‘asset-type’ in the same sense – but also a composite of any combination of these dimensions, a combination which may well change over time for the same nominal entity. Hence I often map this in tetradian form, the inner axes of a tetrahedron:

Most business looks only at the physical and/or virtual dimensions, because, being transferrable, that also represents something that can be sold. But it’s the interactions of all of those dimensions that makes it all happen. Consider this in terms of the market-cycle:

Almost by definition, if we’re dealing with business-type Operations, the focus is mainly on saleable, exchangeable physical and/or virtual. Yet even there, whenever real-people are involved, it’s going to imply some aspects of relational and/or aspirational.

In the Tactics space – the start and end of the core sales-process, for example – it’s definitely going to involve relational-links with real-people, and aspirational-links around desires.

Further out, into Strategy, most of the core concerns will revolve around the aspirational-links that underpin reputation and trust.

And if we don’t manage all of those less-tangible dimensions properly, and manage all of the completions properly, the cycle is going to break – yet we probably won’t be able to see or understand why it’s broken. Which means, very quickly, a dead business. Hence this isn’t some trivial ‘academic exercise’: this is absolutely fundamental to all forms of business-architecture and the like. Yet many of the nominal enterprise-architects or business-architects I meet don’t seem to know about any of this: they just point at the financials, for example, and think that that’s the answer to everything. Which I must admit I do find worrying, to say the least…

[Notice that, unlike many conventional models, there isn’t a distinct category here for financial-assets. This is not an error, because in this schema we don’t treat money any differently from any other asset. A financial-asset is, in effect, a composite of virtual-asset (the information carried by a monetary value, which in itself is usually stable) plus aspirational-asset (the belief in the value of that asset, which can be highly variable), plus also physical-asset if the monetary-value is expressed in the form of cash or some other physical entity.]

The point is that each of these dimensions indicates different requirements for handling: physical cash needs to be handled as a physical-asset, whereas a data-record of the same monetary-value generally doesn’t (other than in terms of its storage or transport within a disk-drive or network, which is a different physical-asset). They’re also worked on in different ways in different functions and by different capabilities, have different event-types, have their own distinct location-schemas and so on – and yet they all interweave with each other in practice in ways that can be mind-bogglingly complex.

Yet architecturally speaking, if we allow ourselves to become confused about what type of asset we’re dealing with, or which dimensions we’re dealing with in each context, we’re going to get into serious trouble. This is especially true if we build a business-model on incorrect assumptions about asset-types – as the media-industries discovered to their cost in the shift, for delivery of music and film and text, from physical/virtual-bundling (a music-manuscript or disk, a cinema-seat, a physical book) to virtual-only (digital data).

So as I understand it, it’s part of the architect’s job to sort it all out, and prevent it from twisting itself into an unmanageable tangle. Hence this post, and others like it.

In the next post, we’ll explore how this same principle of ‘asset-dimensions’ echoes across the entire scope of the architecture.