A services marketplace maps its architecture by listing its microservices. Why is that not a capability map, and what does the difference change?

The difference

A service list describes how the system is currently built. A capability map describes what the business does, independent of implementation. "Match a customer to an available professional" is a capability; "dispatch-service" is a deployment artefact that currently implements part of it.

The map is stable across rewrites, reorganisations and technology changes. The service list changes quarterly.

What the difference changes

• It makes duplication visible. Three teams having built their own pricing logic is invisible in a service list — they have different names — and obvious in a capability map, where three implementations sit under one capability.
• It makes gaps visible. A capability that no team owns, such as "verify a professional's credentials across categories", is missing from a service list by construction.
• It gives investment a language the business shares. "We are under-invested in supply onboarding" is a sentence a business leader can act on; "the onboarding service has technical debt" is not.
• It survives reorganisation. Team boundaries change; the business's capabilities do not, which is why the map is the durable artefact.

How to build one usefully

Two or three levels, no more. A map with two hundred leaf capabilities is a taxonomy exercise nobody consults. Ten to fifteen top-level capabilities decomposed one level is enough to have the conversations the map exists for.

Assess each on two axes: how well it is done, and how much it matters. That produces a prioritisation directly, and the quadrant of high-importance-low-maturity is the investment case.

The trap

Building the map and stopping. A capability map that is not used to make an investment decision, resolve a boundary dispute or justify a rewrite is documentation, and it will be out of date before anyone asks for it.

The map's value is entirely in the decisions it changes, which means it should be built in response to a decision that needs making rather than as an artefact in its own right.