Skip to content
Software Architecture Guide

Capability identification and naming

Explanation

Section titled “Explanation”

A business capability is an ability or capacity that a business may have or exchange to reach a specific purpose or outcome. It is a stable statement of what the business does. It says nothing about how the work is delivered. See the article Business Capability for the full concept.

Stable over time. Capabilities should outlast the current organizational chart and its reorganizations. A capability map should only change when the business model itself changes. This makes a capability a better anchor than a team name.

What versus how. A capability is the what. A process is the how. The two do not nest inside each other. Processes and capabilities relate many-to-many. See Capability versus process.

Naming. Capability names use nouns or gerunds (a verb ending in “-ing”, used as a noun). Processes and value streams use verb-noun phrases instead. A name that starts with a verb therefore signals a process, not a capability.

Levels. Useful capability maps break capabilities into a hierarchy of about two to four levels. See Business Capability Map.

Prioritizing. A heat map uses strategic importance ratings to rank where portfolio attention goes first. See Capability Heat Map.

Service boundaries. Each microservice should implement a single business capability within a bounded context. A bounded context is a natural division within the business. It gives an explicit boundary for a domain model. Capabilities can therefore help you draw service boundaries. See Bounded Context.

Example

Section titled “Example”

An insurance company lists “Claims Handling” as a capability. The process “Handle a claim” describes the steps. The capability stays on the map even if the claims department is renamed or split. A name like “Process Claims” would read as a process, so it does not belong on the capability map.

Trade-offs

Section titled “Trade-offs”

Stability is the main benefit: a capability map survives reorganizations. The cost is abstraction. A capability does not show steps, order or owners of work, so you still need process models for the how. Too many levels also make a map hard to use, which is why about two to four levels is the useful range.

Checks

Section titled “Checks”
  • Capability names use nouns or gerunds, not verb-first phrases.
  • Capabilities describe what the business does, and process steps are kept in separate process models.
  • The capability map has about two to four levels.
  • Capabilities and processes are linked many-to-many, not nested.
  • Each service maps to a single business capability within a bounded context.
Section titled “Related”

Sources

Section titled “Sources”