Application rationalization is not an inventory exercise
Counting what you run is the easy part, and the least useful.
Most application rationalization programmes begin by building an inventory and end by presenting one. The list is longer than anyone expected, the spend attached to it is embarrassing, and the recommendation is to retire the bottom quartile. Then very little happens, because a list is not an argument.
Why the list does not produce decisions
Nobody switches off a production system on the strength of a spend figure. The person who has to approve it wants to know what breaks, who depends on it, what the contract says, and what replaces the function it performs. An inventory answers none of those, so the programme stalls at exactly the point it was commissioned to get past.
The deeper problem is the unit of analysis. Application names are unstable — vendors rename, modules get rebranded, one system is three products with a shared login — and they say nothing about what the organization needs to be able to do. Two systems that look unrelated by name are frequently competing to serve the same capability, which is the finding that actually matters and the one a name-based inventory cannot surface.
What an application has to be connected to
A defensible disposition needs each application joined along a chain. Each link can change the answer on its own:
- Capability. What business function does this serve, and what else serves it? This is the only stable unit — capabilities survive vendor changes and reorganisation.
- Workflow. Who uses it, for which step, and what breaks if that step moves somewhere else.
- Integration and data. What reads from it, and whether it is the source of truth for anything. The most expensive rationalization mistakes are made here.
- Infrastructure. What it runs on, and whether that platform is itself under review.
- Contract and renewal. When the next real decision point falls, which usually constrains the sequence more than technical dependency does.
- Utilization. Genuine use rather than provisioned licences.
- Cost. Licence, hosting, support, and the integration maintenance it imposes on everything around it.
- Strategic value. Whether it does anything the organization competes on.
Rationalization becomes decidable when the question shifts from should we keep this system? to which system should own this capability, and what happens to the others? The second question has a defensible answer. The first invites a defence of the incumbent.
How does application rationalization relate to enterprise architecture?
They are frequently discussed as alternatives, and they are not. Application rationalization is a portfolio decision discipline: what happens to the systems. Enterprise architecture is the structural context those decisions are made inside: capabilities, standards, data ownership, target state.
Rationalization operates within the architecture and informs it. The capability map that makes rationalization decidable is an architecture artifact; the dispositions rationalization produces are how a target architecture actually gets realised rather than remaining aspirational. Organizations that run them as separate engagements usually end up with two incompatible views of themselves and trust neither.
The practical consequence: establish the capability map once, and share it. Doing it twice is how the incompatibility starts.
The other half of the problem
Even a well-connected rationalization has a shelf life. It is an assessment of a moving estate, and within two quarters a division will have bought something, a migration will have slipped, and a vendor will have been acquired. The analysis does not announce which of its conclusions those events invalidated.
That is a separate argument, developed under why application rationalization should be continuous and in the reconciliation section of the application rationalization page.