Capability Model
A structured map of what a business does, independent of how it is organised or which systems support it, used to align technology investment with function.
A capability answers what the business does — "manage customer credit", "fulfil an order", "settle a payment" — not how it does it, who owns it, or which system supports it. That independence is the point: organisations restructure and systems are replaced, while capabilities are stable for decades.
What it is used for: identifying duplication, where three systems support the same capability because three departments each built one; investment targeting, by rating each capability on business importance and current maturity and funding the gap; application portfolio rationalisation, by mapping systems to capabilities and finding both overlaps and unsupported areas; and impact assessment, by seeing which capabilities a proposed change touches.
Practical constraints. Keep it to two or three levels — deeper models are built once and never used. Name capabilities as nouns or gerunds, not organisational units, or it becomes an org chart with a new label and inherits every reorganisation.
Its architectural value is as a stable partitioning candidate: capability boundaries are frequently good service and team boundaries, because they reflect what the business does rather than how it is currently arranged — which is the same reasoning behind domain-driven bounded contexts, arrived at from the business side.