Business Capabilities

Definition

A capability is an ability the organisation has: "accept payment", "fulfil an order", "onboard a customer", "assess credit risk". It is a noun phrase describing what, never how, who or with what.

Why architects care

Capabilities are the most stable thing in an organisation. Processes change, teams reorganise, systems are replaced, but a retailer has been "managing inventory" for a century and will continue to.

That stability makes capabilities the best available frame for boundaries. A system organised around "accept payment" survives the reorganisation, the vendor change and the process redesign. A system organised around the current org chart or the current process does not.

This is why capability-aligned service boundaries outlast every other kind, and why "which capability does this belong to?" is a more useful question in a design review than "which team owns this?"

What makes a capability statement good

• Verb plus noun, describing an ability: "settle payments", not "the payments team" and not "the payments platform".
• Technology-free. If a system name appears, it is not a capability.
• At a consistent level. Mixing "manage the enterprise" with "validate a postcode" makes the map useless.
• Non-overlapping. Two capabilities that both claim to own pricing is a finding, not a detail.

What it is not

Not a process — a process is a sequence of steps; a capability is an ability that may be exercised by many processes. Not a team, though teams are ideally aligned to them. Not a system, though systems implement them.

Conflating capability with system is the most common error, and it produces a "capability map" that is an application inventory with different labels.

Where it earns its keep

• Drawing service boundaries that survive change.
• Assessing duplication — three systems implementing "calculate tax" is visible on a capability map and invisible on a system diagram.
• Prioritising investment — which capabilities are differentiating, which are necessary, which are commodity. That distinction drives build-versus-buy more reliably than any technical criterion.
• Aligning teams, so that Conway's Law works for you rather than against you.

Failure scenarios

• A capability map that is an application inventory, with system names in the boxes.
• Levels mixed, so the map cannot be reasoned about.
• Produced once as a consulting artefact and never used, which is the usual fate.
• Capabilities named after teams, so a reorganisation invalidates the map.

Interview question

"What is the difference between a business capability and a business process, and why does it matter when drawing service boundaries?"