More on EA and asset-types [2]

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?

In the previous post in this series, we looked at the concept of four distinct asset-dimensions: Physical, Virtual, Relational and Aspirational.

The same dimensions carry right the way through the entire architecture. We can see this if we map it as per the ‘service-content checklist’ from Enterprise Canvas, which can also be understood as a much-extended adaptation of a single row from the Zachman taxonomy:

The asset-dimensions are kind of orthogonal to the dimensions represented by the Zachman-style ‘columns’. For this we’ll keep the emphasis on the columns to which these dimensions map directly: Assets, Functions, Locations, ‘action’ and implicit ‘actor’ component of Capabilities, and Events.

[The mapping comes out in a related but somewhat different way in the Decisions/Reasons column and the ‘skill-level’ component of the Capability column, which I won’t go into here.]

On assets themselves, we’ve already covered the fundamentals in that bullet-list from the previous post:

• 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

We need to handle and manage assets in accordance with the respective dimensions: management in terms of storage, security, access, natural-lifecycle, refresh, migration and so on.

It’s all fairly straightforward territory for enterprise-architects; the only real complication is that many entities are or represent composites of dimensions, which means that they need to be handled and managed in accordance with the rules for all of the respective dimensions. A printed book is one simple example:

• book as physical-asset (object): physical storage, ownership-title, inventory-control, access-control, instance-identification, maintenance, repair, physical disposal etc
• book as virtual-asset (information): data-storage, copyright, copy-control, access-control, version-control, validity, review, renewal, metadata, indexing, withdrawal, secure-deletion etc

Just to make it even more fun, the combinations of those composites can change, too, in response to events, the CRUD actions in functions, sometimes in different locations, and even through natural deterioration or depreciation within the lifecycle.

[There’s a lot more to explore about the detail of this, but I’ll do that in another post: for here I want to concentrate on the way the same principles go across the whole architecture.]

Hence, yes, can be a bit mind-bending at times: but taking a dimensions-approach – using the dimensions as ‘lenses’, if you like – really does help.

In the broadest sense, functions act on assets: they describe the activities that apply CRUD-type changes and the like to assets. Hence, again, we have different dimensions of functions – actually the same dimensions – that act on those respective dimensions of the assets.

We have functions that create, use, change and destroy physical objects, or physical attributes of objects.

We have functions that create, read, update and delete information and other virtual-assets or virtual attributes of entities.

We have functions that help people create relational-links with each other; remember existing relational-links; refresh those links, or provide conditions under which a link can sort-of be transferred to another person, such as in a shop, or an escalation at a call-centre; and although relational-links in effect delete themselves as soon as either party drops it, we have functions which can either assist that to happen, or to dissuade it from happening,

And we have functions that help people create aspirational-links – for example, to connect with a brand. We have many, many functions – most advertising, for example – that help people refresh and renew and reconnect with their aspirations in context of a brand or some other aspirational-link ‘target’: in other words, ‘read’ an aspirational-asset, the aspirational-link itself. We have a suite of functions to get people to ‘update’ the aspirational-asset link – for example, to get someone to change loyalty from a competitor’s brand, or to support ‘upsell’ to a more upmarket brand of our own. And for a few special cases, we have functions that aim intentionally to destroy an aspirational-asset – such as when a brand comes to the end of its life, yet we have no replacement, and we don’t want to upset existing customers of that brand.

And, as before, there will be functions that interweave any or all of these dimensions at the same time. But it’s useful to be able to tease all of the threads apart where necessary – not least because a re-implementation of a function in a different form could lose or gain key aspects of dimensions that we might otherwise not realise were there in the previous form.

Thinking of relational-links and aspirational-links as assets, in exactly the same sense as for physical- and virtual-assets, can sometimes be a bit of a mindstretch: but because it allows us to address all asset-types – and what we do to and with all types of assets – in exactly the same overall way, it really does simplify the architecture-frame a lot. And as we’ll see in a moment, it also brings a new clarity and new simplicity to service-oriented architectures, right up to a whole-enterprise scope.

Stop there for now: in the next post we’ll look at how this applies to locations and events.