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?

7 Comments on “More on EA and asset-types [4]

  1. Nice finisher! I can’t tell you how many white board sessions I have had with a few friends about developing something that allows us to tie this all together. Nodes, Node types….. We also go back and forth on the services vs. capabilities vs. function issue. You really could throw capabilities out in my opinion. Anyhow, we even looked into working with avail. Perhaps I’ll find the time next year..but it would be so helpful

    • Thanks, Adam – much appreciated!

      Why would you throw capabilities out? I find the distinctions between the function / service / capability triad really useful: a function is a placeholder for where something can be changed, but doesn’t do anything in itself; if necessary (such as in disaster-recovery) we can swap in a different capability or capability:actor so that we can keep the whole thing running.

      (One of the practical complications is that function and capability are usually bundled in IT-systems and machines, but are not bundled when we use human actors – there are some really important implications that arise from that, again especially in disaster-recovery.)

      A capability literally has no function until it’s brought together with a function to deliver a service. And a service serves… well, you’ve seen in the post(s), obviously.

      You’ll see the same distinction in Archimate, actually: the service is behaviour, whereas an actor is active structure. (I think they have it the wrong round, in some ways, but that’s just me. 🙂 )

      One of the sources for the function vs capability vs service farrago is that people aren’t being clear about levels of abstraction, and are trying to use those separate labels to distinguish between the same nominal entity at different levels of abstraction. The point is that these three items repeat on all levels of abstraction (well, up to row-3 and to some extent row-2, anyway), so we shouldn’t use different labels at different levels.

      Be good to talk about this more with you, anyway. Thanks again!

  2. I think I got tied up in your usage of function perhaps and was just stating you could throw it out of your triad. I’ve been using capability models for a good bit of time now and have witnessed the good and bad of them. Bad is normally related to what you stated…

    ” function vs capability vs service farrago is that people aren’t being clear about levels of abstraction, and are trying to use those separate labels to distinguish between the same nominal entity at different levels of abstraction”

    I perceived your usage of function to be business function at a certain level of abstraction that could be perceived as a capability. Sorry..and now based on your reply I think I understand, but lets try an example…

    Capability – Marketing Resource Management – What we are capable of
    Function – Marketing
    Service – Create Marketing Resource

    Capability – Disaster Management:Alert / Notification Management
    Capability:Actor – Disaster Recovery Lead
    Function – Disaster Recovery:Disaster Recovery Triage
    Service – Alert / Notify Disaster Recovery Team

    Perhaps my take on actor is a bit off, but I’m trying not to think to much haha

    • Thanks, Adam

      (Was starting to write a long and detailed explanatory comment, when I realised it would be a lot more use as a blog-post that would be more generally visible to others. I hope that’s okay with you? Should be later today, anyway – if not, kick? 🙂 )

    • “…would be seen as a true process by our BPM friends” – agreed.

      Yet, confusingly, the process can also be bundled as a larger aggregation as a ‘function’ or ‘service’ – in other words, the inverse of how we unpack the internal workings of a function as a set of one or more processes and its sub-processes, sub-functions etc. In that sense, both are ‘true’ depending on how we choose to view it.

Leave a Reply

Your email address will not be published. Required fields are marked *