Aldermont's leadership wants to know one thing before it commits hundreds of millions of dollars to the core consolidation: where is the bank actually weak? Not which team is understaffed, not which project is late, but which of the fundamental things the bank does are being done badly, expensively, or three times over. It is a simple question and nobody in the room can answer it cleanly, because every answer they reach for is really an answer to a different question.
Someone pulls up the org chart. That shows who reports to whom, not what the bank does. Someone else pulls up a process diagram for mortgage origination. That shows one workflow in detail, not the whole bank at a glance. The question "what does this bank do, and how well" has no artifact to answer it, and that absence is exactly the gap a capability map fills.
What a capability is
Start with the unit. A business capability is something an organization is able to do, expressed independently of how it does it, who does it, or what technology supports it. "Originate a mortgage" is a capability. So is "detect fraud," "onboard a customer," and "settle a payment." Each names an ability the bank has, in stable business language.
The defining trait is stability. A capability is deliberately abstracted away from implementation, so it stays constant even as everything underneath it changes. Aldermont has replaced the software behind "originate a mortgage" three times and reorganized the team that runs it more than once. The capability never moved. That stability is what makes capabilities useful as a fixed frame of reference: they are the one description of the bank that does not shift every time a system is swapped or a department is renamed.
The core idea: A capability answers what the organization can do, never how, who, or with what. "Originate a mortgage" is a capability. "The mortgage team," "the loan origination system," and "the underwriting workflow" are answers to different questions. Keeping the what separate from the how is the entire discipline.
A capability map is simply the complete, organized set of these capabilities for an entire organization, laid out on a single page. It is a picture of everything the business is able to do, with no reference to structure, sequence, or systems.
How a capability map is structured
Capabilities are organized hierarchically, decomposed from broad to specific. At the top sit a handful of high-level capabilities, each of which breaks down into more granular ones, which can break down further still. The top level is usually stable enough to fit on one page and change rarely; the lower levels carry the detail.
For Aldermont, the top level might be a small set of groupings: customer management, lending, payments, deposits, risk and compliance, and the supporting capabilities like finance and human resources. Each decomposes. "Lending" contains "originate a loan," "service a loan," "manage collections." "Originate a loan" decomposes further into "assess creditworthiness," "price the loan," "make a decision," "book the loan."
One discipline governs the whole structure: every box is a noun-plus-verb ability, never a team, a system, or a step. The moment "the mortgage department" or "the loan origination platform" appears on the map, it has stopped being a capability map and become one of the two artifacts it is constantly confused with. Those two are worth separating carefully, because the confusion is the single most common reason capability maps fail to deliver value.
Not an org chart
The most frequent mistake is treating a capability map as a reorganized org chart. They look superficially similar, both are boxes in a hierarchy, but they answer completely different questions, and conflating them destroys the capability map's usefulness.
An org chart shows structure: who reports to whom, how people are grouped into teams and divisions. It changes every time the organization reshuffles. A capability map shows ability: what the organization can do, regardless of who is currently organized to do it. It stays stable through reorganizations.
The distinction has teeth at Aldermont precisely because of its acquisition history. The bank has, at various points, had two or even three separate departments all delivering the same capability, because each acquired bank brought its own version. On an org chart, those appear as three legitimate, separate boxes. On a capability map, they collapse into one: "maintain a customer relationship" is a single capability that the bank happens, wastefully, to deliver three times. That collapse is the insight. The capability map reveals the duplication that the org chart, by its nature, hides. If you build your capability map by copying your org chart, you inherit the duplication and learn nothing.
Not a process map
The second confusion is with process maps, and it runs the opposite direction. Where the org-chart mistake adds structure, the process-map mistake adds sequence.
A process map shows flow: the ordered sequence of steps that accomplishes something, with a beginning, an end, decision points, and handoffs. "Mortgage application received, credit checked, underwritten, approved, funds disbursed" is a process. It is inherently about time and order.
A capability is timeless and orderless. "Assess creditworthiness" is a thing the bank can do; it does not have steps or a sequence at the capability level. The relationship between the two is that processes use capabilities: the mortgage-origination process invokes the "assess creditworthiness" capability at a particular moment in its flow. But the capability exists independently of that or any other process, and the same capability is used by many processes. Aldermont's fraud-detection capability is invoked during account opening, during a wire transfer, and during a card transaction, three different processes drawing on one capability.
Seeing the same subject rendered all three ways makes the distinction concrete.
Hold onto the three questions and the confusion dissolves. Org charts answer who. Process maps answer when. Capability maps answer what. Only the last one gives leadership a stable, duplication-revealing picture of the whole bank, which is exactly what the opening question demanded.
What the map is actually for — heat-mapping
A capability map on its own is just an inventory. Its power comes from what you can overlay on it. Because the map is a stable, complete picture of what the organization does, it makes an ideal backdrop for painting on other information, and the most common and most useful overlay is a heat map.
Heat-mapping means coloring each capability according to some dimension of interest. How healthy is the technology supporting it? How strategically important is it? How much does it cost to run? How much risk does it carry? Color the capabilities red, amber, and green against one of these questions and the whole organization's condition appears on a single page, in the one frame that does not shift when teams and systems change.
This is precisely how Aldermont answers the opening question. Overlay technology health on the capability map, and the picture is immediate: the capabilities still running on the Calford mainframe glow red, the Northline-era capabilities are green, and the duplicated capabilities, the ones delivered two or three times over, are flagged as waste. Now "where is the bank weak" has a visual, defensible answer, tied to the fundamental things the bank does rather than to whichever team happens to own them today.
This is why the capability map is often called the most useful single artifact in enterprise architecture. It is the stable canvas that every other analysis can be projected onto. Investment decisions, risk assessments, and, as the next posts will show, application-portfolio rationalization and governance priorities all become far clearer when painted onto capabilities rather than onto the ever-shifting org chart.
Where you will encounter it
Capability maps show up wherever leadership needs to reason about a whole organization at once rather than one project at a time. A merger is the classic trigger: when two banks combine, overlaying one capability map on the other shows instantly where the duplication is and which version of each capability to keep. That is the analysis Aldermont should have done, and largely did not, across its three acquisitions, which is why it now runs so much three times over.
They also anchor strategic planning ("which capabilities must we strengthen to enter this market"), investment prioritization ("we have finite budget; which capabilities earn it"), and technology roadmaps ("these red capabilities need modernization first"). In each case the map's job is the same: provide the one stable, complete picture of the business that a decision can be made against.
Summary
A capability map is a single-page picture of everything an organization is able to do, organized from broad to granular, expressed entirely in terms of what rather than who, when, or with what. Its value rests on a discipline that is easy to state and easy to violate: a capability is not a team, so a capability map is not an org chart; and a capability is not a step, so a capability map is not a process map. Get that separation wrong, most commonly by copying the org chart, and the map inherits the very duplication it was meant to expose.
Kept clean, the map becomes the most useful canvas in enterprise architecture. Because it is stable while org charts and systems churn, it is the ideal surface to heat-map, coloring each capability by technology health, cost, risk, or strategic value until the whole organization's condition sits on one page. That is how Aldermont finally answered "where are we weak": not with a team name or a project status, but with a red-flagged capability delivered three times over, pointing straight at where the consolidation money should go. The map does not make the decision. It makes the decision visible. The next post takes the messiest of those red capabilities and works the problem in detail: rationalizing the tangle of overlapping applications underneath them, treating the whole estate as a portfolio to be managed rather than a pile to be endured.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.