Every rationalisation effort begins with the same sentence: we need a map. Six weeks later, a spreadsheet arrives. Two hundred rows, one application per row, columns for the vendor, the version, the number of users, the annual cost.
That spreadsheet is an inventory. It has its value — you cannot decide about what you do not know. But it enables no decision, because it says nothing about what matters: what breaks if you remove a row.
What an inventory does not tell you
An application has no cost in isolation. It has a cost, dependencies and a place in a chain. The inventory captures only the first:
- which business processes stop if it fails, and for how long
- which other applications call it, and by what means
- which data it holds itself, and which it copies from elsewhere
- who knows how to keep it running — and what happens the day that person leaves
Those four answers are what separate a list from a map. They are in no register: they are gathered from the people who use the tool every day.
The dependency you only see by cutting it
In most systems built up by accretion there is at least one link nobody can fully describe: an overnight export, a file dropped on a shared drive, a macro inherited from a machine that no longer exists. It works, so it is invisible.
The first merit of a serious map is making those links visible before a project breaks them. It is also the cheapest moment to deal with them.
An inventory tells you what you own. A map tells you what you risk by touching it.
The useful level of detail
The opposite mistake is trying to model everything. An exhaustive map is expensive, goes stale within months and stops being maintained the moment the supplier who produced it has gone.
The right level is the one that lets you decide: enough detail to keep, replace or retire an application, and no more. Which means knowing, before you start, which decisions you are preparing for.
What you then do with it
A map is worth only what it allows you to decide. Its natural sequel is a roadmap offering costed scenarios, not one more inventory.
A map is not a deliverable, it is an instrument. It feeds the roadmap, it underpins the recovery plan, it makes the case the day a vendor announces end of support. Produced without those uses in mind, it ends up in a shared folder nobody opens.
Common questions
What is the difference between mapping and inventorying an information system?
An inventory lists what the business owns; a map says what it risks by touching it. It shows which processes stop if an application goes down, which others query it, what data it holds, and who knows how to run it.
How do you build an application map?
By gathering dependencies from the people who use the tools every day: they appear in no repository. The right level of detail is the one that lets you decide whether to keep, replace or retire an application — no more.
What is a map used for once it exists?
It is a tool, not a deliverable. It feeds the IT master plan and its costed scenarios, underpins the recovery plan, and serves as evidence the day a vendor announces end of support. Produced without those uses in mind, nobody opens it again.