Application Rationalization Framework: What TIME and Pace-Layering Assume About Your Organisation, and When Those Assumptions Break

Every application rationalization framework in common use was designed to bring order to a complicated decision. Pick the right model, fill in the data, and the portfolio sorts itself into tidy categories: invest here, retire that one, migrate the rest. The appeal is obvious. The problem is that every framework carries a set of assumptions about your organisation, and if those assumptions are wrong, the output is wrong with them - quietly, confidently, and sometimes expensively.

Most organisations discover this somewhere between the workshop and the board presentation. The framework said migrate. The team that owns the system said nobody actually knows how it works anymore. The framework said eliminate. The CFO said that system is contractually embedded in a client relationship that runs for another four years. The model had no column for that.

This is not an argument against using an application rationalization framework. It is an argument for understanding what any given framework is and is not capable of telling you before you stake a capital programme on its output.

What is an application rationalization framework, and what problem is it trying to solve?

The underlying problem the frameworks address is real. Most organisations accumulate software the way they accumulate any operational asset: one decision at a time, over years, without a consistent plan. A system is bought to solve a specific problem. It solves it. The problem evolves. The system is extended, integrated, worked around. Eventually the organisation has a portfolio of eighty or a hundred and twenty systems, many of which overlap, most of which have changed hands at least once, and some of which nobody can fully describe without calling in a contractor who left in 2019.

The cost of this accumulation is not just the licence fees. It is the engineering time spent on integrations that exist only because two systems that do the same thing were never consolidated. It is the risk carried in systems that have no active vendor support and no internal team member who understands the codebase. It is the opportunity cost of a team that spends its capacity keeping the lights on rather than building anything new.

A rationalization framework does not eliminate that cost overnight. What it does is give a leadership team a shared vocabulary and a defensible method for making portfolio decisions systematically rather than reactively.

The two frameworks that dominate the conversation in practice are Gartner's TIME model and Gartner's pace-layering model. A McKinsey framework based on a two-axis business value versus technical health grid is also widely referenced, though McKinsey's public guidance on this is embedded in broader transformation research rather than published as a discrete methodology. Each framework has a different entry point and a different set of assumptions. Understanding those assumptions is the main job before you choose one.

What does the Gartner TIME model do, and where does it fall short?

The TIME model was developed by Gartner as part of its application portfolio management methodology. The logic is straightforward. Plot each system on a two-by-two grid. High business value and good technical condition: Invest. High business value and poor technical condition: Migrate. Low business value and acceptable technical condition: Tolerate. Low business value and poor technical condition: Eliminate.

The appeal of the model is that it forces a conversation that most organisations avoid. It requires someone to put a number, or at least a rating, on the business value of each system. That is uncomfortable. The system the sales director has used for fifteen years tends to be rated high on business value because the sales director is in the room. The system that runs payroll tends to be rated low on business value because nobody on the leadership team has ever noticed it failing. Neither rating is reliable.

The more structural problem is the technical condition axis. To score a system honestly on technical condition, you need to know something about its architecture, its dependencies, its test coverage, its vulnerability profile, and the state of its vendor relationship. That knowledge rarely sits in the room where the TIME assessment is being run. It sits with engineers who are often not invited, or who have been told to let the leadership team lead.

The result is a TIME output that reflects the confidence of the people in the room rather than the actual state of the estate. Systems that are politically important get categorised as Invest. Systems that nobody advocates for get categorised as Eliminate. The framework has done nothing wrong. The inputs were simply not what the framework assumed they would be.

The TIME category that tends to be most valuable, and most underused, is Tolerate. It is the category that says: this system is not in great shape, and it is not delivering transformational value, but the cost and disruption of changing it exceeds the benefit. Leave it alone. For many organisations, ten to twenty percent of their estate genuinely belongs in Tolerate, and the honest answer is that it should stay there for the foreseeable future. A rationalization process that produces no Tolerate outcomes should be treated with suspicion.

How does pace-layering change the question?

