Application Portfolio Management and Rationalization: Where to Start

Start with the inventory

Spreadsheets diverge, owners change, and nobody knows any longer which applications still deserve their place. Application portfolio management keeps a single inventory and treats applications as a portfolio to measure, compare and rebalance.

For each application, the inventory states who owns it, which vendor supplies it, where it stands in its lifecycle, what it costs, what condition it is in and what depends on it. Rationalization builds on this inventory.

The information that drives decisions

A list says what the organization owns. The portfolio adds the information that drives decisions, collected at regular intervals. Without it, every renewal, audit or transformation starts the same reconstruction work again.

In ArchiLU, each application is linked to its capabilities, processes, interfaces, technologies and contracts: before changing it, its owner sees what depends on it. Every twelve months, each owner receives a task to confirm their objects.

• Ownership: a named business and IT owner for each application.
• Vendor exposure: the vendors the organization depends on, and how concentrated that dependency is.
• Technologies: the stack behind each application and the versions reaching end of support.
• Lifecycle: from pilot to production, then to retirement.
• Dependencies: what calls what, so nothing is retired blindly.
• Contracts and costs: licenses, end dates and renewals.

Rationalization, a recurring decision

Rationalization decides which applications to keep, evolve or retire. It comes back with every budget cycle and every contract renewal. The goal: reduce duplication, remove avoidable cost and lower risk without breaking the business that relies on these systems.

An expensive application supporting a regulated process does not become a retirement candidate because it shows up in red in the budget. Conversely, a cheap application can be the riskiest one in the estate if it runs on unsupported technology and nobody remembers how it works. The decision therefore weighs value, quality, cost and risk together.

The TIME model: Tolerate, Invest, Migrate, Eliminate

Gartner’s TIME model places each application by business value and technical quality. The quadrant suggests a default action. The model opens a structured discussion; owners settle the borderline cases.

In ArchiLU, the TIME view places each application by its users’ opinion and the share of its technologies still supported. The class remains a recorded decision with its reason: the application owner proposes it, the enterprise architect confirms it. After “Eliminate” or “Migrate”, the owner chooses to prepare the retirement or to open a request. User opinions are private: they are read only in aggregate, over twelve months and from five respondents.

• Tolerate: low value, sound technology. The application stays, with no new investment, under watch.
• Invest: high value, sound technology. The application is protected and modernized; new spending goes here.
• Migrate: high value, fragile technology. The application is replatformed or replaced before it becomes a liability.
• Eliminate: low value, fragile technology. The application is retired, together with the cost and risk it carried.

Cost, health and risk

TIME gives the decision its shape; three families of information say how confidently to make it. Cost covers license, hosting, support and internal effort. Health covers functional fit, stability, user satisfaction and how current the technology is. Risk covers vendor fragility, single points of failure, regulatory exposure and end-of-life components.

In a bank, a payments-adjacent application with a fragile vendor and an unsupported runtime is a risk question well before it is a cost question. In a public body, an old, inexpensive forms system that only one developer close to retirement understands is a continuity risk. The information is the same; its weight changes by sector.

In ArchiLU, a contract is allocated to the applications it covers, with the reasoning for the split, and the Contracts page shows the end date and any automatic renewal detected. Each application shows its technology stack; 90 days before an end of support, a case opens: extend, migrate, retire or accept the risk.

Technical debt and the cost of waiting

Technical debt is the gap between how an application is built today and how it would need to be built to be safe, maintainable and adaptable. It rarely causes one dramatic outage. It shows in rising maintenance effort, slower change, dependence on a few people and a security surface nobody fully sees.

It changes the rationalization calculation. An application that looks cheap on the license line can prove expensive once the maintenance effort and the risk of running it without support are counted. Making debt explicit, application by application, stops it from deciding the roadmap instead of the owners.

Retirement and total cost of ownership

Deciding to retire an application is the easy part; retiring it without incident takes preparation. Failed retirements trip over hidden dependencies, data retention obligations and downstream reporting nobody knew existed. Sequencing helps: cut the inbound interfaces, archive the data, then retire the application.

In ArchiLU, “Retire” opens a four-step case: impact, replacement, decision and execution. The portfolio review shows the cost of retirement candidates, the estimated savings and the realized savings, each with its period and currency; an unknown never counts as zero.

Total cost of ownership counts license and hosting, but also implementation, integration upkeep, internal maintenance, support and the premium of aging technology. Two applications with the same license line can have very different total costs, and that gap often moves a decision from tolerate to migrate or eliminate.

After a merger

Two combined estates often hold several applications for the same capability. The work starts from the capability map: each capability supported by several applications points to a duplicate to examine.

In ArchiLU, the dashboard shows the capabilities supported by several applications. Each duplicate goes through its TIME class, then through retirement or “Merge”, which moves its links to the application that remains. The savings of each estate are read in its own currency.

Keeping rationalization going

A one-off rationalization audit ages quickly: new applications arrive, owners change, and the inventory drifts back to the spreadsheet. Governance keeps the portfolio current with an owner for the inventory, a regular review and a rule: no application enters the estate without an owner, a place in the model and a declared lifecycle.

Rationalization holds better when it follows existing rhythms: budget cycles, contract renewals, transformation milestones. Decisions last when the portfolio is the same model the architects, finance and risk teams already use.