Skip to content
Software Architecture Guide

Capability Map Development Method

Explanation

Section titled “Explanation”

A business capability map lists what a business must be able to do. The articles Business Capability Map and Business Capability cover the basics. This article covers the order of work and the design rules.

1. Set the purpose first. A map should support strategic decisions, not just serve as documentation. Decide which decisions it will inform before you draw anything.

2. Describe what, not how. A capability states what the business must be able to do. It does not name the activities, workflows or systems used to do it. The article Capability versus process explains the difference.

3. Keep the top level small. Aim for roughly seven to ten capabilities at the highest level.

4. Limit the depth. Two or three levels are usually enough for analysis and planning.

5. Make capabilities mutually exclusive. Capabilities must not overlap, so every business function has exactly one home. A review for overlaps, often called a MECE review (mutually exclusive, collectively exhaustive), helps resolve disputes. The set should also cover the whole business and be broken down hierarchically.

6. Keep it stable. The map should hold for years, even while processes, systems and organization structures change. So the org chart should not drive its design.

7. Assign business owners. Each capability needs a named business owner. That person is responsible for its definition and scope.

8. Agree on names and definitions. The map works only if the whole organization uses the same naming, definitions and structure. See Capability identification and naming.

9. Put the map to work. Link capabilities to applications. Use the links for heat maps, rationalization and roadmaps. A heat map shows which capabilities need attention, based on gaps in effectiveness, efficiency and performance.

Example

Section titled “Example”

A retailer sets the purpose: decide where to invest next year. It defines eight top-level capabilities, such as “Product Sourcing” and “Customer Service”. It splits each into a second level only. Each capability gets one business owner. When the retailer reorganizes its departments, the map stays the same. The team then links each capability to the applications that support it and colors a heat map to show where attention is needed.

Trade-offs

Section titled “Trade-offs”

Keeping the map shallow and stable makes it easy to share and reuse. But it leaves out detail about how work happens, so you need other models, such as process models, for that. Strict non-overlap also takes review effort, and owners must agree on where each function belongs.

Checks

Section titled “Checks”
  • The document states the purpose of the capability map and ties it to strategic decisions.
  • Capabilities describe what the business does, not processes, workflows or systems.
  • No two capabilities overlap; each business function has one home.
  • The map has about seven to ten top-level capabilities and no more than two or three levels.
  • Every capability has a named business owner.
Section titled “Related”

Sources

Section titled “Sources”