The capability map was beautiful.
It filled an entire wall. Hundreds of carefully named boxes were arranged into strategic, customer-facing and supporting areas. Colors were consistent. Definitions had been debated. Senior architects had spent months refining the taxonomy.
Six months later, almost nobody was using it.
This is one of the quiet tragedies of enterprise architecture. We can become so absorbed in building a correct model that we forget why the organization needed one. A business capability model is not valuable because it describes the enterprise elegantly. It is valuable because it helps the enterprise make better decisions.
The point is not to finish the model. The point is to use it.
What is a business capability model—and why do we need one?
A business capability describes something the enterprise must be able to do. It describes the “what,” independently of the organization structure, processes, technologies or people currently used to do it.
Customer Management is a capability. A customer-relations department is an organization. Handling a customer complaint is a process. A CRM platform is a technology. Those things may realize or support the capability, but they are not the capability itself.
The Business Architecture Guild’s Business Architecture Metamodel Guide describes capabilities as fundamental building blocks of the business. The Guild’s approach also emphasizes information concepts: a capability such as Customer Management remains focused on the customer even as it is decomposed into more detailed capabilities.
The Open Group’s TOGAF Series Guides include specific guidance on business capabilities and capability-based planning. The Open Group also connects capability perspectives with strategy, portfolio planning and investment decisions in its role-based guidance for business architecture.
Gartner describes business capabilities as a way to connect strategy with execution. Its business capability model toolkit focuses on using a model to create prioritization heatmaps and inform investment decisions.
Whynde Kuehn develops the larger strategy-execution context in Strategy to Reality and, with Brian Cameron, in The Execution Challenge. These works position business architecture as a reusable foundation for translating strategic intent into coordinated change.
Mike Walker makes the point particularly well in his article, “Business Capability Modeling Is the Missing Link Between Strategy and Execution”:
“Once established, a Business Capability Model becomes a decision platform.”
That is the standard we should apply. If the model does not help someone make a decision, it is not yet earning its keep.
Capability model, capability map and capability heatmap
These terms are frequently used interchangeably, but the distinctions are useful.
A business capability model is the underlying structured body of information. It contains capabilities, definitions, decomposition relationships and potentially other attributes or relationships. It may connect capabilities to strategies, value streams, business units, processes, information, applications, investments and performance measures.
A capability map is a visual representation of some portion of that model. It arranges capabilities so people can understand their scope and relationships. One model can produce several maps: an enterprise map, a map for one business area, or a simplified view prepared for a particular stakeholder.
A capability heatmap is a capability map with an analytical concern overlaid on it. Color might represent maturity, strategic importance, investment, risk, cost, performance or the gap between current and required ability.
The model is the underlying knowledge. The map is a view. The heatmap is an analysis presented through that view.
This distinction matters because an organization should not need a different underlying capability model every time a stakeholder asks a different question. Preserve a reasonably stable model and produce views suited to the decision at hand.
Start with a reference model—but do not surrender to it
You do not always need to begin with a blank page.
Industry organizations have invested considerable effort in developing reference models. For banking, BIAN’s Business Capability Model is intended as a reference from which a bank can derive its organization-specific model. BIAN also distinguishes its business capability model from its more technology-oriented Service Landscape.
For telecommunications and digital-service businesses, the TM Forum Business Architecture Capability Reference Map provides capabilities and definitions extending through several levels of detail.
The Business Architecture Guild offers industry reference material to its members, and software providers such as SAP LeanIX and Ardoq publish models, examples and templates.
These resources can save weeks of sterile debate. But a reference model is a starting hypothesis, not a finished description of your enterprise.
Begin by selecting a model appropriate to your industry—or a general model when an industry-specific one is unavailable. Then change it deliberately:
- Adopt the vocabulary your business uses.
- Remove capabilities your organization does not need.
- Add differentiating capabilities that the reference model lacks.
- Resolve boundaries that do not match your operating reality.
- Stop decomposing when you have enough detail to perform the intended analysis.
The Business Architecture Guild makes this point in Business Architecture: Setting the Record Straight: a capability map derived solely from an industry reference model rarely represents the unique perspectives of a particular business.
Your model should be recognizable to the people running the enterprise. If business leaders need an architect beside them to translate every box, it is not yet their model.
Apply a few quality checks
A capability model does not have to be perfect. It does need to be coherent enough to support analysis.
I use several practical checks.
Aim for MECE. Capabilities under the same parent should be as mutually exclusive and collectively exhaustive as business reality allows. Persistent overlap usually means that definitions or boundaries are unclear. Obvious omissions mean the parent is not fully represented.
Keep it non-technical. Technology may support a capability, but it should not define it. “Customer Information Management” can survive a technology replacement. “Salesforce Management” cannot.
Use the language of the business. Prefer the words stakeholders use—provided those words have reasonably consistent meanings. An academically elegant label that nobody recognizes will not create shared understanding.
Maintain the information focus. Decomposition should preserve the business object or information concept at the center of the parent capability. Customer Management should decompose into capabilities concerned with customers, not into a mixture of departments, processes and applications.
Limit depth and volume. Model only as deeply as the analysis requires. Enterprise investment planning may need levels one and two, with selective use of level three. A program examining a specific area may go deeper. A model containing hundreds of equally detailed capabilities is expensive to maintain and difficult to explain.
Write definitions with clear boundaries. A definition should make it possible to understand what belongs in the capability and what does not. If two capability owners can plausibly claim the same scope, tighten the definitions before collecting data.
These checks are not an invitation to spend another six months polishing the taxonomy. They are enough to make the model trustworthy for its intended use.
Collect planning data selectively
The most expensive mistake is attempting to populate every possible attribute for every capability.
An architect creates the model, sends a spreadsheet or survey to dozens of people and asks for maturity, ownership, cost, applications, processes, information, risk, pain points and planned investments. Participation declines. Answers become inconsistent. The model is obsolete before it is complete.
Reverse the sequence.
Start with the strategies to which leadership has actually committed. Map those strategies to the capabilities required to execute them.
Next, review the strategically relevant capabilities with knowledgeable stakeholders. Ask which of them are likely to require attention. This is a triage step. It narrows the investigation before the organization invests heavily in data collection.
Only then gather deeper information for that selected set of capabilities:
- Current and required maturity
- Relevant processes
- Responsible people or teams
- Supporting tools and applications
- Important information and data
- Current or planned investments
- Known risks, constraints and dependencies
Maturity can be assessed across dimensions such as people, process, tools and information. Different organizations will use different scales, but the essential comparison is consistent: how capable are we now, and how capable must we become to execute the strategy?
This focused approach respects everyone’s time. It also makes the resulting analysis more credible because stakeholders are assessing capabilities connected to an actual business concern—not filling in an architecture repository for its own sake.
Pull the meaningful gaps aside
Once current and required maturity have been assessed, identify the capabilities with consequential gaps.
Do not bury them inside a map containing hundreds of neutral boxes. Create a view containing the capabilities that matter to the selected strategy. Show their present condition, required condition and the dimensions contributing to the gap.
A capability may have adequate tools but weak processes. Another may have skilled people but fragmented information. A third may be constrained by unclear ownership. Those are materially different problems even if their overall maturity scores look similar.
Pulling the gaps aside creates a manageable planning surface. Leaders can see where the enterprise lacks the ability needed to execute its strategy—and what kind of change each gap requires.
Turn the gaps into programs
A capability gap is not yet a program.
Look across the selected gaps for common outcomes, dependencies, affected stakeholders and shared change mechanisms. Several capability gaps may belong in one coherent program. One large gap may need to be divided among several programs.
Name programs for the business outcomes they are intended to create, not for the technology somebody expects to purchase. Give each proposed program:
- A clear business objective
- The capability gaps it will address
- The maturity dimensions expected to improve
- A credible business champion
- Measurable outcomes
- Known dependencies
- Enough scope and cost information to enter the planning process
Review the proposed programs with the leaders who depend on those capabilities. Their role is not merely to approve a diagram. They must be willing to champion the change when it competes for funding.
Then submit the programs into the organization’s planning cycle.
This reverses the usual bottom-up process. Instead of beginning with 137 project requests and asking which five sound most strategic, begin with strategy, identify the capabilities that matter, find the gaps and construct programs that address them. I described that wider argument in “Stop Ranking Projects: Why Portfolio Planning Should Start Top Down.”
This is also the workflow I designed the Useful EA Capability Modeler to support: importing and adapting a model, connecting strategies, collecting focused maturity data, exposing gaps and organizing those gaps into proposed programs. The tool is useful only to the extent that it makes the planning conversation easier.
The model is not the outcome
A capability model is never really finished. It becomes good enough to support a decision, and then it improves as the organization uses it.
That is a healthier standard than completeness.
Start with a credible reference model. Adapt it to your enterprise. Apply enough quality control to make the boundaries trustworthy. Use strategy to narrow the field. Collect detailed information only where it matters. Pull the important gaps into view. Turn them into coherent programs with business champions.
Then put those programs into the planning cycle.
The success of a business capability model is not measured by the number of capabilities documented, the sophistication of the repository or the beauty of the heatmap.
It is measured by whether the enterprise invests differently because the model made the need for change clear.