Business capabilities

50 min 6 outcomes 0 interactive diagrams 5 standards cited

Business capabilities are stable enterprise abilities that survive system replacements, organisational restructures, and process redesigns. The G211 Business Capabilities v2 guide sets out how to define them and how to heat-map them in Phase B, and structured assessment is what turns a capability map from a wall chart into an instrument for investment decisions.

By the end of this module you will be able to:

  • Define a business capability accurately using the G211 definition and spot common mislabelling
  • Explain how G211 suggests assessing capabilities through heat mapping, and apply this course's wider seven-dimension lens
  • Distinguish capabilities from processes, systems, teams, and projects
  • Apply the four negative tests to check whether something is genuinely a capability
  • Build a first-pass capability map for London Grid distribution operations
  • Use capability assessment to ground investment decisions in evidence rather than instinct

A ‘capability map’ that was really an application inventory.

In 2021, a water utility's architecture team proudly presented what they called a "business capability map" to the transformation board. The board reviewed it for ten minutes and then one non-executive director pointed to the top-level boxes: "SAP Finance," "GIS Platform," "CRM System," "Workforce Management Tool."

She asked, "Are these the things the enterprise must be able to do, or are these the things the enterprise happens to own today?" The architecture lead hesitated. The answer was obvious. The map was an application inventory wearing language.

That mistake is one of the most common in , and it is one of the most damaging. When capability maps collapse into system inventories, the architecture loses its ability to discuss strategic improvement independently of current technology.

If every entry on the capability map is a software product name, is the enterprise discussing what it needs to become better at, or what it currently owns?

That story illustrates the most important guardrail in capability work: never mistake a system boundary for a capability boundary. What follows is the G211 definition of a capability, how capability assessment works in practice, and how to avoid the traps that make capability maps useless.

19.1 What a capability is: the G211 definition

G211 Business Capabilities, Version 2, is the primary TOGAF Series Guide for capability thinking. It defines a capability as an ability the enterprise needs to possess and improve over time. Capabilities are named independently of the systems, teams, or processes that currently deliver them.

That independence is the entire point. A capability describes what the enterprise must be able to do, not how it currently does it. The "how" changes with every system replacement, organisational restructure, and process redesign. The "what" remains stable across those changes.

It helps to keep capability definition and capability assessment apart. Defining a capability means naming it, placing it in the hierarchy, and describing its purpose. Assessing a capability means judging how well the enterprise performs it today and the gap between where it is and where it needs to be. Both activities sit in , but they serve different purposes.

19.2 How to tell when something is not a capability

The fastest way to check capability quality is to apply four negative tests. G211 implies these tests through its guidance on capability naming and hierarchy, and they are useful as a practical quality gate.

  • The system test. If it sounds like a software product, it is probably not a capability. "SAP Finance" is a system. "Financial management" is closer to a capability. A capability should survive a system replacement.
  • The department test. If it sounds like a department, it is probably not a capability. "IT Operations" is a team. "Technology service delivery" is closer to a capability. A capability should survive an organisational restructure.
  • The task test. If it names one narrow workflow step, it is probably too low-level. "Send email notification" is a task. "Customer communication management" is closer to a capability. A capability should be broad enough to matter strategically.
  • The replacement test. If it cannot be imagined surviving a system replacement, it is probably not a capability. "Salesforce pipeline tracking" is tool-specific. "Sales opportunity management" is a capability. This is the strongest test.

Common misconception

“Capability names should match the current application portfolio for traceability.”

Naming capabilities after systems defeats the purpose. Capabilities should describe enterprise abilities independently of which system delivers them. The traceability comes from mapping capabilities to systems, not from merging their names. G211 is explicit about this: capability names must be technology-neutral.

19.3 Assessing capabilities: G211 heat mapping and a wider lens

G211's own assessment mechanism is deliberately light. It suggests heat mapping capabilities during Phase B, colouring each one from four suggested perspectives: maturity, effectiveness, performance, and the value or cost contribution of the capability to the business. It also describes what a capability is realised through: people, processes, information, and resources. Weakness in any of those components is weakness in the capability.

