Architecture Strategy

How to recognise a Capability

An updated version of this article is in my book “Design To Win”. You can still just learn it from here. However, there’s a vast amount of information and diagrams in the book about the rest of Enterprise Architecture. Click here for links to the Amazon page.

There seems to be a problem with definitions of Capability — most of the good ones were written long before the web. So you have to go hunting in old MBA text books and the like to find a definition. The term Capability has been used by the military for hundreds of years and was borrowed first by engineering then by business. In business, Capability Management has been around for decades and leads to quotes like it is ’based on the “theory of the firm” as a collection of capabilities that may be exercised to earn revenues in the marketplace and compete with other firms in the industry.’ which is taken from

Two reasonable definitions that I dug up are:

What the company needs to be able to do to execute its business strategy (e.g. support customers through any medium — telephone, fax, the Web, etc.). These capabilities are operational in nature. — The Capable Company (2003)


The ability to reliably and consistently deliver a specified outcome relevant to your business (i.e. in support of your way to play). This capability is ensured through the right combination of processes, tools, knowledge, skills, and organization, all focussed on meeting the desired result. The most important capabilities are distinctive: each of them represents an extraordinary competence that few others can master. — The Essential Advantage (2010)

That’s not a recommendation for those books, I just went hunting on Amazon as my old books are all in boxes. Many of us EA types start off thinking about Capability upside-down or inside-out. We think it’s something like a Function or a Service or Competence. However, those are all inside the enterprise looking inwards. Capability is something you can only see from inside the enterprise looking out to a market or from outside the enterprise. You have to think of the enterprise as a black box. You have no idea what’s inside it but you know what either you or your customers can use it to achieve.

A tank has a Capability to travel across rough terrain.

If there is a traffic jam, either of my motorbikes has the Capability to sneak between the cars. The Yamaha’s implementation of that Capability is much stronger than the Harley’s. There is no “sneak between cars” button on either of my motorcycles yet both have that Capability. It is implicit in their design. Note that the Capability is not with me, the operator of the vehicle. I have Competence. Put me in a dump truck and that Competence is useless because the dump truck does not have the Capability “sneak between cars”.

That business mentioned in The Capable Company might also have the Capability to deliver goods to customers.

Those examples all use the term Capability the same way: [Black Box] has a [Capability] that can be used in [external environment]. The tank’s environment is rough terrain. The motorbikes’ environment is the road. The business’ environment is its market (its customer base).

That a business has a Capability says nothing about how it does it. Which is one of the key points. With a Capability, you should be able to change its underlying Functions, Services, Processes, Resources and so on but have the Capability still remain. For instance, the business that has the delivery Capability might switch from using a to courier to its own fleet of vehicles. It’s the same Capability but a different implementation.

A Capability can come from anything. Any object (real or notional) in any part of the business. There can be small things buried deep in the organisation that determine whether or not a Capability exists.

Basic ones. A retailer has “goods in”, “advertise goods” and “accept payment” capabilities. In each of those cases, it would probably have corresponding Function or Service that was the implementation of the Capability. However, the Capabilities themselves say nothing about how they are implemented. The Functions and Services that underlie them could change completely and the Capabilities could remain exactly the same.

More advanced. A data centre company wants to apply for government data storage contracts. To do so, all of its staff with physical or administrative access to the data centre must have a certificate that they passed a government security check. So even though the company’s Core Competencies, Functions, Processes, Services, etc. all stay exactly the same, one missing certificate can remove the Capability to apply for government data storage contracts.

One of the major points about a Capability is that it might not exist yet. By saying that a retailer wants a Capability called “next day delivery” we are saying absolutely nothing about how to implement it. Will it be implemented as a Service? Probably. But what if the retailer decides to outsource the problem? The Capability remains whether the retailer owns the Service or not.

A last example and it’s from the military. “Boots on the ground anywhere in the world within 24 hours” is a well-known military Capability. It tells the whole story to whoever wants to use that Capability. It says absolutely nothing about how it will be done. Indeed, the How will be hugely different depending on where in the world, what time of day, what opposition will be faced, etc.

