Application Rationalization: The Complete Method, Anchored on Business Capabilities

Application rationalization is almost always the first challenge I'm brought in to solve when I arrive as an enterprise architect in a large corporation. The diagnosis barely ever changes: an application landscape that grew organically, project after tactical project and merger after merger, with functional overlaps everywhere, applications maintained out of habit rather than necessity, and run costs drifting upward year after year until they suffocate the innovation budget. Nobody can say with certainty how many applications the IT estate actually contains, or which ones still serve a living business purpose.

In fifteen years of engagements, I've learned that application rationalization fails whenever it's run as a purely IT cost-cutting exercise, and succeeds whenever it's anchored on business capabilities. The question isn't 'which applications can we switch off?' but 'what does the organization know how to do, and is each capability over-tooled, under-tooled, or properly served?' This article lays out the method I apply in the field, from initial mapping to arbitration, with measured results.

Why an application landscape drifts — and why cutting isn't enough

An application landscape never becomes redundant out of bad intent. It drifts because every project, taken in isolation, made a rational choice: buy one more tool, duplicate a function to move faster, work around an application deemed too rigid. After three decades, the aggregate result is unmanageable, even though every individual decision was defensible.

That's why attacking rationalization through the application list alone is a classic mistake. You get an endless debate where every owner defends their tool, with no shared frame of reference. The right entry point isn't the application — it's the business capability: what the organization knows how to do, independent of the tool that supports it. Once that reference is in place, redundancy stops being an opinion and becomes a visible fact.

Anchor rationalization on the business capability map

Before any assessment matrix, I stabilize a business capability map across two or three levels. A capability describes the 'what' — Manage Claim, Execute Payment, Acquire Customer — and stays stable over time, neutral with respect to technology. That's exactly what makes it a good anchor: an application comes and goes, a capability endures.

Concretely, I run short workshops with business directors to validate 5 to 8 level-1 capabilities, broken down into 30 to 50 level-2 capabilities. We avoid the process trap: a capability isn't a handling step (the 'how'), it's an ability. Until you've cleanly separated the what from the how, maps become unreadable and change with every reorganization.

This map becomes the backbone of the entire effort. It serves as a common language between the executive committee, IT, and delivery teams, and above all it conditions what follows: you don't rationalize applications in a vacuum, you rationalize how a portfolio supports capabilities ranked by their strategic value.

Mapping with ArchiMate®: making the invisible visible

Mapping is my first concrete move. I use ArchiMate® to model the links between business capabilities, applications, and infrastructure — not as an academic exercise, but as the instrument that makes the invisible visible. The diagram that changes everything is the capabilities × applications matrix: capabilities in rows, the application portfolio in columns, and actual support at the intersections.

When a CIO sees on a single view that three applications cover the same capability for three different subsidiaries, the discussion stops being political and becomes factual. The configurations speak for themselves:

• A capability covered by several redundant applications: a natural consolidation candidate.
• A strategic capability running on a spreadsheet or a shadow system: an urgent risk to address.
• A low-strategic capability that's over-tooled: an easy saving to capture.
• An orphan application no longer serving any living capability: a candidate for outright elimination.

I model these views in ArchiMate® 3.2 and industrialize them in a repository (MEGA HOPEX, LeanIX, or Ardoq depending on context), leveraging the native relationship between Application and Capability. The tool only matters because it keeps these links current; a diagram drawn once for a meeting is worthless.

Assessing the portfolio: the TIME matrix enriched with field criteria

Once support is mapped, I assess each application with the TIME matrix — Tolerate, Invest, Migrate, Eliminate. But the raw matrix isn't enough: I systematically enrich it with quantified, context-specific criteria, otherwise the ranking stays subjective.

• Measured technical debt (platform obsolescence, vendor support, coupling level).
• Annual maintenance cost, including run and licenses.
• Real active user count, not declared.
• Strategic value of the capability or capabilities served.
• Alignment with the target IT trajectory.

Every application is reviewed with both business and IT teams, never in isolation. Crossing 'strategic value of the capability' × 'support quality' produces a heatmap that ranks decisions without debate: you invest where a critical capability is poorly served, you eliminate where a secondary capability is over-tooled.

The decision phase: the most political moment

Mapping and assessment are the easy parts. The decision phase is the most political, because behind every application there's a team, a budget, sometimes an ego. That's precisely where my status as an external architect becomes an asset: I can ask the hard questions without carrying the internal stakes.

'This application has 12 users and costs €200K a year in maintenance — what's the plan?' Asked by an external consultant and backed by facts, the question becomes debatable without becoming a personal attack. I tackle quick wins first: risk-free eliminations, obvious duplicates. They quickly demonstrate the value of the approach, free up budget, and bring teams on board for the heavier trade-offs that follow.

I always formalize the target with the same vocabulary as the current state: transformation thus becomes the explicit arbitration between a current and a target state, capability by capability. You no longer ask 'should we keep this application?' but 'what minimal portfolio covers our strategic capabilities at the best cost?'

Govern the target so it doesn't drift again

Rationalizing without governance is like emptying the bathtub without turning off the tap: the landscape rebuilds itself within two or three years. So I always couple the effort with a few durable guardrails. One simple principle — 'buy before build', 'one reference application per capability' — beats ten rules nobody enforces.

The second lever is systematically reviewing new projects against the capability map: every application investment must declare the capability it serves and justify why the existing portfolio isn't enough. It's this discipline, not the big initial cleanup, that sustains the savings over time. Without a business owner on the executive committee, the repository quickly reverts to an abandoned IT artifact the moment the consultant leaves.

Observed results and pitfalls to avoid

The results I've measured on engagements are significant: a 20-30% reduction in application maintenance costs, a clear simplification of integration flows, and above all a much better ability of the IT landscape to absorb new projects. You routinely eliminate 25-35% of the steps or duplicates in a landscape that has drifted for years. Rationalization isn't an end in itself — it's a transformation enabler.

Three pitfalls recur. Confusing exhaustiveness with value: trying to map everything before a single decision exhausts the sponsor. Confusing capability and application: without the capability anchor, you cut blind and sometimes remove the support of a critical capability. And underestimating politics: rationalization is first a change-management effort, not a spreadsheet exercise.

What I take from the field

Successful application rationalization never starts with the application list. It starts with the business capability map, which turns a clash of opinions into arbitrable facts. ArchiMate® mapping makes redundancy visible, the enriched TIME matrix ranks the decisions, and governance keeps the landscape from drifting again.

The real success indicator isn't the number of applications switched off. It's the organization's regained ability to invest where it matters, because it can finally see clearly what it does, with which tools, and at what cost.