Cleaning up the application landscape
By Redaktion techport.ai, IT-Beratung · Last updated on
The question of how many applications are in use is almost always answered too low in mid-sized companies. The big systems get counted. What does not get counted are departmental applications, cloud services with monthly billing, self-built databases and the spreadsheets that are effectively systems because a process stops without them.
An overview of the application landscape is not an end in itself. It is the precondition for reducing cost, retiring systems, judging security and placing new requirements. Without it, every initiative starts with the same search.
How you notice it
- Asking for a list of all systems triggers a discussion about what counts as a system.
- Two areas use two different tools for the same task.
- Nobody can say which application holds which data and where copies exist.
- When a security advisory appears, checking whether you are affected takes several days.
Why this happens
Applications enter the company because a concrete problem had to be solved, often quickly and often from within a department. They do not disappear when the problem is solved or when a larger system takes over the task. Nobody owns the shutdown, it brings no visible benefit to anyone, and there is always a residual risk that someone still uses it. So the landscape grows in one direction only.
How we go about it
- Survey the inventory. We capture systems from several sources at once: contracts and invoices, network access, sign-ins in the directory service and conversations in the departments. Only the combination gives a complete picture, since every single source has blind spots.
- Reduce to a few attributes. We describe each application only with what is needed for decisions: process supported, business owner, number of users, data held, interfaces, operating model, cost, contract end and technical condition.
- Assess and name candidates. We mark duplicates, systems without an owner, systems without vendor support and those whose function an existing system already covers. From that comes a list of candidates for retirement, consolidation or cancellation.
- Anchor the maintenance. We define who keeps the overview and on which occasions it is touched, at minimum with every new purchase and every contract renewal. Without that step the work has to be repeated in two years.
What you gain
- A basis on which you can judge cost and risk per system.
- Fast answers when a vulnerability becomes known or a customer asks for evidence.
- Concrete savings candidates that require no process change.
From our projects
When we bring together contracts, network data and departmental conversations, the actual number of applications regularly turns out to be two to three times the first estimate. Part of that consists of services with small monthly amounts, individually unremarkable and significant in total. The second recurring finding is systems without a named business owner. Those systems are typically the worst maintained and the hardest to retire, because nobody feels responsible while everyone has reservations.
Häufige Fragen
Do we need a special tool for this?
For the first few years a structured spreadsheet with fifteen columns is enough, provided it is maintained. A dedicated tool pays off once you manage more than roughly a hundred applications, when several sites have their own landscapes, or when you want to analyse dependencies between systems. The tool does not solve the maintenance problem, it only makes it more visible.
How do we persuade departments to give up a tool?
Not with a cost argument but with a replacement and a plan. Anyone giving up an application wants to know how their process will run afterwards and who will do the migration. If both are answered and the data is carried over, resistance is usually lower than expected. Without answers to both, it is justified.
Let us talk about Cleaning up the application landscape
In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.
Further reading
Back to the field Architecture and Applications