Adopting this catalog

Start from it, do not adopt it whole

No reference model fits one organization as published. Expect to rename, merge or split a fair share of capabilities, and to drop the ones you will never own or fund. A smaller map that people use beats a complete one that nobody reads.

• Pick the cross-industry domains you need, then add your industry block.
• Read the in scope and out of scope lines before renaming: they say what each capability means here.
• Keep the catalog id beside your own name, so you can take later releases without losing your edits.

Owners and experts

Two roles keep a capability model useful. A business owner is accountable for the capability's performance and for what its name and description mean. An architect acts as the model's caretaker for that capability, keeping it consistent with the rest of the map and linked to applications, data and value streams. Different methods put the emphasis on one or the other; in practice you need both.

Test it against your value streams

Walk each of your value streams stage by stage and check every stage is served by a capability you kept. A capability no stream needs may not be worth keeping; a stage with no capability is a gap in the map.

Getting it into your tools

• Download ready-made files for ServiceNow, LeanIX and Ardoq, or a generic CSV, from Exports.
• Query the catalog from code over the JSON API, or from an AI agent over MCP.
• Each release is numbered and listed with what changed; retired ids name their successor, so an import can be refreshed safely.