App Rationalization Is a Decision Process, Not a Spreadsheet

The register exists. Someone built it, probably in a spreadsheet, possibly in a tool, almost certainly with more rows than anyone expected. It lists the applications, notes the vendors, records the annual licence costs, and sits in a shared folder that gets opened every time the portfolio conversation comes around again. And then, meeting after meeting, nothing gets decided. The register is not the problem. The problem is that app rationalization is a decision process, and the register was built to hold data, not to force a verdict.

This distinction matters more than it sounds. A portfolio register that cannot answer the right questions before a decision meeting does not slow rationalization down a little. It stops it. The meeting fills with clarifying questions, the action items are "go and find out", and the decisions are deferred to a next session that carries the same unresolved questions forward. If this pattern is familiar, the issue is almost certainly not the people in the room. It is that the register was designed to describe the estate rather than to support a verdict on it.

What is app rationalization, and what does it actually require?

The word "rationalization" does real work here, and it is worth being precise about what it means. To rationalize is to impose a logical structure on something that has grown without one. Most application estates grew exactly that way - through acquisition, through departmental initiative, through the accumulation of workarounds that became permanent. The estate is not irrational in the pejorative sense. It is simply unexamined. Rationalization is the examination that produces a verdict.

What that requires, at minimum, is four things the register must be able to answer for each application before anyone sits down to decide.

The first is business purpose: what capability does this application support, and is that capability still needed? Not "what does it do technically" but "what would stop working, and for whom, if it were gone tomorrow". This is a business question, and it has to be answered by someone in the business, not by IT reading the system documentation.

The second is true cost. Licence fees are the visible part. The harder figure is the total cost of running and tolerating the application - support contracts, infrastructure, the developer hours spent keeping it integrated, and the operational workaround time that never appears on any invoice. A system with a £40,000 annual licence can easily cost £300,000 a year once you count everything that the licence fee does not.

The third is integration weight. How many other systems depend on this one, and in which direction does the dependency run? A system that feeds fifteen downstream processes carries a rationalization cost that has nothing to do with the system itself. You are not deciding about the application; you are deciding about the network it sits inside.

The fourth is replacement difficulty. This is not the same as age or technical condition. Some old systems are replaceable in months. Some modern systems are entangled in a way that makes replacement a multi-year programme. The register needs to hold an honest, independently formed view of this, not an estimate from the team that built the integrations and would likely build the replacements.

When those four answers are present, the decision meeting can make decisions. When they are absent, the meeting makes action items.

Why do most app rationalization exercises produce reports instead of decisions?

There is a pattern that runs through most stalled rationalization programmes, and it is consistent enough to describe precisely. The exercise begins with an inventory. The inventory reveals that data is missing, contested, or unreliable. The programme pivots to data quality. By the time the data is in reasonable shape, the budget or the appetite is gone, and the deliverable becomes a better-documented version of the original register rather than a set of funded decisions.

This happens because the people running the exercise are, reasonably, trying to be thorough. The error is in the sequencing. Data quality is pursued to the point of completeness before any decision is made. But completeness is a horizon that moves. There will always be one more application whose ownership is unclear, one more integration whose data flow has not been mapped, one more cost figure that needs finance sign-off.

The discipline that breaks this pattern is deciding, before the data collection begins, what level of information is sufficient to make a call.

For a retire-or-keep decision, you probably need business purpose, annual cost, and a named owner. You do not need a full architectural diagram. For a replace decision, you need integration weight and replacement difficulty as well. For an invest decision, you need a business case with a payback period. Setting these thresholds in advance gives the data collection a stopping point. The register does not need to be perfect. It needs to be good enough for the decision type at hand.

The Gartner TIME model - Tolerate, Invest, Migrate, Eliminate - is useful here not because the quadrant labels are revelatory but because they force the exercise to be explicit about which decision type is being made. Each quadrant implies a different information threshold. Using the model as a decision framework rather than as a classification exercise keeps the programme oriented toward verdicts rather than records.

What does the register need to hold before rationalization decisions can be made?

It is worth going through these one at a time, because each one has a common failure mode.

Business capability is frequently recorded as a system category ("ERP", "CRM", "reporting") rather than as a specific business function ("invoicing for the UK entity", "field sales pipeline management", "weekly board pack generation"). The category is not useful for rationalization. The function is. When a rationalization decision is made, the question is whether the specific function is still needed, whether something else already delivers it, and what the consequence of removing it would be. Categories do not answer those questions.

Annual cost has a data problem that most finance systems make worse. Licence fees appear on contracts. Infrastructure costs appear on cloud or hosting invoices. But the third and largest element - the labour cost of running, supporting, integrating, and working around the application - is distributed across dozens of timesheets that were never coded to this system. Capturing it requires estimation, and estimation requires talking to the people who actually do the work. This is the figure most registers omit, and it is the one that most often changes the decision. A system that looks cheap by licence fee can look very different when someone calculates how many hours a month the team spends extracting its data into a format something else can use.

Integration weight requires a conversation with the architecture team, not just a lookup in the register. The number of integrations matters, but direction matters more. A system that receives data from one source and feeds fifteen others is load-bearing in a way that a system with the reverse topology is not. Retiring a load-bearing system without first understanding what depends on it has produced some of the more expensive unplanned outages in recent enterprise IT history.

Replacement difficulty is the figure most likely to be distorted by the people whose estimate is sought. A team that built a complex integration naturally tends to describe it as complex to replace. An independent view of this - someone without a build contract to protect - is worth having before the number goes into the register as fact.

When is "leave it alone" the right rationalization verdict?