A four-perspective heat map is a good start, but on real programmes the harder question is why a capability scores poorly, because the answer decides what kind of intervention to fund. This course therefore uses a wider assessment lens with seven dimensions, built on the G211 components rather than prescribed by the guide itself. Each dimension captures a different aspect of capability strength.

Strategic importance

How critical is this capability to the enterprise's current strategic priorities? A capability that directly supports a regulatory obligation under active scrutiny is more strategically important than one that supports an internal convenience. Assess strategic importance against the enterprise goals and drivers identified in the .

Current maturity

How well does the enterprise currently perform this capability? Maturity is also one of the four G211 heat-mapping perspectives. Assess it against observable evidence: service metrics, incident records, audit findings, feedback, and results. Gut feeling is not evidence. If the maturity assessment is based on opinion rather than data, the resulting heatmap colours are decoration.

People and skills

Does the enterprise have the right people with the right skills to deliver this capability at the required level? A capability may have the right systems but lack the skilled people to use them effectively. People are one of the four components G211 says a capability is realised through, so capability strength is never purely a technology question.

Process maturity

Are the processes that support this capability defined, repeatable, measured, and improved? A capability supported by ad-hoc processes is fragile even if the underlying systems are modern. Processes are another of the G211 components, so an immature process is a capability weakness in its own right, not a separate concern.

Information and data quality

Does the capability have access to the information it needs, at the quality it needs? Many capability weaknesses trace to information problems rather than system problems. A capability that depends on inaccurate or incomplete data will underperform regardless of how modern its supporting technology is.

Technology support

How well do current systems, platforms, and tools support the capability? This dimension covers system fitness, integration quality, , and technology currency. It is one dimension among several, not the only one that matters.

Governance and accountability

Is there clear ownership, decision authority, and for this capability? A capability with no clear owner will drift. A capability with contested ownership will consume governance time without producing improvement.

Which capabilities carry the most severe gaps and rank first to fix

Scoring each capability against process, data, application and skills turns a maturity assessment into an order of work: the row with the most severe gaps ranks first, and reading down a column names the dimension that fails most often and so earns investment before the rest.

Which capabilities carry the most severe gaps and rank first to fix A capability gap heatmap drawn as a matrix. Rows list capabilities (Connections, Network control, Network planning, Outage response, Reliability reporting, Billing and metering) on a left rail, under a calm blue header band. Columns are the four gap dimensions: Process, Data, Application and Skills. Each cell is graded against a three-state legend: a green cell for a small gap, a soft amber cell for a moderate gap, a solid amber cell for a severe gap, with a marker that grows as the gap widens. A right-hand priority column counts each row's severe gaps so the worst rank first, and the capability with the most severe gaps carries the blue accent as the row to fix first. Capability Process Data Application Skills Priority Connections Moderate Severe Severe Moderate 2 severe across four dimensions Network control Small Severe Moderate Small 1 severe across four dimensions Network planning Moderate Severe Severe Moderate 2 severe across four dimensions Outage response Small Moderate Small Moderate No severe gaps across four dimensions Reliability reporting Moderate Severe Moderate Small 1 severe across four dimensions Billing and metering Moderate Moderate Severe Moderate 1 severe across four dimensions Small gapModerate gapSevere gap (solid fill)

Twelve capabilities scored for maturity and investment pressure across four families

A capability at Initial or Repeatable maturity with high investment pressure is a candidate for immediate architecture intervention in Phase E, so the amber cells mark exactly where the money and the roadmap effort should go first.

