More on EA and asset-types [3]

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 first post in this series, we looked at the concept of four distinct asset-dimensions:

• 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

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas:

And we looked at how those asset-dimensions apply in practice to for the first two columns of that checklist: Assets, and Functions.

Moving on, we now apply the same logic to locations: every location, of any type, exists within a schema that incorporates any combination of the asset-type dimensions.

[As in shown the service-content checklist above, there’s a fifth dimension – time – that applies primarily to locations, though potentially to specific types of events as well. The key point is that although we do treat it as a dimension here, time is not an asset in the same sense as for the other dimensions: we know this because we can’t ‘own’ time, in any sense, and we can’t create it, update it or delete it. (We can waste our own time, of course, and sometimes for or with others as well – but that’s not the same as deleting time itself! 🙂 )]

Obviously, we have physical-locations – locations with physical-dimension schemas – with which we would typically associate physical-assets.

We have virtual-locations, with which we would typically associate virtual and/or physical-assets. An IP-address or URL is a classic-example of a virtual-location. A street-address or room-number is actually a composite, a virtual-asset from an imaginary-schema of street-names or floor-numbers or the like, that also references a parallel schema for physical-locations. Much the same for the pairing of a network-address and rack-location for a data-server, for example.

We have relational-locations, within relational-schemas, within which we find relational-assets: the dreaded org-chart is perhaps the archetypal example of this. (Note, by the way, that it’s the relationship between people that is the asset in this context – never the person!)

[I’ll admit I’m not quite sure how best to describe, within this taxonomy, the implicit relationship indicated by an ‘owner’-responsibility such as process-owner, project-owner, data-owner etc. There’s no person-to-person connection there, so it’s probably not a relational-asset; in fact it seems to point strongly towards it being an aspirational-asset, because it’s clearly person-to-abstract, even where it’s a physical object that’s ‘owned’. The fact that such ‘owner’-responsibilities only work well when there’s a personal commitment involved again points to a variant on aspirational-asset. But I’d appreciate any comments you might have on this, anyway.]

Then we have aspirational-locations, within aspirational-schemas, within which we find aspirational-assets. This one’s perhaps a bit of a mindstretch too, but the most obvious example is brand-mapping, where brands are mapped in relation to each other, and demographics mapped to brands.

And, of course, we have temporal-locations, within various forms of timescales – some of which may be time-itself, others as proxies for time, such as video-framenumbers and the like. Time isn’t itself an asset, so we can’t place ‘time-assets’ within time: but we can place other assets, and other locations in other schemas, and so on, in relation to time.

As with functions and assets themselves, locations often exist within composite multiple-dimension schemas, which may intersect with other multiple- or variable-dimension schemas: it gets complicated… But again, this taxonomy does help to disentangle all the threads, which can become highly relevant as we move assets or functions or whatever between or even within different location-schemas.

By contrast, events are relatively straightforward.

We have physical-events: mechanical triggers, events in the real-world, and so on.

We have virtual-events: a signal, a numerical-value, a clock-event.

We have relational-events: something that marks the start of a beautiful relationship, we might say, or an unfortunate divorce – in a business sense, in this case, but the metaphor still holds for events that impact or are triggered by changes in relational-assets.

We have aspirational-events: anything that affects a brand, for example.

And we have composite-events, of course. “A man walks into a bar” might be the beginning of a joke, but in business terms it’s a composite of a physical event, probably a virtual-event ‘door open’ signal, possibly a relational-event, and quite likely a select-a-beer-brand aspirational-event too.

We can also see how the various asset-dimension threads weave through sequences of events, such as in what might happen after “a man walks into a bar”:

• there’s the change-of-status physical-event of no more beer in the vending-machine, which is…
• indicated by the ‘dispenser-empty’ virtual-event signal from the vending-machine, which may lead to…
• a physical-event of an angry kick at the machine from the would-be customer; thence to…
• an end-relation event with the bar-keeper, and…
• the aspirational-event of the signal of a potential beginning of an anti-client aspirational-link ‘anti-asset’ between the now-ex-customer and the bar

Disentangling all of those threads is an interesting exercise for a service-designer or solution-architect, one that really is made a lot easier through this type of taxonomy – though probably not very interesting at all to our ex-customer, who still just wants his drink! 🙂

Again, stop there for now: in the final part of this series we’ll explore how the same principle applies to capabilities, and thence to services – to me, the core of the architecture.