This is what I talk about when I say capability

This post has been updated, and all updated text should be highlighted blue.

I was asked the question I love to get the other day, “what do you mean by capability?”. I usually try to be brief when I explain my point of view and so I was this time to. However in this post I’ve elaborated somewhat on the details of my explanation. This is not the last answer on this topic but it will give an indication to how I’m currently viewing capabilities.

My first attempt at getting some sort of definition down

Only a “whole” can contain a capability. Thus a human or an organization could be said to be able to posses capabilities to perform a certain set of activities that will ensure delivery of an anticipated value. An application, a device or any combination of products and services can not be said to be able to contain capabilities. Applications, devices and such types of things contain functions. These functions are at times marketed under the label “capabilities”, but they are functions nothing else.

Where I am now NOT including the above

I once created a 7 day training on Enterprise architecture from a holistic and practical perspective. In that course on day five or six it must have been, I challenged everyone to explore the possibility of viewing a complete business model as one capability of the business. Why may I have this view on capabilities one may ask. The business model as I’m used to describe them is a static description of how the enterprise will service the customer, as well as how it will utilize the services of other organizations. In my mind this idea of business models as capabilities fits well with the notion that only animate and social systems can be purposeful (1).
Some assumptions:
  • The business model is a complete architecture description in such a sense that it covers the whole that we seek to explore.
  • The business model represents a high level perspective of the detailed architecture.
  • Using the business model as a foundation we can detail things as far as we need to understand them in a solutions perspective.
  • When a business model needs to change there is a possibility that the underlying capability will need to change.
  • We can pre-produce business models and put them on the shelves.
  • We select the business models we would like to use.
  • Business functions in general is a configuration used across a set of capabilities.
Some rough definitions:
  • Business model = A static description of what a business must coordinate to meet a coherent set of value propositions.
  • Value proposition = The perceived value of the products and services offered as viewed from the customers perspective.
  • Customer segments = The way we segment the customers and non-customers in the market as targets for the offered value propositions.
  • Customer relations = The link we maintain between the customer segments and the value proposition.
  • Processes = The activities we need to perform to be able to service the value propositions.
  • Value network = The partners and suppliers we work together with in our processes.
  • Resources = The things and competences we use in our processes.
  • Costs = The collection of costs accrued by executing the business model.
  • Revenue = The collection of revenues generated by the customer segments as they consume the value propositions.
What is a complete business model?
One may ask what do I mean by a complete business model, and why is that different from any one business model? When I use the business model framework I may use it on different levels within an enterprise. Using the business model framework like this means that there will be business models that are not of a directly value creating perspective, rather they are supporting the value creation/value consumption. The easy way to spot these supporting structures is to look at the customer segments. If there are only enterprise internal customer segments then this is a supporting business model. I would not consider a supporting business model a capability but rather a function that must be performed within a larger structure. I do however consider it appropriate to use the business model framework as a means to design and link these supporting functions.
Why is a supporting business model a business function and not a business capability?
A supporting business model as one could construct for human resources, finance or IT has no intent outside of the intent of the complete business. Yes you may very well have HR-, Finance- and IT-strategies but they are just relative to the business strategy. Each business function maintains its autonomy relative to the constraints set by its environment, but contributes to the production of the larger enterprise system. Each and everyone of these business functions will make use of parts of the capabilities available to the enterprise, but that does not make them a capability of their own right. As I’ve come to see it there there is a true difference between a business function and a business capability. Let me make it clear that what I describe in this section is not aimed at defining what makes up a business model or a business function, it is about using a tool designed to find business models to find candidate business functions.
The good things with this definition
If one use the definition that I’ve described above then
  • There will not be an abundant of capabilities floating around in the enterprise.
  • The very small set of capabilities is the focus of the entire enterprise.
  • There is no need for capabilities within capabilities.
  • Functions clearly hold their own right to be in the architecture.

4 thoughts on “This is what I talk about when I say capability

  1. Very interesting perspective Jörgen. I’m intrigued that this definition is entirely dependent upon the boundaries of what is considered a “whole”, which is a purely subjective definition since system thinking demonstrates nearly anything can be considered to be merely one level in a hierarchy (both up and down) of systems.

    Admitting a system can be composed of specialised sub-systems, which themselves can be considered as loosely-coupled, autonomous systems in their own right and delivering an anticipated value to the higher level system, surely leads to the concept of nested capabilities (rather than just functions at sub-system level)?

    It could be counter-argued that specialised sub-systems may not be viable as independent entities in their own right, which would restore the primacy of capabilities only appearing at the highest system level.

    However, from an analysis perspective, it can get confusing to have to work with two very similar concepts – functions and capabilities – and my preference is to let the services crossing the system boundary define the organisational purpose (along with a few strategic things that typically don’t appear).

    To be continued … :-)

    I like the blog – excellent work.

  2. Jörgen,

    The concept of ‘capability’ is a matter of convention. Whenever some meaning works, I’m happy to let that pattern stabilise and spread out.

    If I remember well, the ‘capability’ as an EA concept, first appeared in DoDAF. Then at certain point, Microsoft announced something like this: “function didn’t work, then processes appeared, they were an improvement but not as good as services which came later but that’s nothing compared to the ‘truth’ and that is.. capabilities”. And it seems that many Enterprise Architects share that view of capabilities being a combination of processes, people, technologies, know-how etc. and appearing only on strategic level.

    When you say that “Only a “whole” can contain a capability… An application, a device or any combination of products and services can not be said to be able to contain capabilities”, I have the feeling that you more or less side with that usage of the term ‘capability’. Please correct me if I’m wrong.

    In any case, the way I use capability allows an application, service, device, machine, component, people, organisation etc to have a set of capabilities. I find myself agreeing with the concept of ‘capability’ as supported in OASIS and other SOA sources though I feel uncomfortable directly associating it with SOA which is currently over-associated with technology concepts like ESB, web services, REST and the like. No, my view have nothing to do with that. It’s just a way to describe existing or future ability of an active element of a system as a ‘supply’ as well as the need of a behavioural element of a system as a ‘demand’. That helps a lot in EA analysis and can be supported by reasoning technologies (actually it’s done already, by several tools). Again, nothing IT-centric, IT-supported at most. Both a radiator and an oven have the capability to ‘increase the temperature of the surrounding air’, but one realises the service of ‘cooking’ and the other of ‘heating’ and this is the value we utilise. Now, the natural question is why not use ‘function’ instead of ‘capability’? The reason is that ‘function’ in EA context is something you assign resource to. While ‘capability’ is something inherent for the utility of an active element of a system.

    Well, the actual answer is much longer than that. Probably will write it in a separate post. In any case thank you for bringing this up. Sorry, I didn’t include references. If you are interested, drop me a mail.

  3. One more thing. The ‘business model’ should be a dynamic description if it is to bring any value. But there could be many ‘views’ of the business model which are indeed, static.

  4. I’d agree pretty strongly with Ivo here: capability is simply “the ability to do something”. More details on that in the last part of my ‘EA and asset-types’ series:

    Business-model? – I would incline to the Osterwalder view (as per ‘Business Model Generation’), that it’s how the organisation structures ‘the business of its business’. Osterwalder’s model is geared to commercial business, but with a few tweaks it works fairly well for the business of government-departments and not-for-profits too.

    I’ll also echo David Hollings’ comment: you’re doing great work here, always pushing the boundaries whilst still keeping it grounded and practical. I really value a lot of the ideas you’ve developed – particularly that ‘The Art of Architecture’ series, and the ‘Lego for Enterprise Architecture’. Many thanks – and keep going! :-)

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s