Twelve capabilities scored for maturity and investment pressure across four families A flat maturity grid for twelve London Grid Distribution capabilities grouped into four families: Core Operations, Customer Services, Governance and Enablers. Each row shows the capability, its maturity on a five-point scale from Initial through Repeatable, Defined and Managed to Optimised, the investment pressure and the owning team. Maturity and pressure cells are tinted as a three-band state: amber where maturity is Initial or Repeatable or pressure is high, neutral for the Defined middle, green for Managed or Optimised. Innovation sits at Initial; Network and Fault Operations at Managed. A legend names the states. Low maturity with high pressure marks a Phase E intervention candidate. FamilyCapabilityMaturityInvestmentpressureOwner CoreOperations CustomerServices Governance Enablers Asset Management3 DefinedHighEngineering Network Operations4 ManagedMediumControl Centre Fault Response4 ManagedLowField Operations Customer Connections2 RepeatableHighCustomer Team Smart Metering2 RepeatableHighMetering Lead Complaints Handling3 DefinedMediumCustomer Team Regulatory Reporting3 DefinedHighRegulatory Affairs Data Management2 RepeatableHighData Office Cyber Security3 DefinedHighCISO Workforce Management2 RepeatableMediumHR and Operations Network Planning3 DefinedMediumPlanning Team Innovation and R and D1 InitialMediumStrategy Weak: Initial or Repeatable, invest nowMid: DefinedStrong: Managed or Optimised

19.4 Why capabilities help enterprise architecture

Capability thinking serves three distinct functions in architecture work, and each one matters for different reasons.

Stable enterprise language.Capabilities let the business and architecture talk about what must improve without tying the discussion to today's tooling. When the board asks "what do we need to become better at?" the answer should be in capability language, not in system names.

Planning value. Capabilities can be assessed, prioritised, and linked to choices more easily than loosely defined ambitions. Structured capability assessment grounds investment decisions in evidence rather than in opinion about which system feels oldest.

Cross-domain relevance. Later data, , and technology decisions can all be tested against the capabilities they are supposed to support. That traceability is what makes capability maps earn their place across the full cycle.

The capability priority quadrant of value against change difficulty

Plotting each capability by business value against change difficulty turns a crowded backlog into four decisions: harvest the easy wins, fund the hard high-value work as a board-owned programme, defer low-value easy work, and question low-value hard work before it drains effort.

The capability priority quadrant of value against change difficulty A two-by-two priority quadrant on two blue rails: business value rises low to high up the left, change difficulty advances low to high along the bottom. Each quadrant names the decision one combination forces, with a green action marker, an amber risk marker, and the owner top-right. High value, low difficulty is Harvest, the quick wins: push delivery to free cash, though wins fade if left to drift. High value, high difficulty is Invest, tinted as the board-owned strategic programme to fund despite cost and risk. Low value, low difficulty is Defer, left on background run-rate. Low value, high difficulty is Question, to challenge, retire or insource before it sinks effort for little return. Business value: low to high Change difficulty: low to high High value, low difficulty Harvest Quick wins Push delivery to free cash fast Wins fade if left to drift High value, high difficulty Invest Board owned Fund as the strategic programme Heavy cost and delivery risk Low value, low difficulty Defer Maintain Leave on background run-rate Not worth scarce attention Low value, high difficulty Question Sunset Challenge, retire or insource Sinks effort for little return The action to takeThe risk it carries

19.5 The most important guardrail

Never mistake a system boundary for a capability boundary. If a capability map is really an application inventory, the architecture has already drifted off course.

This guardrail matters because the drift from capability to system is subtle. Architecture teams under delivery pressure naturally gravitate toward familiar system names because those names feel concrete. But concreteness is not the same as usefulness. A capability named "SAP Finance" feels concrete but tells the enterprise nothing about what it needs to become better at. A capability named "Financial transaction management" is less concrete but far more useful because it can survive a system replacement.

The discipline is to keep asking: would this capability name still make sense if we replaced every system in the enterprise tomorrow? If the answer is no, the name needs to change.

London Grid Distribution: capability map for distribution operations

The London capability view is built around enterprise abilities, not product names. Applying the naming discipline from G211, the first-pass capability map for London Grid distribution operations includes the following capabilities, grouped by domain.

