What is a capability map and what is it actually for?

A capability map is a representation of what an organization knows how to do, independent of how it does it today or who is in charge of it. A capability describes a stable what, such as "process orders", while the process that carries it out describes the how, and that how keeps changing: people, tools, software all turn over. This distinction, taken from the business capability model in enterprise architecture, is what keeps the map useful past the day it was drawn: a company reorganizes its teams, replaces an ERP, and the list of capabilities underneath stays nearly the same, describing the business rather than the current org chart. On its own, a map is just a poster: drawing the boxes is not the value. The value appears when each capability is overlaid with how strategically important it is and how good the organization is at it today, producing a heat map that shows the capabilities that are both critical to strategy and weak.

Why depth is the most common trap

The typical mistake is going too deep, though no rule forbids it. The Open Group's TOGAF Series Guide Business Capabilities, which takes the concept from Ulrich Homann's 2006 white paper, sets no ceiling at all and in fact reports three to six levels of decomposition as common, noting that the deeper levels serve architects and planners while an executive may only want the first. That is the distinction that gets lost: taking the full decomposition into a boardroom turns the exercise into a process map disguised as a capability map, with hundreds of boxes no executive will ever use to decide anything. An investment decision needs two levels, the first holding the broad areas ("sell", "produce", "serve the customer") and the second capabilities that whoever owns them can recognize: if the map needs a thirty-minute legend, it has already lost the purpose it was built for.

An enterprise example

An eighty-person manufacturing company is weighing whether to start a predictive maintenance AI project, because a vendor pitched it and a competitor announced one on social media. Before choosing any technology, it draws a two-level capability map of the operations and supply chain areas: "plan production", "manage maintenance", "manage suppliers", "control quality". For each one it scores two axes, how much it matters for the next three years of strategy and how good the company actually is at it today, using a three-point scale filled in by the people who do the work daily, not by management. The result overturns the starting assumption: "manage maintenance" matters but is already decent, while "manage suppliers" is critical to strategy and weak, because it still runs on email and a shared spreadsheet. The maintenance AI project would have improved something already acceptable while leaving the real bottleneck untouched.

Why it matters for decision-makers

A capability map is the tool that makes AI use case selection defensible: it shows where the organization is weak in what actually matters for strategy, instead of letting the choice start from whatever technology someone already has in-house or saw in a demo. It should be kept distinct from a bounded context, which sits a level below and describes a software model, not a business activity: one capability can be served by several bounded contexts, and one bounded context can serve several capabilities. It should also be kept distinct from how teams are organized, the territory of Team Topologies and Conway's law: the map states what needs doing well, not who does it or how those people are organized. Whoever is deciding where to invest does not need a poster: they need to know which two or three capabilities are both critical and weak, because that, and only that, is where a euro of investment pays off the most.