Capability’s proper use is in describing potential interaction with the environment of the thing that delivers/creates the Capability. So it’s a good starting point for EA if someone has identified a gap in the market or for the exec to use as a way of understanding how they can interact with a market. They can point at the gap and say, “we need a Capability to address that gap in the market.”

However, Capability can be used to describe what goes on inside an organisation too — normally Capabilities are External but they can be Internal. Unfortunately, that seems to have caused some serious problems. If you go hunting around on the web for a definition of Capability, it is quite difficult to find genuine ones. I’ve given up. All of the ones I found are spurious.

In turn, those spurious definitions seem to have led to the serious problem that, if you try to find examples of Business Capability Maps, you might never find one. I went through the first 100 or so on Google Images and all of the things that claimed to be “Business Capability Maps” were not. Most of them were Function Maps; I have no idea what the rest were supposed to be.

Maybe the problem is that Capability was rediscovered and became a buzzword about a decade ago. Not many people knew how to describe them because they are a Business Consulting/MBA tool. But lots of IT people and business analysts who knew nothing about the subject produced fake “Capability Maps” and published them on their blogs. Now the real ones are impossible to find and fakes are all that’s left.

To make matters worse, the people who wrote the TOGAF Business Capability Guide seem to have used things like that as their source material. It seems the blind are leading the blind.

Let me leave you with a quote from Mark Goetsch — “Think of capabilities as the strands that weave together services and functions into its unique positioning in a competitive landscape. The paradigm for this is resources-competencies-capabilities. Resources are acquired by the firm (Capital), transformed into competencies (functions and services) and exposed as capabilities (the unique positioning of the firm). This is what connects tactical and strategic action. For the first 100 years of the industrial age (1860-1960) services and functions were enough. This was the theory of business enterprise by Veblen in 1904. Build it and they will come. Chandler refined the concept of a business as an enterprise with overwhelming evidence across hundreds of companies over a 150 year period finding that this worked. Mergers and acquisitions in the 1980’s destroyed this view as companies that relied on these strategies became buy-out targets.  Companies needed a way of positioning that went beyond services. This is what Teece et. al. are addressing with capabilities.”

[Update 17th Nov 2019] Here’s my personal definition that might work for you too after reading the above.

Business Capability:
The ability to reliably and consistently achieve a desired effect in a market. It can be delivered by any object (real or notional) in any part of the business or any combination of them. For example it could be delivered by an individual Process, Role, Location, Service, Competence, system, piece of software, skillset, etc. or any combination of those things. It might be something as big as a set of buildings and all of the operations within; or as small as a few lines of code. However, it must be important or unique enough to a market that the executives of the business should be made aware that its use is significant to business strategy or operations. It is normally named for the desired effect.

Scaling that down to a black box system:
The ability to reliably and consistently achieve a desired effect in an environment external to the system. It can be delivered by any component (real or notional) in any part of the system or any combination of them. However, it must be important or unique enough to an environment external to the system that the operators of the system should be made aware that it is significant to the available uses of the system. It is normally named for the desired effect.

For internal Capabilities — those that are delivered and used inside the organisation — you should use the black box definition. In other words, consider a Process/Function/Service/etc. as the black box and, for example, swap the word “system” for “Process” in the black box definition.


[Update 13th Jan 2020] To give you a flavour of the mindset you need to develop, a recent example was shown to me where someone had confused Capability with Function. They had identified a need in the business and called it “Document Capture” with a “Scan Document” as a supporting Capability. Those are both inward looking, self-contained and say nothing as to the desired effect; both have already chosen a solution just at different levels of detail. In other words, they are Functions.

A Capability would be something like “Printed Documents Made Available Electronically” or “Paperless Where Possible”. Those define the desired effect and not a path to the solution or how to do it. They open up possibilities like requesting all suppliers send PDF invoices to the Finance department rather than paper ones, saving the expense of a load of scanners that is already implied in “Document Capture”.


