Skip to content
Software Architecture Guide

Capability versus process

Explanation

Section titled “Explanation”

People often mix up capabilities and processes. They answer different questions.

Capability: what the organization can do. A business capability defines what a business needs to be able to do to reach an outcome that supports its mission. It describes a core ability the organization needs to run its business. It is abstract and conceptual. It does not say how the work is done.

Process: how the work is done. A business process is a linked series of activities that turns inputs into outputs. It describes the tasks, their sequence, and the systems used to carry them out. That adds operational detail that a capability leaves out.

Naming helps keep them apart. Processes use a verb-noun form, such as Receive Order or Ship Product. Capabilities use nouns or gerunds (the “-ing” form of a verb), not plain verbs.

Stability differs. Capabilities should stay stable over time unless the business model itself changes. Processes can change even when the business model stays the same, for example as the business evolves.

How they connect. Value streams show how capabilities are used to create value. Processes give the operational detail. If you map capabilities to the stages of a value stream, you see which capabilities each stage needs. See Business Capability Map and Operational Value Stream for more.

A common mistake. Teams nest capability maps and process maps inside one another. Keep them as separate maps and link them through relationships.

Example

Section titled “Example”

A retailer has a capability named Order Fulfillment. It states that the company must be able to get ordered goods to customers. It says nothing about steps.

Processes sit alongside it in a separate process map. They are named Receive Order and Ship Product. They list the tasks, their sequence, and the systems used. If the retailer changes how it ships, the Ship Product process changes. The capability stays the same, and the link between the two maps shows which processes support it.

Trade-offs

Section titled “Trade-offs”

Keeping two separate maps means more modeling work, because you must maintain the links between them. The benefit is that the stable capability view is not disturbed when processes change. Nesting the maps looks simpler, but it is a common mistake.

A capability is linked to value stream stages and processes, but kept in a separate map.

Diagram source 
flowchart TD
  C[Capability: Order Fulfillment<br/>what the business can do]
  V[Value stream stage<br/>needs the capability]
  P1[Process: Receive Order<br/>how the work is done]
  P2[Process: Ship Product<br/>how the work is done]
  C --- V
  V --- P1
  V --- P2

Checks

Section titled “Checks”
  • Capabilities are named with nouns or gerunds, and processes use verb-noun names such as Receive Order.
  • The capability map and the process map are separate and linked by relationships, not nested in each other.
  • Capability descriptions state what the business must be able to do and do not describe tasks, sequence, or systems.
  • Capabilities are mapped to value stream stages to show which capabilities each stage needs.
Section titled “Related”

Sources

Section titled “Sources”