Business capabilities

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.

G211 also distinguishes between capability definition and capability assessment. Defining a capability means naming it, placing it in the hierarchy, and describing its purpose. Assessing a capability means judging its current maturity, its strategic importance, and the gap between where it is and where it needs to be. Both activities are part of Phase B, but they serve different purposes.

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.

G211 provides a structured capability assessment framework that goes beyond simple red-amber-green heatmaps. The framework assesses each capability across multiple maturity dimensions, producing a richer picture that supports investment prioritisation and planning.

The assessment framework works by evaluating each capability against defined maturity dimensions. Each dimension captures a different aspect of capability strength. The full set of dimensions from G211 includes the following.

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. G211 recommends assessing strategic importance against the enterprise goals and drivers identified in the Architecture Vision.

Current maturity

How well does the enterprise currently perform this capability? G211 recommends assessing maturity against observable evidence: service metrics, incident records, audit findings, stakeholder feedback, and compliance 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. G211 recognises that capability maturity is not 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. G211 treats process maturity as a dimension of capability strength, not as 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, interoperability, 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 governance for this capability? A capability with no clear owner will drift. A capability with contested ownership will consume governance time without producing improvement. This dimension connects directly to the organisation mapping work from Module 18.

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 roadmap choices more easily than loosely defined ambitions. The G211 assessment framework grounds investment decisions in evidence rather than in opinion about which system feels oldest.

Cross-domain relevance. Later data, application, 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 ADM cycle.

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.

The London capability view is built around enterprise abilities, not product names. Using the G211 framework, 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.
• Flexibility management. The ability to procure and coordinate flexible DER 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 LTDS.
• 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 G211 assessment dimensions 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.