Definitions on capability
This one’s really straightforward: it’s just a follow-up to a public request on Twitter by Bizzdesign consultant Bas van Gils:
- basvg: I am looking for definitions of these concepts, please help: capability, capability based planning, capability increment, capability map
I’ve no idea what any supposedly ‘official’ definitions might be, but these are the ones I use, based in part on work we did at Australia Post:
— Capability: the ability to do something.
— Capability-based planning: planning to do something, based on capabilities that already exist, and/or that will be added to the existing suite of capabilities; also, identifying the capabilities that would be needed to implement and execute a plan.
— Capability increment: an extension to an existing capability; also, a plan to extend a capability.
— Capability map: a visual and/or textual description of (usually) an organisation’s capabilities.
Yes, I do know that those definitions are terribly bland and generic – and they need to be that way. That’s the whole point: they need to be generic enough to be valid and usable at every possible level and in every possible context – otherwise we’ll introduce yet more confusion to something that’s often way too confused already.
Note what else is intentionally not in that definition of ‘capability‘:
- there’s no actual doing – it’s just an ability to do something, not the usage of that ability
- there’s no ‘how’ – we don’t assume anything about how that capability works, or what it’s made up of
- there’s no ‘why‘ – we don’t assume any particular purpose
- there’s no ‘who‘ – we don’t assume anything about who’s responsible for this capability, or where it sits in an organisational hierarchy or suchlike
We do need all of those items, of course, as we start to flesh out the details of how the capabilities would be implemented and used in real-world practice. But in the core-definition itself, we very carefully don’t – they must not be included in the definition itself.
The reason why we have to be so careful and pedantic about this is because the relationship between service, capability, function and the rest is inherently recursive and fractal: each of them contains all of the others, which in turn each contain all of the others, and so on almost to infinity. If we don’t use deliberately-generic definitions for all of those items, we get ourselves into a tangle very quickly indeed – as can be seen all too easily in the endless definitional-battles about the relationships between ‘business-function’ versus ‘business-process’ versus ‘business-service’ versus ‘business-capability’ and so on.
In principle there are many different ways in which we could sort out the relationships between definitions, but the one I’ve found simplest in practice – and the one I use in modelling with Enterprise Canvas – is to start from an assertion that everything is a service. This then gives us a set of relationships between assets, capabilities, functions and various other types of entities encapsulated ‘within’ each service, that we could represent visually as follows:
Note that ‘capability’ in the above diagram is split into three sub-components:
- action: what kind of ‘thing’ (or combinations of ‘things’) that the capability can act on
- agent: what kind of ‘thing’ does the ‘doing’ in the capability
- skill-level: in essence, the level of variation and uncertainty that the agent(s) and the overall capability can handle
Again, remember that all of this is recursive and fractal: capabilities are made up of services that are made up of all of the above, that in turn are made up of services that… well, you get the picture. 🙂
Another theme that I’ve explored in various posts – such as ‘Service, function and capability (again)‘ and ‘Service, function and capability (an addendum)‘ – is how capability, function and service actually fit together. To quote from the former of those two posts:
- everything in the enterprise is or represents or signifies a service
- a process links services together in some way to achieve some kind of outcome
- a function is an external view of a service – in effect, a description of its interfaces (‘black-box’ view), often together with a summary or overview of what it does and how it does it (‘white-box’ view)
- a capability is the ability to do something
- a function needs to be linked to a capability in order to do anything
- on its own, a capability literally has no function
- in a service-architecture, we link together a function and a capability (and various other service-content items, as in the diagram above) in order to create a service
Another way to summarise this difference is to describe it in terms of the structure of service-level agreements:
- the function describes the parameters of the service-level agreement – which should remain essentially the same for all implementations of the service
- the capability determines the parameter-values to be assigned to those parameters in the service-level agreement – which are likely to be different for each implementation of the service
The function is the outside view of the service; the capabilities deliver ‘the ability to do stuff’ that’s embedded inside the service. Which we could summarise visually as follows:
We can put together the functions (interfaces) and capabilities (‘ability to do something’) in all manner of different ways, providing us with options, for example, to deliver the same nominal service via different capability-agents (as in load-balancing, disaster-recovery and business-continuity) and/or with different skill-levels and competencies (as in customer-service escalation), all through the same function-interface. Or we could switch function-interfaces but use the same services and capabilities behind it (as in cross-platform service-delivery). The point here is that it can be extremely difficult to model all of these interchangeabilities and options for reconfigurations unless we do use flat definitions of this kind.
Given that definition of capability, then capability-based planning is about identifying what capabilities we have (or could have, or need), what we could do with those capabilities, and how we could put them together in different ways with different function-interfaces to deliver whatever services we need. Alternatively, we can run the whole thing the other way round: we would start from the overall need, then identify the services required to deliver that need, then the function-interfaces and service-delivery parameters for those services, and finally derive the capabilities needed within and behind the services – for which we’d then do a gap-analysis between the capabilities we have and the capabilities we need to find.
Which brings us to capability increment, because that’s what we’d need to build whenever there’s a shortfall between the capabilities we have and the capabilities we need.
In turn, that brings up to capability map, which is just a catalogue of capabilities, usually in accordance with some kind of structure or taxonomy (hence ‘map’). Note that if we’re going to be pedantic about it – which we probably should – we’d use the same definitions as above to distinguish between service-map, function-map and capability-map. The purpose of the capability-map is to help us identify what capabilities we have, what relationships we have between them (as per the taxonomy or structure behind the mapping itself), and probably where and under whose responsibility each capability resides – all of which, in turn, is going to be important for capability-based planning and the like.
I can throw in more comment and definitional-stuff if you need it, but I hope that makes enough sense for now? Over to you, anyway.
[Comment posted by Tom Graves on behalf of Charlie Alfred, who’s having difficulty posting via WordPress.]
These definitions sound spot-on. Capabilities are definitely an important and sometimes misunderstood atomic particle.
My view of capability is similar to yours, with a slight twist. While capability is the ability to do something, I refine it a little. I have the “capability” to drum my fingers on the table top or tap my toes. I’m not sure these rise to capabilities, or are merely abilities. I see capability as the ability to deliver value. The “doing” is there, but I think it’s subordinate to the value. A bottle of Evian has the “ability” to be consumed, but the value on hot day is quenching thirst.
This leads to a related point. If capabilities deliver value, then it presumes that there typically is collaboration between multiple parties (typically capability provider and benefit receiver).
I agree entirely that a service “bundles” many capabilities. Whether these capabilities are provided directly or are “outsourced” is a separate matter.
The question I have is where do dependencies go? Are they at the capability level, or service. As a simple example, a stove has the capability to boil water, but I can’t expect to pour a quart of water on my gas stove and have it boil. The capability to boil water depends on (or has a precondition of) a container, and the container must have the ability to hold water without leaking and to not burn. Just curious.
Again, good post. Very clearly stated.
Thanks, Charlie.
In the definitions I’m using here, value is completely separate from capability – and, again, intentionally so. The reason why is that we may use capabilities in many different ways – as responses to affordances, in fact. Delivered-value comes from the integration of capabilities and other elements into a service – not from the capability itself.
Outsourcing is again another matter – that’s part of one of the reasons why I separate capabilities from services, so that a service can be implemented in multiple black-boxed ways.
Dependencies – yep, that’s another interesting theme and question. In effect, it’s dealt with by the recursion here: a capabilities is typically implemented by services, which themselves combine assets (e.g. container and stove) and function-interfaces (stove as heat-interface for container) and their respective service-parameters and parameter-values for the functions (‘water is boiling’, ‘no leak’, ‘not burn’ etc).
I’m well aware it’s a slightly weird discipline at first, this somewhat-pedantic separation of elements, but it really does pay off once we get deeply nested into some of the recursions and substitutions that can take place here.
Tom,
I think your definition of capability (the ability to do something) misses two important aspects.
1) Capability is always about performance. For example, the US military require that “Capability definitions must contain the required attributes with appropriate measures of effectiveness”.
Just ability to play chess is very different with ability to win the chess world championship.
2) The requested performance must be proven. Just a declaration is not enough.
So, capability is the proven possession of characteristics required to perform a certain kind of work (i.e. as a particular service to produce a particular result) with the expected performance
Thanks,
AS
Thanks, Alexander.
If the definitions weren’t recursive, then yes, you’d be right, there would be a lot missing here.
But since they are recursive, centering around the core-concept of ‘service’, then actually, no, there isn’t anything missing. (At least, not in terms of what you’ve said above, anyway. 🙂 )
1. Performance: This is (intentionally) not part of the capability itself: it’s associated primarily with the function (interface-parameters), which is then merged into a service. The capability for chess-playing is just the ability to play chess: nothing else. The service-level parameters indicate the level-of-service required, and thence the type of capability you’d need – which would typically be bundled into and indicated by the exposed services that make up that capability. ‘Ability to play chess well enough to win the chess world championship’ is a capability that includes services within itself that can self-test for that requirement.
2. Proof of performance: Performance is an attribute of a service – not of a capability as such. If you do need to attach such attributes to a capability, you would attach it to the services that are embedded in the capability. A simple solution is you get challenged on ‘proof of performance’ and suchlike is this: if in doubt, go down one level of recursion.
Recursion is the absolute key to all of this. The point that so many people seem to struggle with here is the way in which recursion allows us to keep to strictly consistent definitions for all of the element-types (asset, function, location , capability, event, decision). The moment we forget about the recursion, we’re then all but forced into using inconsistent definitions, which leads us straight into impenetrable thickets of arbitrary definitions and arbitrary assumptions. Which is what we fight most of the time in enterprise-architectures and the like. As I’ve just said above to Charlie Alfred, a lot of what I’m describing here can often sound pernickety and pedantic at first (even seemingly-pointless at first?), but it really starts to pay off as soon as we start to move outside of single-domain single-technology short-term ‘solutions’ – in other words, as soon as we start to do anything that genuinely does resemble a real enterprise-scope architecture.
I don’t know why so many people seem to struggle with such recursion – after, all recursion and fractal self-similarity and suchlike have been a standard part of computer-science (and much else besides) for a fair few decades now. It’s true that the definition-set for capabilities and suchlike that I’ve summarised above will only make sense in context of recursion; but since the inevitable alternative is a definitional-babel, it’s probably wise for people to put in the small amount of extra effort to understand how that recursion works, wouldn’t you think?
Two other quick points I need to add.
One is that although that definition of ‘capability’ as ‘the ability to do something’ is primarily about the ‘doing‘ (or more accurately, ‘potential to do’), remember that the other half of that definition is about the ‘something’ that is to be done. What is that something? What is to be done with or to or around or about it? In practice, that ‘something’ part tends to be expressed in terms of assets or services or events or suchlike that are embedded recursively within the nominal capability.
The other point – and this is really important – is that I do not in any way claim that these definitions are ‘the truth’. It’s just an interlinked, interrelated set of definitions that, when used as specified, in a consistent way, have proven useful towards achieving a particular type of outcome. That’s all they are: useful, not ‘true’. If you’re going to use them, please do use them in the manner specified, because that’s the way you’ll get best results; but it’s perfectly fine if you’re not going to use them, and you use the usual other definitions instead. (But if you do that, don’t complain if you end up in the usual definitional-fights and contextual-chaos, okay? 🙂 )
Hi Tom,
Several of my blog posts talked about Business Capabilities, including this one.
http://ingenia.wordpress.com/2013/06/16/business-capability-based-ea-roadmap/
Enjoy
Adrian
Hi Tom, Enjoying rereading this article at the moment 🙂
I’m curious as to the link between capability definition as described here, and methods for quality definition (which of course links to effectiveness criteria). Is quality defined by composite asset/function/event specifications within service recursion?