The Application Inventory Nobody Has — How to Actually Map Your Estate in 2 Weeks

The previous post in this series argued that most enterprises are running between two hundred and four hundred SaaS applications, that the IT organisation typically knows about a quarter of them by name, and that the cost of this distributed sprawl is now the largest unaddressed cost line in enterprise IT. This post is the operational follow-on. Before any rationalisation decision can be made, the enterprise has to know what is actually in the estate. The honest inventory is the precondition for everything that comes next.

The bad news is that the inventory exercise has been attempted in most enterprises before, usually multiple times, and has consistently produced incomplete results. The CMDB is wrong because it depends on humans to keep it current, and humans do not. The TBM tools are partial because they depend on procurement data, and procurement data misses the entire shadow IT estate. The IT-led survey approach is slow because it depends on business units to self-report, and business units self-report what they remember rather than what they actually use.

The good news is that the discovery problem is now genuinely tractable in two weeks rather than two quarters. The data sources exist; they have always existed. What changed is that AI agents can fuse them into a single, queryable inventory in a way that human-driven inventory exercises could not.

Why CMDB never worked

Configuration Management Databases were invented for the data centre era. The rationale was sound: keep a single record of every server, switch, and application instance, with relationships between them, so that incidents could be diagnosed quickly and changes could be assessed for impact. In a world where the entire IT estate fit in a few racks and changes happened through a controlled change management process, the CMDB was an achievable goal.

The SaaS era broke every assumption the CMDB depended on. Applications now arrive without a change ticket. They are bought with a credit card. They onboard users through self-service. They integrate with other applications through APIs that the IT organisation never approved. By the time the CMDB process notices the new application exists, it has been in production for months. The mismatch between the speed of SaaS adoption and the speed of CMDB updates is structural; no amount of process discipline closes it.

The honest assessment

In our customer base, the CMDB's accuracy at the SaaS application layer is consistently below a third. Some applications are in the CMDB but no longer exist; many applications exist but are not in the CMDB; the application owners listed are frequently people who left the company two years ago. Treating the CMDB as the inventory is the most common failure mode of consolidation programmes — the programme commits to its conclusions before it has discovered the problem.

Why TBM tools are not enough

Technology Business Management tools improved on the CMDB by attaching cost data to the inventory. They are useful; they are also incomplete. The data they depend on — procurement records, contract repositories, license management systems — is the data the IT organisation already had before TBM existed. TBM organises this data better than spreadsheets did, and it produces useful financial visibility. It does not solve the discovery problem.

The applications TBM cannot find are the applications that were never procured through procurement. The marketing team that bought a survey tool with the corporate card and expensed it through their cost centre. The sales team that signed up for a free tier that became paid. The engineer who put a SaaS subscription on their personal AmEx and reimbursed it through expenses. None of these end up in the procurement system; therefore none of them end up in the TBM tool.

The shadow IT estate is, by definition, invisible to systems that depend on procurement records. In our customer base, shadow IT is consistently between thirty and sixty percent of the active application footprint. A TBM tool that excludes this estate produces an inventory that is missing the half of the problem the rationalisation programme is supposed to solve.

The four sources that actually work

The reliable inventory comes from fusing four data sources that the enterprise already has, that no individual source captures completely, but that together produce a picture far more accurate than any single source can.

1. SSO logs

The single most powerful data source. If the enterprise uses an identity provider for SaaS authentication, every application that authenticates against it is logging every login. The login record is timestamped, attributed to a named user, and unambiguous about which application was accessed. SSO logs cover the majority of sanctioned applications. They miss applications that have not been integrated into SSO, which becomes a discovery signal in itself — applications outside SSO are typically either shadow IT or candidates for SSO integration that have not happened.

2. Network telemetry

The complement to SSO. Network egress logs capture every outbound API call, every cloud SaaS endpoint, every domain that the enterprise reaches. Cross-referencing the network egress data against a database of known SaaS providers identifies applications that are in active use even when they are not SSO-integrated. This is where the long tail of shadow IT becomes visible. The application that nobody admits to using is still calling out to the vendor's API every day; the network sees it.

3. Procurement and expense records

The financial signal. Procurement records cover the formally purchased applications — the contracts, the renewal cycles, the line items. Expense reports cover the informally purchased applications — the credit-card SaaS subscriptions, the team-bought tools, the conference passes that were really annual subscriptions. Together they identify applications that someone is paying for, with attribution to the cost centre paying. The gap between “applications someone pays for” and “applications anyone uses” is the trial debris and zombie subscription category.

4. OCR'd procurement and contract metadata

The historical signal. Most enterprises have a contract repository that has accumulated thousands of documents over the years. Many of those documents are the original SaaS agreements; many of them are amendments, renewals, and termination letters. Running the contract estate through optical character recognition and structured extraction produces a historical timeline of which applications were ever signed, when they were renewed, and which were formally terminated. This is the source that catches applications that were terminated on paper but are still active in production, and the inverse — applications that are paying renewal fees on contracts that nobody can find.

The two-week timeline

