The Open Group OGEA-103: Capability-Based Planning with TOGAF

Capability-based planning asks what the enterprise must be able to do before deciding which organizational unit, process, application, or technology will provide that ability. This creates a stable planning layer because capabilities change more slowly than projects and products. A business may replace an application while the underlying need—such as onboarding customers, managing risk, fulfilling orders, or analyzing data—remains.

Within enterprise architecture, capability models connect strategy with architecture and investment. The TOGAF library includes business-capability guidance because capability views help architects reason across business, information, application, and technology domains without starting from the current system landscape.

The value does not come from drawing a large capability map. It comes from using the map to identify which abilities matter, how well they are supported, where dependencies exist, and where investment can improve strategic outcomes.

Define capabilities independently of the organization chart

A capability describes an ability, not the team currently responsible for it. This matters because organizational structures change and several units may contribute to the same capability. If the model mirrors the org chart exactly, it becomes difficult to compare shared needs or evaluate alternative operating models.

Use decomposition only when it improves a decision

Capability models can become extremely detailed. Decompose a capability when the sub-capabilities have different maturity, owners, investments, risks, or strategic importance. Stop when additional levels no longer change a decision.

Assess capabilities with more than a maturity score

A single red-amber-green score can hide the reason a capability is weak. Assessment can examine process, people, information, technology, governance, performance, cost, risk, and strategic importance. Two capabilities with the same maturity may need very different investments.

Connect capabilities to value and strategy

Capabilities are useful for prioritization when they can be traced to strategic objectives, customer value, regulatory obligations, or operating outcomes. This avoids architecture investment that is justified only by technical age or platform preference.

Map enabling architecture to the capability

Once a priority capability is understood, architects can identify the information, applications, integrations, technology, security, and organizational roles that enable it. This creates traceability from strategic need to architecture work.