The pace-layering model, introduced by Gartner analyst Brian Burke and popularised through Gartner's application strategy research, approaches the rationalization question from a different angle. Instead of asking "what condition is this system in?", it asks "how much does this system need to change, and at what rate?"

Systems of Record are the stable core: financial ledgers, HR systems, inventory management platforms. They change slowly, prioritise data integrity and reliability over flexibility, and are often the systems with the longest tenure and the most embedded dependencies. Aggressive modernization of a System of Record is almost always riskier than it looks.

Systems of Differentiation change on a medium cycle, typically aligned to business strategy and competitive positioning. A pricing engine, a customer service platform, a supply chain optimisation tool. These are the systems where investment in modernization is most likely to generate a return, because the business is actively asking them to do new things.

Systems of Innovation are experimental and fast-moving: pilots, proofs of concept, new digital channels. They are expected to change rapidly and may never reach production at scale. The key governance question for these systems is not whether to modernize them, but whether to formalize them at all.

The assumption pace-layering makes is that you can reliably classify your systems into these three layers. In many organisations, that classification is genuinely ambiguous. A system that began as a System of Record has been extended over years to include differentiating logic. A system that was bought as an innovation platform has become load-bearing infrastructure that the operations team depends on daily. When systems have drifted between layers, pace-layering gives you a vocabulary to describe the problem but not a simple answer to it.

The more practical use of pace-layering in a rationalization exercise is as a prioritisation lens. If you have forty systems to assess and limited time, assess the Systems of Differentiation first. Those are the systems where the business is most likely to be feeling active pain, and where an investment or migration decision is most likely to have a near-term impact.

What do both frameworks assume that your organisation may not have?

This is where most application rationalization exercises encounter their real difficulty, and it is worth being specific about each assumption.

Accurate cost data. Most organisations can tell you what they pay in licence fees. Far fewer can tell you what it costs in engineering time to maintain each system, what the integration overhead between systems costs annually, or what the opportunity cost of running an unsupported platform amounts to in risk remediation effort. Without that data, the financial case for any rationalization decision rests on incomplete information. The Standish Group's CHAOS research has consistently found that IT projects are more likely to overrun when the base cost data for the systems being replaced is not established before the replacement begins.

Clear ownership. Organisational change, outsourcing arrangements, and acquisitions leave many systems in a state of ambiguous ownership. The system exists, it runs, but the person nominally responsible for it has moved on, the vendor relationship is managed by procurement, and the team that uses it most sits in a business unit that was restructured two years ago. A rationalization framework asks you to assign a decision to each system. If ownership is unclear, the decision will be deferred or made by the wrong person.

Business value assessment without distortion. This is the hardest assumption. Business value is not an objective measure. It is a judgement made by people who have interests in the outcome. The discipline required to produce an honest business value assessment often requires a structured scoring approach agreed before the assessment begins, combined with challenge from someone who has no stake in any particular outcome. Without that structure, the value ratings reflect organisational politics rather than economic reality.

Capacity to act. A rationalization assessment produces a prioritised list of decisions. Acting on those decisions requires engineering time, change management effort, budget, and leadership attention. If the organisation is already running at capacity maintaining the existing estate, the rationalization output may be accurate and entirely unactionable. That is not a failure of the framework. It is a constraint the framework cannot see.

When should you use a framework, when should you modify one, and when should you stop?

The practical answer to "which application rationalization framework should we use?" is usually "the one whose assumptions most closely match your current state of knowledge, adapted for the parts that do not fit." That is less satisfying than a simple recommendation, but it is more honest.

For organisations with a reasonably inventoried estate, clear ownership, and decent cost data, the TIME model is a sensible starting point. It is widely understood, the output is easy to communicate to a non-technical audience, and the four categories map naturally to budget decisions. Invest and Migrate categories need funding. Tolerate and Eliminate categories should, in principle, reduce the cost base over time.

