# Capability identification and naming

**In short:** A business capability says what a business does, not how it does it. Identify capabilities that stay stable over time, and name them with nouns or gerunds, not verbs.

## 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

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

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

- 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.

## Related

- [Business Capability](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability.md)
- [Business Capability Map](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability-map.md)
- [Capability versus process](https://arc.fuet.ch/concepts/enterprise-architecture/capability-versus-process.md)
- [Capability Heat Map](https://arc.fuet.ch/concepts/enterprise-architecture/capability-heat-map.md)
- [Capability Map Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/capability-map-development-method.md)
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md)
- [Business Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/business-architecture.md)

## Sources

- [Business Capabilities | Albumi Docs](https://albumi-docs.pages.dev/concepts/business-capabilities/) — albumi-docs.pages.dev, accessed 2026-11-09
- [Developing your Capability Architecture: It's All about Being Able to Get Things Done (Commentary)](https://www.brcommunity.com/articles.php?id=b927) — brcommunity.com, accessed 2026-11-09
- [Microservices Architecture Style - Azure Architecture Center | Microsoft Learn](https://learn.microsoft.com/en-us/Azure/architecture/guide/architecture-styles/microservices) — learn.microsoft.com, accessed 2026-11-09