This verdict is under-represented in rationalization frameworks, and its absence does real damage. When every rationalization exercise points toward investment or replacement, the reader stops believing it. The steering committee has seen the presentation before. It says the estate is in trouble, it recommends modernization, and it happens to be written by people who modernize things for a living. The conflict of interest is structural, not personal, but it produces the same outcome: a sceptical audience that defers the decision.

An honest rationalization process finds a meaningful proportion of systems where the right answer is to do nothing. What "meaningful" looks like depends on the estate, but in most portfolios that have been reviewed rigorously, somewhere between a third and half of applications fall into the tolerate or leave-alone category. They are not exciting. They are functioning. The function costs what it should cost, the system is not entangled in anything that creates risk, and nobody is asking questions about it.

The discipline is to reach this verdict deliberately, with the evidence recorded, rather than by default because nobody got around to looking at it.

There is a difference between a system that has been reviewed and found satisfactory and a system that has simply not been reviewed. The first is a managed asset. The second is a risk that has not been quantified. App rationalization should produce both types of verdict: systems that are actively earmarked for action and systems that have been consciously cleared and can be deprioritised until the next review cycle.

The same logic applies to retirement. Some systems on the register are simply finished. The business function they served has changed, the users have moved to something else, or the volume has dropped to a level that makes the fixed cost of running it indefensible. These do not need a modernization programme. They need a retirement plan, a data migration where data needs to be retained, and a date. Straightforward retirements are often deferred because nobody claims ownership of the work. That deferral costs money every month the system stays running.

How should the rationalization process be structured to produce funded decisions?

The temptation in every portfolio review is to do all of it at once. The estate is mapped, the register is built, the heat map is generated, and the presentation is delivered to the steering committee with every system plotted against every other. This is satisfying to produce. It is very difficult to act on.

The steering committee sees sixty systems requiring attention, in four different categories, across five business domains, with a range of investment figures that total more than anyone would approve in a single budget cycle. The response is predictable. The committee acknowledges the analysis, asks for a prioritized subset, and commissions a business case for the top three. The rest goes back to the register.

The alternative is to structure the exercise as a series of smaller decision gates from the beginning. The first gate covers the systems where the data is clearest and the decision is most defensible - typically the highest-cost and highest-friction applications. These are the ones where the "leave it alone" verdict is least likely to survive scrutiny and where retirement or investment is easiest to cost. Making decisions at this gate, getting them funded, and beginning implementation before the next gate opens creates momentum that the full-portfolio approach rarely generates.

It also builds institutional confidence. A steering committee that has seen one rationalization decision execute correctly is much more willing to approve the next one. The register becomes a live document that feeds a rolling programme rather than a one-time deliverable that ages in a folder.

Konnectedly's approach to this is explicitly staged: assess the highest-priority tier, deliver fundable verdicts, then move to the next tier once those decisions are in motion. The point is not to produce a complete portfolio view on day one. It is to produce decisions that someone can act on this quarter.

Frequently Asked Questions

What is app rationalization?

App rationalization is the structured process of deciding what to do with every application in a portfolio: keep it as-is, invest in it, retire it, or replace it. It is not an inventory exercise. The inventory is the starting point. The rationalization is the series of decisions the inventory has to support, each one explicitly made and owned.

What is the difference between app rationalization and application portfolio management?

Application portfolio management is the ongoing discipline of tracking, governing, and optimizing a set of applications over time. App rationalization is a specific decision event within that discipline, where each application is evaluated and assigned a direction. Rationalization is what you do with the portfolio management data, not the data collection itself. One is continuous; the other is a periodic verdict.

How long does an app rationalization exercise take?

For a portfolio of 50 to 150 applications, a focused rationalization review typically takes eight to twelve weeks when data gathering, business interviews, and decision facilitation run in parallel. Larger estates with poor documentation take longer - not because the process is harder, but because establishing what each system actually does takes time that no spreadsheet can compress.

What data does a portfolio register need before rationalization decisions can be made?

At minimum: the business capability each application supports, its annual total cost of ownership (licensing, infrastructure, support labour, and workaround time), the number and direction of its integrations, its replacement difficulty, and a clear owner who can speak to its actual use. Missing any one of these turns the decision into a guess dressed up as analysis.

Why do most app rationalization exercises stall before producing decisions?

Because they are set up as data projects rather than decision projects. The team builds the register, discovers that data is incomplete or contested, and spends the remaining budget cleaning records rather than making calls. The fix is to set the decision threshold before the data collection begins, so the team knows what level of information is enough to act on each decision type.

Should every application in a portfolio be rationalized at the same time?

No. Full-portfolio rationalization in one pass produces analysis paralysis and decision fatigue at the steering committee level. The more effective approach is to start with the highest-cost and highest-friction systems, make decisions there, begin implementation, and then move to the next tier. Staged rationalization produces outcomes. Full-portfolio rationalization in a single cycle typically produces reports.

What are the four possible outcomes of an app rationalization decision?

Retain as-is, invest and modernize, retire without replacement, or replace with an alternative. Some frameworks add a fifth - consolidate, where two systems doing the same job are merged into one. What matters is that every application receives one of these verdicts explicitly, not by default, and that someone with budget authority has agreed to the verdict and the timeline attached to it.

How do you handle applications where no one knows who owns them?

Treat ownership as a decision prerequisite, not a data quality problem. If no one will claim an application, that is itself a signal. Run a short structured interview with the business units most likely to depend on it. If none surface, the application is a candidate for retirement on the grounds of zero accountable ownership. Document that reasoning carefully - it will be challenged, and you need the audit trail.