Assets and enterprise-architecture
(This is a thread I’ve started over on the enterprise-architecture lists on LinkedIn, but thought I’d also place it here.)
The start-point was a throwaway comment by a guy on one of the lists that was probably meant to be dismissive and sarcastic – given his overall behaviour at the time – but is worth thinking about a lot more deeply:
“Assets do not imply ownership, assets imply value.”
For me, this triggered off a whole stream of questions about what we mean by ‘asset’ in the first place, and likewise what we mean by ‘ownership’ and ‘value’. More on that in the enterprise-architecture books, of course, but this is what I put up on LinkedIn as a ‘conversation-starter’:
(Some of this may sound a bit abstract at first, but if you look a little deeper, it has direct, concrete, practical application in architecture, sometimes with far-reaching consequences on architecture and design.)
The classic economics definition of assets is in terms of capital, land and labour. A useful overview, but too coarse-grained on which to build an enterprise-architecture.
The asset-categories I use are:
- physical: transferable, alienable (if I give it to you, I no longer have it) – a tangible ‘thing’
- virtual: transferable, non-alienable (if I give it to you, I still have it) – data, information etc
- relational: only partially transferable – a mutual link that exists between two entities
- aspirational: ‘one-way’ relationship from a person (mostly) to a virtual or imagined ‘other’ – belonging, meaning, brand etc
(A crucially important example of the need for precision here: people are not assets, it is the relationship with each person that is the asset. Thinking that people are assets can easily destroy an enterprise, and often has.)
Many (most?) real-world assets are composites of these categories:
- paper form: physical and virtual
- CRM record: virtual as indicator of relational
- money: virtual and aspirational (in essence, money is a belief of worth)
- trust: relational and aspirational
These days, most shareholder-value is derived from virtual (IP), relational (‘goodwill’, client-base) and aspirational (reputation) assets – the physical assets are often a tiny proportion of the perceived value.
Each asset-category requires fundamentally different handling: e.g. physical assets require physical storage, other assets (mostly) don’t. Real problems occur when business-models are based on ‘unnatural’ bundling in asset-categories: e.g. music-industry used to bundle its virtual asset (music) into physical form (disc, cassette) which it can control as a physical asset, but cannot control when unbundled into virtual form only (digital download). In architecture, we need to understand the implications of each asset-category, and of bundling and re-bundling of the underlying asset-categories in the assets we manage.
Assets are what are used or changed etc in business-functions. They imply value in that changes within business-functions may add (or remove) perceived value for the asset.
Assets do imply ownership, in that the entity only becomes an asset when it is owned. But note two fundamentally different models of ownership:
- possession – the legal ‘right’ of exclusion
- responsibility – e.g. process-owner, project-owner etc
Although most business-models are based on possession, it’s arguable that it doesn’t work (in fact is the core reason for the current economic crisis), and that the only models that work are responsibility-based. This would take more space to describe than available here, but for architecture purposes:
- what responsibilities are implied by each asset?
- how are those responsibilities transferred?
- how is value determined in relation to the asset and to those responsibilities?
I still have a long way to go to get my head fully around this, so I’m asking for others’ opinions, experiences, suggestions and views. Over to you, if you would? Thanks.
Leave a Reply