Application rationalisation with AI: what to automate and what stays a judgement

Application rationalisation decides which applications to keep, invest in, replace or retire. AI helps most with the evidence work that stalls it: reconciling records across the EA repository, the CMDB and the finance system, finding overlap by capability, and drafting a candidate list with the records behind each line. It should refuse when evidence is missing. Business criticality, sequencing, contract negotiation and the final decision stay with people. The method below keeps every call traceable to the records a steering committee can check.

Why does application rationalisation stall?

Rationalisation programmes rarely fail on the framework. They fail in the spreadsheet, before anyone decides anything.

The data has gaps. Each decision needs an owner, a cost, a measure of use and a lifecycle state. Owners have left. Costs sit in a cost centre that pays for ten things. Usage was never measured.

The systems disagree. The EA repository says an application was retired last year. The CMDB still lists servers running it. The finance system still pays its support contract.

The work is slow. Reconciling a few hundred applications by hand takes weeks, and the list is stale when it's finished.

The politics are real. Without evidence, a candidate list becomes a negotiation about opinions, and the loudest owner wins.

Where does the TIME model fail?

The TIME model sorts applications into four calls: Tolerate, Invest, Migrate, Eliminate. It plots technical fit against business value. It frames the conversation well; it doesn't make the decision.

Value and fit are usually scored in workshops. Without cost and usage data underneath, the quadrant records what people believe.

What can AI do well in application rationalisation?

The steps that suit AI read many records across systems, apply a clear rule, and produce something a person can check.

1. Reconcile records across systems. Match each application in the EA repository to its CMDB entries, its contracts and cost lines in the finance system, and its open work in the delivery tracker. Names differ ("CRM EU", "Customer Hub"), so each match shows its evidence and confidence.
2. Find functional overlap by capability. Group applications by the capabilities they support and list where several serve the same users. Say, three CRM systems after an acquisition.
3. Flag contradictions. List every application where the systems disagree: retired in the repository but running in the CMDB, paid for but with no recorded users, active but with no owner.
4. Draft the candidate list with evidence. For each candidate, give the proposed TIME call and the records it rests on: cost, usage, lifecycle, overlap, contract dates.
5. Refuse when evidence is missing. An application with no usage data and no cost line should not get a confident Eliminate. It should go on a list of records to fix, with the gap named.

The fifth step matters most. A model that fills gaps with plausible guesses produces a list that falls apart in the first committee meeting. Test how an assistant handles missing data before you trust its list: the question kit includes portfolio questions such as retirement candidates and renewals on applications marked Eliminate.

What stays a human judgement?

Some calls depend on context no record holds.

• Business criticality. Whether a system matters at month-end close or a regulatory filing is known by the people who run those processes.
• Sequencing against change capacity. Five retirements may be sound on paper. The business may absorb two this year.
• Contracts and vendor negotiations. Notice periods, bundled licences and renewal leverage are commercial judgements.
• The final decision. Someone accountable signs off each call, and their name sits on the record.

AI can prepare each of these, for example by listing contracts that expire soon. It shouldn't make the call.

How do you make each decision traceable?

A steering committee asks one question in many forms: how do you know? Each line in the candidate list should answer it without a follow-up meeting.

For every candidate, record the source system and record id behind each figure, the date it was read, and whether it was checked against its source. Let a recommendation rest only on checked values, and mark estimates as estimates. When someone challenges a number, anyone should be able to open its record in a minute.

The same test applies to any AI involved: if it can't show which records support a call, the call isn't ready. The AI-agent governance checklist applies the same rule to agent inventories.

Which traps catch rationalisation programmes?

• The cheap duplicate that holds unique data. A small application looks redundant beside the strategic platform, but it is the only system of record for, say, broker commission history. Check what data each candidate masters before you call it a duplicate.
• Retired in the repository, still running. The replacement went live and the record was updated, but a nightly batch job on the old servers still feeds a report. Check the CMDB and recent change records, not only lifecycle fields.
• Licence cost without usage. A high licence cost looks like a saving, but without usage you can't tell a daily tool from shelfware. Cost without usage is half a fact.
• Overlap by name, not by capability. Two applications called "portal" may serve unrelated users.

A six-step method for application portfolio rationalisation

1. Fix the scope and the rules. Agree which applications are in and write the rule for each TIME call before anyone sees a candidate.
2. Reconcile the estate. Match records across the EA repository, CMDB, finance system and delivery tracker. Publish the contradiction list.
3. Close the gaps that block decisions. Send owners the records missing cost, usage or ownership. Leave the rest for later.
4. Draft candidates with evidence. Apply the rules. Every candidate carries its records, and anything without enough evidence goes on the hold list with the reason.
5. Review with the people who know. Owners and process leads test each candidate for criticality, unique data and hidden dependencies, and you record what changed.
6. Sequence and decide. Order the approved calls against change capacity and contract dates, take them to the committee, and record who decided each one.

Steps 2 and 4 are where AI saves the most time. Steps 5 and 6 are where people earn the decision.

Questions to answer before the first committee

• Does every application in scope have an owner, a cost, a usage measure and a lifecycle state?
• Where the EA repository and the CMDB disagree, which do we trust, and how do we settle it?
• Is each TIME rule written down, and could someone else apply it and get the same answer?
• For every Eliminate, do we know what data the application masters?
• Can each figure on the list be traced to a record in a minute?
• How many changes can the business absorb this year?
• Which contracts expire in the next eighteen months?

Start with the contradictions

Before you score a single application, list where your systems disagree about the estate. That list is quick to produce, hard to argue with, and shows the committee the real state of the data. It also separates the decisions you can make now from those that wait for better records. A programme that starts there argues less about opinions and acts sooner on evidence.