There is a particular meeting most architects have sat through. The business explains what it wants to be able to do next year. IT explains which systems exist and what they cost. Both sides are precise, both sides are telling the truth, and neither is talking about the same thing. An hour and a half later, a follow-up meeting is scheduled.
What is missing in that room is a word both sides can use without giving up precision. That word is business capability.
The definition, and the one thing that makes it useful
A business capability is something the organisation has to be able to do. Manage customer orders. Onboard a new employee. Settle a claim. Approve a credit application.
Notice what the phrasing leaves out. It does not name a department. It does not name a system. It says nothing about the order in which the work happens. It says what, never how.
The Open Group puts it in the TOGAF standard as "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome". It is a dry definition, but it carries the important part: a capability is an ability, not an activity and not an asset.
The three things a capability is not
Most capability maps that fail, fail in one of three ways.
It is not a process. A process describes how. "Order intake, steps one to seven" is a process. It gets rewritten every time someone improves something, which is often, and thankfully so. The capability "Manage customer orders" is the same before and after. Rule of thumb: if there is a verb implying a workflow, a process has crept onto the map.
It is not an application. "Order management in D365" is not a capability. It is a means of realising one. The distinction matters the day D365 gets replaced, because the capability still has to be performed afterwards. A map where system names have slipped in as headings has to be redrawn every time something is swapped out, and by then half the point is gone.
It is not a department. This is the most common mistake, because it is the easiest one to make. The org chart is right there, it has already been approved, and it looks tidy. But a capability map that follows the organisation has to be redrawn every time someone moves a team. Worse, it can no longer reveal that three units are doing exactly the same thing under three different names, and that was one of the reasons for drawing the map.
Stability is the whole point
Everything else in an enterprise landscape moves. Processes get optimised continuously. Applications are replaced every five to ten years. Departments shift whenever a new leader arrives. Vendors come and go.
Capabilities stay still. Not forever, but long enough to build on. TOGAF describes the property directly: the capability map "provides a self-contained view of the business that is independent of the current organizational structure, business processes, information systems and applications".
That is why the capability is the right hook to hang the rest on. Applications link to the capabilities they realise. Costs follow the applications. Strategic objectives require particular capabilities. Decisions concern particular capabilities. With the stable layer in the middle, the links survive even when the ends get replaced.
Without that layer you only have direct connections between things that move independently. Which is why, in practice, an overview evaporates within about eighteen months, however good it was on the day it was made.
How the map is built
A capability map is a hierarchy, in practice three levels deep.
Level one is what the business is built from. There should be few enough that people can hold them in their heads, in practice around seven to ten. If nobody can recite the top level without looking it up, the map has stopped being a shared language and become a document.
Levels two and three make the capabilities concrete enough that each application can be placed somewhere specific. That is what lets the map answer anything at all.
Level four does not exist. Or rather: go one level deeper and you have usually stopped describing what the organisation needs to be able to do and started describing how it does it. That is a process description in disguise, and it belongs elsewhere in the model.
There is a test for whether the structure holds: can a level-two capability be placed without an argument? If people have to negotiate where it belongs, the map overlaps itself, and it will not be able to find overlap in the portfolio later.
You do not have to invent the structure either. APQC's Process Classification Framework is openly available, covers thirteen top-level categories, and in version 8.0 includes a category called precisely Develop and Manage Business Capabilities. It is a starting point, not a straitjacket, and it saves the three workshops otherwise spent agreeing on headings.
A note on terminology
Capability is not competency, and it is not a function. A competency sits with people. A function sits in an org chart. A capability sits with the business as a whole, and it is deliberately indifferent to who performs it.
The distinction sounds pedantic until the first workshop, where someone proposes "Finance" as a level-one capability. Finance is a department. What the business needs to be able to do is manage financial resources, which is a different sentence and a more useful one, because it survives the day finance is partly outsourced and partly automated.
What the map can answer once it is linked
A capability map hanging on a wall is a nice picture. The value appears in the link to the applications, and it appears sooner than people expect. The first time the application list meets the map, two things happen by themselves: some cells are empty, and some are crowded. Both are findings.
From there you can answer questions that previously required a round of emails:
Which systems carry the thing we cannot lose? Look up the critical capability and see what hangs off it.
Where do our tools overlap? Look for capabilities with three applications on them. That is rarely a coincidence.
What breaks if a vendor goes away? Follow the chain from application to capability to the objective the capability was meant to serve.
What does the strategy we promised the board actually cost to run? Roll the cost up through the capabilities to the objectives. That is the question a flat portfolio tool cannot answer, because it has no strategy layer.
How you know you got it right
There is a single sign, and it has nothing to do with how the map looks.
You got it right the day someone makes a decision on it. Not references it in a slide, not praises it in a steering committee. Decides something. Chooses to consolidate two systems because they sit on the same capability. Defers an investment because the maturity gap is somewhere else. Answers an auditor without commissioning an analysis first.
Until then the map is a hypothesis about how the business fits together. That is not nothing, but it is not what the work was started for either.
Spekir builds the layer that connects strategy to the IT portfolio. See Atlas