The discovery exercise, when run as an agent-driven fusion of the four sources rather than a human-driven survey of business units, converges in two weeks. The shape of the work is consistent across enterprises.

Days 1-3: Source connections

Connect the four data sources. iHub connectors handle the SSO provider, the network monitoring platform, the procurement system, and the expense management platform. Activate the contract repository OCR pipeline. The data starts flowing into a unified data layer where the inventory agent can read across all four.

Days 4-7: First-pass inventory

The inventory agent runs the first-pass reconciliation. Each application gets a record with a primary identifier, the data sources that recognised it, the apparent owner, the apparent cost, and the apparent active user count. The first-pass inventory typically lands around three hundred to four hundred applications for a mid-to-large enterprise. The output already exceeds anything the CMDB has ever produced.

Days 8-10: Owner assignment

The first-pass inventory is reviewed by application owners. Pairing Rules route each application to the cost centre or business unit most likely to own it; the owner confirms or redirects. Applications with no identifiable owner are flagged as orphans, which is itself one of the most useful outputs of the exercise — orphan applications are the highest-priority retirement candidates.

Days 11-14: Function tagging and gap analysis

Each application is tagged with the business function it serves. The inventory now answers the question: how many applications are doing each major job? Multiple applications doing the same job are immediate consolidation candidates. Applications with no clear function are immediate retirement candidates. Applications with one clear function and one named owner are kept candidates pending the legitimacy diagnostic from Post 3.

What the inventory typically reveals

The first honest inventory in an enterprise that has never had one tends to surface the same set of findings.

The shadow estate

The number of applications outside SSO and procurement is consistently larger than the IT organisation expected. In our customer base it averages between thirty and sixty percent of the active application count. These applications are not all wrong — many of them are legitimate business tools that the IT organisation simply did not know about — but they are all ungoverned, which is a problem in its own right.

The duplicate problem

The number of applications doing the same job is consistently larger than expected. Three to five project management tools, two to four expense systems, four to seven design tools, multiple parallel CRMs, more than one HRIS in companies that have made acquisitions. Each duplicate has a defensible local origin; the aggregate is irrational.

The zombie subscriptions

Applications that are still being paid for despite having no active users in the last quarter. The contract auto-renewed. The original owner left. The procurement system kept paying. The honest inventory finds these on day eight; the licence-recovery savings frequently fund the rest of the rationalisation programme.

The orphan estate

Applications with no identifiable owner. Marketing applications whose original owner moved to operations. Engineering tools whose original owner left the company. The orphans are not necessarily candidates for retirement — some are doing important work — but they are all candidates for owner reassignment, which is the precondition for any future governance.

The integration map

The application-to-application integration graph is consistently denser than the IT organisation expected. The discovery process exposes that applications nobody manages are sending data to applications nobody owns through integrations nobody documented. The integration map is, in many cases, the most valuable secondary output of the inventory exercise.

How to keep the inventory current

The most common failure of past inventory exercises was that they produced a snapshot, the snapshot decayed within months, and the next exercise had to start over. The snapshot model fails because the underlying estate changes daily — new applications onboard, old applications retire, owners change, costs evolve.

The agent-driven inventory is structurally different. The four data sources stream continuously. The inventory agent re-runs nightly. Changes are flagged the day they happen rather than discovered during the next quarterly review. The inventory ages from a snapshot artefact into a living operational record — the application equivalent of the financial close, except continuous rather than periodic.

What this enables

The inventory is not the end state; it is the foundation. With an accurate, owned, costed, function-tagged inventory in hand, every subsequent rationalisation decision becomes tractable.

• The legitimacy diagnostic in Post 3 can run against named applications rather than guesses.
• The separation case in Posts 4 and 5 can be evaluated per-application against the residency and compliance constraints that apply to each one.
• The 70% diagnostic in Post 6 can identify the actual consolidation candidates rather than the suspected ones.
• The M&A integration plan in Post 7 can compare the parent estate against the acquired estate honestly, with the actual application lists rather than the asserted ones.
• The CFO case in Post 9 can model the actual savings against the actual licence and integration cost.

What to do this quarter

Closing

The inventory exercise is the first place application rationalisation programmes succeed or fail. Programmes that begin with an honest inventory have the chance to produce honest conclusions. Programmes that begin with the CMDB or the TBM tool are committing to inherited inaccuracies before the work begins.

The inventory is also one of the highest-leverage outputs the IT organisation can produce, full stop. With it in hand, the conversation with the CFO is different, the conversation with the board is different, the conversation with the business units is different. Without it, every conversation about application portfolio strategy is happening on incomplete information.

The next post walks the taxonomy — the five mechanisms by which applications accumulate, the diagnostic that separates legitimate accumulation from accidental sprawl, and the questions the inventory can now answer that no previous attempt could.

Two weeks. Four sources. The inventory you should have always had.

VoltusWave runs the agent-driven inventory exercise as the first phase of every application rationalisation engagement. iHub connectors fuse SSO, network, procurement, expense, and contract data into a unified queryable inventory in two weeks. The inventory is the foundation of every subsequent decision.

Application Consolidation · 10 posts