[Update 16th Jan 2020] Another example of possible confusion of Capability with Function came up in a friend’s work for a Bank. He had labelled Loans as a Capability. It certainly can be a Capability but it could easily be a Function, high-level Process, Org-Unit, etc. The name Loans gives no real clue as to the desired effect. So let’s break it down.

For a start, there is definitely a “Loans” Function in his bank that gives loans whether the Function is called that or not. So we can ask the questions:

Who or what uses the Loans Function?
What effect does that thing or person gain by using it?

The answers are “bank customers” and “temporarily increase liquidity”. That tells us the desired effect is “temporarily increase liquidity for bank customers”. Which is a Capability of the bank. We can abbreviate that to the slightly nicer, “Temporarily Increase Customer Liquidity”.

Now we have something very, very different from the “Loans” Function which specifically tells us How we are going to increase customers liquidity. The name of the Capability leaves us with a lot more options for How. For instance, maybe a bigger overdraft facility will achieve the desired effect that is “Temporarily Increase Customer Liquidity”.


[Update 13th Jan 2020] From my EA Thought of the Day:

In business, Capabilities are useful for external markets but of questionable value internally. The term Capability comes from the military where it makes sense. Every piece of terrain is different and every opposing force has its skills so, if you are asked to secure a hill, the Capabilities you need depend on the hill and the opposing forces trying to prevent your success. Whereas, across the world, business departments and their staff skills are similar from enterprise to enterprise. Some of them are even eager for your success.


[Update 17th Apr 2020] With thanks to an excellent example from James McGovern:
There are three insurance companies,, and has no “Direct Sales” Capability. They only sell through agents. has a “Direct Sales” Capability that is delivered by its Sales Function operating a call centre. has a “Direct Sales” Capability that is delivered by a bespoke web app developed and run by its in-house DevOps Function. has no Sales Function. signs a contract… will host an version of the web app but still selling insurance. will operate it and give a percentage of every sale. now has a “Direct Sales” Capability and the thing that has given it that Capability is a contract.


[Update 13th May 2020] How to spot a fake Capability Diagram
One of the big problems in learning about Capability is that the Internet is full of fake Capability diagrams. There’s an easy way to spot them: they are littered with Management. The word Management on the end of the name of an alleged Capability should set alarm bells ringing. Most of the time, things that end in the word Management are Functions not Capabilities. The way to tell the difference is to ask whether it is managing something inside itself or outside. If it’s inside, it’s a Function.

So, if you see something like “Payments Management” ask yourself, are they doing that for a customer? If not, it’s almost certainly a Function.


[Update 9th Nov 2020] Capability vs Function
Let’s say there is something called Finance Management. Is it a Capability or a Function? A quick examination is all it needs.

Finance Management — as part of any products or services you offer, you can help your customers to manage their finances.
Finance Management — as part of what your Finance department does internally and through its requirements on other departments, your organisation can manage its finances.

The first is a Capability; the second a Function. If you think it through, the second is pretty much a redundant concept. If they couldn’t do Finance Management, why on Earth would you have a Finance department?


[Update 1st Oct 2022] A physical example of Capability
This is one for the photographers. An ND Filter (neutral density) gives a good example of the difference between Function and Capability. Its Function is to reduce the amount of light hitting the sensor/film — that’s about what’s happening inside the camera. Its Capability is to allow us to take a picture in bright light — that’s about what’s happening outside the camera.


[Update 28th Nov 2022] Recently, someone gave me a questionable definition of Capability: “a combination of people, process, technology that converts inputs to desired outcomes and Value from the perspective of recipients of outcomes within and outside the organization.” — which is very similar to the definition of Function. The only difference it’s “outcomes” instead of “outputs”. To me, the definition misses an important point. The start — “a combination of people, process, technology that converts inputs” — is the Function that delivers the output associated with the Capability. The business can use the output to potentially achieve a desired effect. To be fair, a lot of people use the word Capability to mean the whole thing: the combination of the Function, it’s outputs and the resulting potential to achieve an outcome.

The upshot is you can understand Capability this way:
Function [people, process, technology, etc.] converts inputs to outputs
[the business can potentially use the outputs to achieve a desired effect]

Function: build a bridge
Capability: cross a river