Every application rationalisation starts with one thing: knowing what you actually have. A good application inventory is the foundation everything else is built on.
Every rationalisation stalls in the same place: someone asks how many applications there are and gets three different answers. Finance says 240 because that is how many software vendors they pay. IT service management says 180 because that is what has a support queue. The architecture team says 400 because they counted the databases and the spreadsheets that run departments.
All three are right, which is the problem. Until you agree what counts as an application and produce one list everyone accepts, no downstream analysis will survive contact with a steering committee.
Write the inclusion rule down first. A workable definition: a distinct piece of software that supports a business capability, has identifiable users, and would need a decision if it were switched off.
That deliberately excludes infrastructure components and shared platform services, which belong on a different register. It deliberately includes the departmental Access database keeping a regulated process alive, because switching it off would absolutely require a decision. Edge cases will still arise — modules of a large ERP, for instance. Decide once whether they are one application or several, record the rule, and apply it consistently.
The temptation is to design a 40-field schema. Resist it — the marginal field costs you weeks of chasing and rarely changes a decision. Start with what the analysis genuinely needs:
| Field | Why it earns its place |
|---|---|
| Name and aliases | The same system has three names across three departments; you will merge duplicates on this |
| Business owner | Nothing gets decommissioned without one. This is the hardest field to fill and the most valuable |
| Technical owner | Who you ask about integrations and versions |
| Capability supported | The link to your capability map; this is what makes duplication visible |
| Annual cost | Licence, support, hosting, and internal effort if you can get it |
| User count | Separates enterprise systems from departmental ones fast |
| Hosting and lifecycle status | On-premise, SaaS, version, vendor support end date |
| Criticality | What breaks if it stops. Usually already defined by your continuity register |
| Key integrations | Rough is fine; you need coupling, not a full interface catalogue |
Anything beyond this should have a named consumer who will use it in the analysis. If nobody will, leave it out.
No single source is complete, and triangulating three imperfect ones beats waiting for a perfect one.
Expect the first consolidated list to be roughly 30% larger than whatever IT believed the estate was. That gap is usually the most interesting finding of the whole exercise.
Timebox it. Pull the automated sources in week one, reconcile and de-duplicate, then spend week two filling gaps by exception rather than interviewing everyone. Accept "unknown" as a value — a field marked unknown is honest data, whereas a guessed figure quietly corrupts every calculation downstream.
Aim for good enough to make decisions, not complete. An inventory that is 85% accurate and finished supports a rationalisation; one that is 99% accurate and still in progress supports nothing.
An inventory decays roughly 20% a year through change alone. Rather than committing to continuous accuracy you cannot sustain, tie refresh to the decisions that need it: before annual planning, before a major programme, before renewal cycles.
Record when each record was last verified and by whom. A dated field lets a reader judge how much weight to put on it. An undated field of unknown age is worse than no field, because people trust it.
Once the inventory is stable, the next step is scoring it — see running a rationalisation with the TIME model and application portfolio management.
The Applications Assessment & Rationalisation Toolkit includes a data-collection template that feeds straight into the scoring calculator and TIME quadrant.
