Services, functions, capabilities and assets

Tom Graves has written extensively about the notions of services, functions, capabilities and assets as well as on how these interrelate and how to tell one from the other.

I strongly recommend reading the following blog posts by Tom:

The following is my interpretation of what I perceive to be the essence of these blog posts. I took the liberty to mix citing and paraphrasing his definitions or what they meant to me. In adapting this for my own work, I’m sure I lost some of the subtleties of Tom’s work. (If any of this doesn’t seem to make sense: Use the source, Luke!)

A service serves a purpose.

A service is a means for realising a desired end.

Services act on assets.

Services share and exchange assets with each other.

An asset is a resource for which a service exercises responsibility.

Services realise functions.

A function is an external view of a service.

Services are actioned by capabilities.

A capability is the ability to do something (appropriate with or on or for something or someone).

Capabilities combine three essential elements: action (think verb + object), actor (or an actor’s agent) and skill-level.

Services link functions and capabilities.

Services are triggered by events.

Services have location.

A process links services.

Some capabilities use processes.

Assets, events and locations can be described in terms of the tetradian dimensions (physical, virtual, relational, aspirational).

Everything in the enterprise can be viewed as a service.

The enterprise itself can be viewed as a service.

The enterprise and its elements described here (services, processes etc.) are layered and recursive: they are fractals.

Have I already said I strongly recommend reading Tom’s posts? Links above.

Updates

2013-05-21: Undid previous change and replaced with a summary statement saying that the enterprise and its element described herein are layered, recursive, fractal as per Tom’s follow-up comment below.

2013-05-20: Added “Services are fractals”, “Processes are fractals”, and “The enterprise itself can be viewed as a service” in response to Tom’s comment below.

Advertisements

6 thoughts on “Services, functions, capabilities and assets

  1. Tom Graves

    Many thanks indeed for this, Oliver – much appreciated!

    The only point I think I would add is that all of this is deeply layered and recursive: services incorporate other services which incorporate and interact with and within other services, and so on. (You’ve hinted at that above, with the quote about “some capabilities use processes”, but in effect that kind of recursion applies to everything.)

    One of the reasons for using this kind of service-oriented view is that it gives us some chance of making sense of all of that recursion. The same sets of relationships occur at every level and in every context, hence we can use this model as a kind of checklist to make sure that our view is complete-enough for whatever purpose we need.

    Thanks again, anyway. 🙂

    Reply
    1. Oliver Baier Post author

      Thank you very much for your response and for letting me work with your material in this way, Tom.

      Trying to act on your comment, I have updated the post stating:
      Services are fractals/recursive.
      Processes are fractals/recursive.
      The enterprise itself can be viewed as a service.

      I think there’s more to it, but I’d like to check my thinking with you before making further updates:

      1. Enterprises are fractals. (a. If the enterprise is viewed as a service, this follows from services are fractals. b. I can envisage a shared-enterprise as contributing towards achieving the purpose of a larger shared-enterprise.)

      2. Functions are atomic. (Maybe we can find a better word. A function is a service interface: there is nothing in here that could be composed, aggregated, nested etc. It’s just an empty shell, a facade.)

      3. Capabilities are fractals. (I can view a capability as incorporating other capabilities. This seems to be an aspect when thinking about capability development within an organisation, but I’m unsure this is very helpful here. It would add another (de-) composition option to the picture (in addition to the one regarding services)…I’m concerned this would muddy the water without adding much practical benefits.)

      Thoughts?

      Thanks!

      Reply
  2. Tom Graves

    Oliver: “Functions are atomic.”

    Not quite – in fact they’re actually just as fractal as every other part of the service-context. Think about it: the interface for an abstract service (a ‘Business Service’, for example) is an aggregation of all of the interfaces of the services that make up the next-more-concrete level of services; and so on, ever deeper into the recursion.

    The only truly ‘atomic’ interfaces are literally atomic: they’re down at the level of the chemical and other relationships between individual atoms. Everything else that we see, from molecules upwards, are abstractions from the interactions right down at that literally-atomic level.

    Hence, just as we get to pick-and-choose about what we call a service or capability or asset or location or whatever, the same is true for functions (functions-as-interfaces). It’s only ‘atomic’ because we say it is 🙂 – nothing more than that. The question then becomes whether it’s useful to say that it ‘is atomic’: and the answer to that is that sometimes it isn’t, and sometimes it is. In other words, as usual, “It depends…” 🙂

    Reply
      1. Tom Graves

        Oliver – apologies if I sounded like an old pain-in-the-proverbial… 😦 – it’s just that keeping everything consistent, without arbitrary special-cases, helps to make everything a heck of a lot simpler than it otherwise would be!

      2. Oliver Baier Post author

        Tom, you didn’t. There just wasn’t much more to say, except perhaps that I’ll update the post accordingly.

        I’m grateful that you’ve been taking the time to help sort out my thinking. I’m all for keeping it simple (and the subject matter isn’t exactly trivial) and consistent.

        So, thank you again. I mean it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s