Skip to content

Capability-based planning

The EA problem

Technology inventories age badly when they're organized by technology. "We run 140 applications" tells leadership nothing. "Our Claims Processing capability is supported by six overlapping applications, two of them end-of-life" tells them everything. A capability is a stable expression of what the business does — it changes far more slowly than the systems that deliver it, which makes it the right backbone for planning, investment, and rationalization.

The hard part for mid-market organizations: they know their systems but rarely have a clean capability model, and building one feels like a big up-front project. So it never happens.

How ArcaMira addresses it

A three-level capability hierarchy (/capabilities): L1 domains → L2 capabilities → L3 sub-capabilities. Even a rough two-level map (10–20 capabilities) is enough to start hanging applications against.

Capability is the destination of meaning, reached progressively. ArcaMira never forces you to map an application to a capability at creation time. Instead:

  • AI-assisted discovery suggests likely application→capability links from names and descriptions. You confirm with a click; confirmation creates a real relationship. (See Discovery & connecting.)
  • On import, freshly imported applications automatically queue capability-link suggestions for review.
  • The coverage overlay on the capability map shows, per capability, whether it's covered, at-risk, or a gap — derived from the applications that realise it and their health.

Services — the interfaces of capabilities (/services): where a capability is exposed for others to consume, model it as a service. Capabilities and services sit together under the Business group, deliberately distinct from the Estate (the technical inventory you discover and run) — authored business intent on one side, discovered assets on the other.

Business ownership lives on the capability (see Ownership & accountability) — which is why an application's business owner is derived from the capabilities it serves.

What good looks like

  • A capability map that covers your whole business at L1/L2, with L3 detail where it earns its keep (not everywhere).
  • Most active applications linked to at least one capability — so coverage and redundancy are meaningful.
  • Visible coverage gaps (capabilities with no supporting application) and redundancy (capabilities with many overlapping applications) driving real rationalization conversations.
  • Each capability has a named business owner.

You are not aiming for a perfect, exhaustive, academically pure capability taxonomy. You're aiming for a map that makes investment and rationalization decisions clearer than they were yesterday.