For organisations where the primary strategic question is about speed of change rather than technical condition, pace-layering provides a better frame. It is particularly useful when the conversation is about whether to invest in a new platform versus extending an existing one, because it forces the question of which layer the capability belongs in before the platform decision is made.

For organisations where regulatory and compliance requirements are dominant - financial services, healthcare, critical infrastructure - both standard frameworks may need a third axis. Technical condition and business value may both be secondary to whether a system can meet an upcoming compliance requirement. A system in poor technical condition that is about to become non-compliant is not a Tolerate; it is an emergency.

The most common mistake is running a framework exercise when the base data is not ready. When an organisation cannot score more than fifty or sixty percent of its systems with reasonable confidence on the primary axes, the framework output is misleading rather than useful. The right answer in that situation is to stabilise the inventory first: establish what the systems are, who owns them, what they cost to run, and what they do. That work is unglamorous and often skipped. It is also the work that determines whether the rationalization that follows is a genuine portfolio decision or an expensive exercise in documenting assumptions that were wrong from the start.

Konnectedly's independence is relevant here. Because we do not build the replacements, we have no reason to recommend migration when stabilisation would do, or to recommend investment when the honest answer is to tolerate the system for another three years and revisit. The frameworks are tools. The discipline is in knowing when to trust their output and when to push back on it.

Frequently Asked Questions

What is an application rationalization framework?

An application rationalization framework is a structured method for deciding what to do with every system in an organisation's software portfolio: invest, maintain, migrate, or retire it. The most widely used frameworks are Gartner's TIME model and Forrester's pace-layering model. Each gives decision-makers a consistent vocabulary and a repeatable process for portfolio decisions.

What does the TIME model stand for in application rationalization?

TIME stands for Tolerate, Invest, Migrate, and Eliminate. Gartner developed it as part of its application portfolio management guidance. Each system in the estate is placed into one of the four categories based on its technical condition and its business value. The model's strength is its simplicity; its weakness is that it requires honest data on both dimensions, which most organisations do not have ready-made.

What is pace-layering and how does it apply to application rationalization?

Pace-layering, also from Gartner, segments systems by how quickly they need to change. Systems of Record change slowly and prioritise stability; Systems of Differentiation change on a medium cycle aligned to business strategy; Systems of Innovation change rapidly and are often experimental. In an application rationalization exercise, the layer a system belongs to determines how aggressively you should modernize or replace it.

What assumptions do these frameworks make that may not hold for every organisation?

Both TIME and pace-layering assume you have reasonably accurate data on business value and technical condition, that ownership of each system is clear, and that your organisation can execute change at the pace the framework implies. When those conditions are absent - which is common in organisations with large, undocumented estates - the framework output is only as reliable as the data fed into it.

When should you leave a system alone rather than rationalize it?

When the cost and risk of change exceed the cost and risk of continuing to run the system as it is. A stable system with no current growth requirement, modest running costs, and no active integration pressure is often better left alone. The frameworks support this conclusion; the TIME category "Tolerate" exists precisely to name it without apology.

How long does an application rationalization exercise typically take?

For an estate of 50 to 150 systems, a structured rationalization assessment typically takes six to twelve weeks. Larger estates with poor documentation take longer, not because the framework is complex, but because establishing the base data - who owns each system, what it costs to run, and what business process depends on it - is the actual work.

What is the difference between application rationalization and application modernization?

Rationalization decides what to do with each system. Modernization describes how to change the ones that warrant investment. Rationalization comes first. Beginning a modernization programme before completing a rationalization assessment risks spending significant capital improving systems that a clear-eyed portfolio view would have flagged for retirement.

Can a small organisation use the same application rationalization frameworks as a large enterprise?

Yes, with adjustment. The TIME model and pace-layering were designed for large estates, but their underlying logic - assess business value, assess technical condition, match the answer to a category - applies at any scale. A smaller organisation may find the full Gartner methodology more elaborate than it needs, but the core two-axis assessment remains useful even for a portfolio of twenty systems.