Customer and connections domain

  • Customer connections management. The ability to process connection requests from application through to energisation, meeting regulatory timescales.
  • Customer communication management. The ability to keep customers informed of progress, changes, and decisions throughout the connections journey.
  • Connection offer generation. The ability to produce accurate, costed connection offers based on current network capacity and reinforcement needs.

Network planning and operations domain

  • Network planning visibility. The ability to maintain an accurate, accessible view of network capacity, demand forecasts, and planned interventions.
  • Connection design coordination. The ability to produce technically sound connection designs that account for network constraints and future demand.
  • Operational resilience governance. The ability to maintain network reliability, respond to faults, and manage the physical infrastructure safely.
  • management. The ability to procure and coordinate flexible response to manage local network constraints.

Information and governance domain

  • Information publication. The ability to produce and publish accurate network data for regulatory, planning, and public purposes, including the .
  • Evidence-backed decision-making. The ability to support governance and operational decisions with traceable, quality-assured evidence rather than opinion.
  • Data quality management. The ability to ensure that network models, asset records, and planning data meet defined accuracy and completeness standards.
  • Controlled decision-making. The ability to route decisions through defined governance paths with clear authority, audit trail, and accountability.

Applying the seven-dimension lens to these capabilities reveals that the London case has particular weaknesses in information and data quality (fragmented across systems), governance and accountability (contested ownership at handoff points), and process maturity (ad-hoc handoff procedures). Technology support is a contributing factor but not the primary weakness in most cases. That insight is what makes the multi-dimensional assessment valuable: it prevents the default assumption that every capability gap requires a system replacement.

Check your understanding (part 1)

An architecture team’s capability map includes an entry called ‘Oracle EBS Financial Processing.’ A stakeholder challenges this as a system name, not a capability. The architecture lead argues it is a capability because it describes what the finance team does. Who is correct?

G211 Business Capabilities v2 suggests heat mapping capabilities in Phase B from four perspectives. Which of the following is NOT one of the four?

Check your understanding (part 2)

A capability assessment shows that ‘information publication’ scores well on technology support (modern systems) but poorly on data quality and governance. What does this pattern suggest?

Core distinctions

  • G211 defines a capability as an ability the enterprise needs to possess and improve, named independently of systems, teams, or processes.
  • G211 suggests heat mapping capabilities by maturity, effectiveness, performance, and value or cost contribution; this course widens that into seven dimensions spanning strategy, people, process, information, technology, and governance.
  • Multi-dimensional assessment prevents the default assumption that every capability gap requires a system replacement.
  • Capability language is useful because it survives solution churn and current org-chart accidents.
  • A good capability map helps the enterprise talk about what must improve. A bad one collapses back into application inventory or department naming.
  • The London Grid capability map spans customer connections, network planning, information publication, and governance domains, with particular weaknesses in data quality and accountability.

Standards and sources cited in this module

  1. G211, Business Capabilities, Version 2

    Full guide

    The primary TOGAF Series Guide for business capabilities, covering capability definition, mapping, and heat mapping in Phase B.

  2. G233, Business Capability Planning

    Full guide

    Planning guidance built on capability thinking, covered in the next module.

  3. The TOGAF Standard, 10th Edition (C220)

    Architecture Development Method, Phase B: Business Architecture

    Core standard context for capability identification within Phase B.

  4. G178, Value Streams

    Full guide

    Value-stream guidance that complements capability maps by showing flow alongside ability.

  5. G203, Architecture Maturity Models

    Full guide

    Maturity-model guidance that helps put evidence behind the maturity grades used in capability assessment.

Back: Organisation mappingNext: Capability-based planning

Module 19 of 72 · Business Architecture

Try it in the workspace

2 tools reinforce this module.

Capability Heatmap Builder

Score each business capability across four gap dimensions (process, data, application, skills) so the gap between today's organisation and the one the strategy requires is visible on one heatmap.

TOGAFDeep · 45 minutes
Open tool

Competence Map

Map the competences an enterprise must excel at to the capabilities they shape, and set the measure each capability has to meet.

Open Business ArchitectureDeep · 30 to 45 minutes
Open tool