Capability-to-Application Mapping
Linking each business capability to the systems that support it, which is what converts two inventories into an analysis tool.
A capability map and an application inventory are each mildly useful. The mapping between them is where enterprise architecture produces findings nobody else can, because it answers questions that require both.
What it reveals immediately:
Duplication — one capability supported by seven systems, usually because seven departments each procured their own. This is the primary input to rationalisation and it is invisible from either inventory alone.
Gaps — a capability rated important with no system supporting it, which is being performed manually or not at all.
Over- and under-investment — spend and change activity plotted against strategic importance, which frequently shows most effort going into undifferentiated capabilities.
Impact and risk — which capabilities a proposed retirement or an unsupported platform affects, in business terms rather than technical ones. This is the form in which technical risk becomes fundable.
Concentration risk — one system supporting many critical capabilities.
The practical constraints: keep the capability model to two or three levels, map at a level of granularity a person can maintain, and accept approximate mappings — a many-to-many relationship with a primary designation is more useful and more sustainable than an exact model nobody updates.