More on EA and asset-types [4]

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 identified 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, first with an emphasis on Assets and Functions:

In the third post we looked at how those asset-dimensions also apply to Locations and Events.

In this final part of the series, we’ll look at how the asset-dimensions impact on Capabilities, and then how all of those concerns come together within services.

[As before, we’ll skip the Decisions and Capabilities:skill columns for now: the asset-dimensions do apply there, but only kind-of in parallel – as implied in the service-content checklist above – rather than directly as in the other columns. A topic for another post, really.]

The asset-dimensions apply to Capabilities in a somewhat more complicated way than for those columns described earlier. What we definitely need to avoid here are those endless arguments about capability versus function versus service versus process and the like, which can get very tangled indeed. So to keep everything as simple as possible, I use a very flat definition here: a capability is the ability to do something.

[If you want to extend it a bit for the business-context, a capability is the ability to do something that would be of value to the enterprise. We’ll see why such a bald definition is so useful later when we look at services.]

In practice, though, this capability ends up with three distinct components:

• action: what kind of capability, what the capability can do, to what, and with what
• actor: who or what does the work implied by the capability
• skill-level: in effect, the ability to deal with real-world variation within the context of that work [which we won’t explore here]

The simplest part of this is Capabilities:action. The actions of a capability act on assets, or create changes in assets, so it’s essentially the same as for assets.

We have physical-actions, which act on, use or change physical-assets, or the physical-dimension components of composite-assets.

We have virtual-actions, which act on, use or change virtual-assets, or the virtual-dimension components of composite-assets.

We have relational-actions, which act on, reference or change relational-assets, or the relational-asset components of composite-assets.

And we have aspirational-actions, which act on, reference or change aspirational-assets, or the aspirational-asset components of composite-assets.

Sadly, the real world is rarely quite that simple…

True, if everything lines up straight away – for example, we have the right type of physical-action to work on the right type of physical-asset – it actually is that simple: metal-working capability to work on metal, and so on. Remember, though, that these are dimensions, which in the real world usually occur in fairly complicated and sometimes dynamically-changing composites – both for asset-types, and for the capabilities that would act on them. Getting everything to line up properly is often a lot harder than it looks, with plenty of scope of for inefficiency, ineffectiveness and error – especially if we don’t even know about the relational-asset and aspirational-asset aspects of some task that needs to be done. Hence why we need to use the dimensions-set as a checklist – along with other checklists, of course – to make sure that nothing has been missed.

[I won’t give a detailed example here: it’d take too long, and would probably only make sense in that specific context anyway. But if you do need a full example, please let me know? – preferably with some background and description from which to build the example.]

Which brings us to Capabilities:actor – that which actually enacts the required action with the required level(s) of skill and suchlike.

In a business sense, the capability is often thought of as an ‘asset’, a kind of active asset. Yet the capability doesn’t just appear from nowhere: something – or someone – will do that work, will enact the capability. That ‘something or someone’ is the actor of the capability – which in principle implies that it’s the actor, rather than the capability itself, that is the respective ‘asset’.

Which leads us once again to the asset-dimensions, because there are crucial distinctions here about the relationship between actor and asset:

• physical-dimension: actor is embedded in physical-asset (e.g. machine)
• virtual-dimension: actor is embedded in virtual-asset (e.g. as software)
• relational-dimension: actor is linked with via relational-asset (e.g. person-to-person relationship with worker)
• aspirational-dimension: actor is linked to via aspirational-asset (e.g. person-to-purpose relationship with worker)

The key point here is that whilst machines or software are real business-assets, real-people should never be described as ‘assets’. Although the person might be the actor for the capability in terms of doing the required work, it’s the relational- and aspirational-links between the organisation and that person that are the actual assets here: and if those links are lost, the effective access to the capabilities of that actor are lost as well.

This distinction becomes critical when we need to switch back-and-forth between machine, IT and manual implementations of the same nominal capability – such as is a common requirement in prototyping and process-development, in load-balancing, and in business-continuity and disaster-recovery. It’s easy enough to see that if we don’t have the right machines or the right software on the right IT-servers, it’s going to be difficult to get a job done that needs that capability. It’s also obvious that if we don’t have the machines or the IT, then we’re going to need a real person to do the work.

But it’s not as simple as swapping out one machine and plugging in another (even though classic Taylorism assumes that that is the case) – because even if we find someone with the right capability, we’re not going to be able to access that capability without providing enough reason for that person to engage in the work. That’s why the relational (person-to-person) and aspirational (person-to-purpose) links are so important: they in effect provide that person with the reason to be there, the reason to engage their capability. That’s why we need to understand that, from the organisation’s perspective, it’s the relationship that is the key asset here – and never the person as such.

[There are some other interactions we also need to take into account here, around the Capabilities:skill component. For example, skills for high-variability (Complex and Chaotic) contexts are in most cases available only in real-people, not machines or IT: at certain levels of complexity, we’re going to need a real person, whether we like it not. Yet if the relationship isn’t there, the person may be present, but probably not with the required skill-level: which means that if there isn’t adequate attention to relational- and aspirational-assets, the capability will be unavailable, and the service or process won’t work. Which makes this very important for a service- or process-architecture. Another topic for another post, though.]

Finally, Services are what bring this all together.

To me, services are the core to the architecture: everything in the enterprise is or represents a service, and every service in an enterprise exists to serve in some way the vision of that enterprise.

[Note that the meaning of ‘the enterprise’ here is much larger than the organisation: see ‘What is an enterprise?‘. In enterprise-architecture we develop an architecture for an organisation, but about the extended-enterprise in which that organisation plays its part. Don’t fall for the trap of thinking that the organisation ‘is’ the enterprise: they’re fundamentally different.]

Which leads us to another deliberately-flat definition: a service is something that serves a need within the respective context.

So how does the service serve that need? This is where we bring together all of the above work on asset-types:

— The organisation as a whole, and each of its services at every level of decomposition from ‘business-services’ right down to individual actions and web-services and the like, serve the enterprise by making appropriate changes (CRUD etc) to assets on behalf of other services.

— Assets may be of many different forms or types (such as indicated by the asset-dimensions described here), and, within a service, may be changed from one form or type to another as required.

— Assets are located at, and may be be moved between, specific locations.

— Assets are acted on in response to events.

— Assets are acted on (CRUD etc) as specified by functions and their protocols, service-level agreements, contracts etc.

— The ability to act on assets is embodied by capabilities.

— A service brings together the structure of the function and the capabilities to enact that function, to act on specific assets at specific locations in response to specific events. [Also in accordance with specific decision-types at specific skill-levels, but that’s that other topic again.]

— A process is a kind of pathway – predefined, free-form, or any combination – that links services together in a sequence that delivers required overall changes to assets or to asset-status or ownership or whatever.

And the asset-dimensions weave across all of this, applying to the assets themselves, and to locations, events, functions, capabilities, services and processes, in all of the ways that we’ve explored above.

That’s it, really.

Comments, anyone?