The Five Reasons You Have So Many Apps (and Which Ones Are Legitimate)
Application sprawl is not one problem. It is five problems with one symptom. Each accumulation mechanism has a legitimate version and an accidental version. The diagnostic that separates the two is what determines whether your rationalisation programme produces savings or destroys value.
Once the inventory exercise from the previous post is complete, the next instinct is to start retiring applications. This is the moment most rationalisation programmes go wrong. Retiring an application without understanding why it arrived is the easiest way to break a business process that nobody documented. The application that looks like dead weight may be the only thing holding together a workflow the IT organisation never knew existed.
The discipline that prevents this failure mode is taxonomy before action. Every application in the inventory arrived through one of five mechanisms. Each mechanism has a legitimate version that produced an application the enterprise should keep, and an accidental version that produced an application the enterprise should retire. The two versions look similar from the outside; the diagnostic is what separates them.
This post walks the five mechanisms in detail and gives you the diagnostic test for each.
1. Acquisitions
The largest single source of net-new applications in most enterprises that have completed any M&A activity. Every acquired company brings a complete IT estate, and every estate brings applications the parent company did not have, did not vet, and did not plan for.
The legitimate version
The acquired company is in a different vertical, a different geography, or a different regulatory regime. Its applications were correct for the business it was running. Forcing a consolidation onto the parent estate would either destroy the operational capability that justified the acquisition, or fail compliance obligations the acquired entity was meeting before the deal. In these cases, the acquired applications stay, governance is established, and the rationalisation question becomes how to operate across the two estates rather than how to merge them.
The accidental version
The acquired company was running tools the parent company already had better versions of. The integration plan promised to consolidate. The integration plan was deprioritised after the deal closed because the next deal arrived, the political cost of forcing migration was high, or the synergy ROI did not survive contact with operational reality. Five years later, the parent company is still running both estates. Both are paid for. Both are integrated nowhere. Neither is governed.
The diagnostic
2. Shadow IT
The category that gets the most attention and the least nuance. Shadow IT is the universal scapegoat in IT governance conversations, and the universal scapegoat is wrong. Shadow IT is a symptom, not a cause. It exists because IT was too slow to deliver something the business needed.
The legitimate version
The marketing team needed a customer survey tool. The IT roadmap had survey tooling scheduled for the following fiscal year. The marketing team made the rational decision to buy a SaaS survey tool through marketing budget, get the work done, and move on. The application is delivering real business value. The cost is reasonable. The only problem is that nobody told IT it existed. Sanctioning the application, formalising procurement, and integrating it into SSO is the right answer — not retiring it.
The accidental version
The marketing team needed a customer survey tool. The IT-sanctioned platform already supported customer surveys. The marketing team did not know, or preferred the alternative tool because it had nicer charts, or signed up for the alternative because someone in the team had used it at a previous company. The duplicate creates parallel data, parallel licence cost, and parallel security exposure. Retiring it and consolidating onto the sanctioned platform is the right answer.
The diagnostic
3. Departmental sprawl
The pattern where each business function builds its own “best-of-breed” stack. Marketing has its preferred suite of tools. Sales has its CRM and four enablement add-ons. Finance has the ERP and a handful of specialist tools. The pattern is not malicious; specialist tools genuinely do specialist things better than general-purpose tools. The pattern is uncoordinated.
The legitimate version
The function genuinely needs the specialist tool because the alternative is materially worse. The legal team needs contract lifecycle management; a generic document repository does not do contract clause comparison or obligation tracking well. The procurement team needs supplier risk monitoring; the ERP does not do real-time risk scoring against external data. These are real specialist requirements that justify a real specialist tool.
The accidental version
The function bought a specialist tool because the head of the function had used it at a previous company, or because the vendor sales rep got there first, or because the team wanted “our own tool” for status rather than capability. The specialist tool overlaps with capability the enterprise already has. The cost is duplicate; the operational benefit is marginal; the integration burden is real.
The diagnostic
4. Vendor expansion
The escalation pattern where a small commitment becomes a large one over time without any single decision authorising the escalation. A team starts with a free tier. The free tier proves useful. Premium features get added. The bill grows. Each step in the escalation is locally rational; the cumulative result is a meaningful enterprise dependency that was never approved at the level the spending now justifies.
The legitimate version
The escalated tool is doing real work that justifies the cost. Each escalation step delivered measurable value. The current state is the right tool for the use case at the right price. The only governance gap is that nobody re-evaluates the relationship at the new spend level. Fixing the governance is the right answer; retiring the tool is not.
The accidental version
The escalated tool is paying for capability the team does not actually use. Premium features were added because they came in a bundle. The number of seats has grown to match the team size rather than to match the actual users. The annual renewal happens automatically. The honest audit shows that the enterprise tier is delivering free-tier value at enterprise prices.
The diagnostic
5. Org-change debris
The category that has no legitimate version. Org-change debris is what happens when applications survive their owners, their use cases, and sometimes their stated purpose. The original owner left the company. The original use case ended. The reorganisation moved the function elsewhere. The application kept running because nobody had the authority to turn it off.
The legitimate version (rare)
The application was originally bought for a use case that ended, but it has since been adopted by a different team for a different use case, and is now delivering real value to that team. This case exists; it is rare; and it should be treated as a fresh procurement and re-justified at the new use case's price point. If the new team would not buy the tool today for their use case, the application is debris.
The accidental version (almost always)
The application is running because nobody turned it off. The original owner left. The licence renews automatically. The cost centre that pays for it has changed names twice. The honest investigation shows that the active user count is small, the use case is unclear, and the operational value is hard to articulate.
The diagnostic
The combined diagnostic
For every application in the inventory, the rationalisation programme runs the same five-question diagnostic.
- Acquisition origin: if standalone today, would this still be the right tool for that business? Yes → legitimate; No → consolidation candidate.
- Shadow origin: does the sanctioned alternative actually meet the use case? Yes → consolidate; No → sanction.
- Departmental origin: name the specific capability the alternative cannot deliver. Concrete answer → keep; vague answer → retire.
- Vendor expansion origin: at the current price, would you buy this today? Yes → keep; No → downgrade or retire.
- Org-debris origin: who would object if it were retired in 30 days? Nobody identifiable → retire; small team → re-justify at today's use case.
What this typically produces
The honest application of the diagnostic, on a typical 300-application estate, produces a roughly consistent breakdown.
- ~15% legitimate-keep — the applications the enterprise should keep regardless of consolidation strategy. Genuine specialist tools, sanctioned shadow IT, properly-escalated vendor relationships, well-justified acquired estates.
- ~15% legitimate-separate — the applications that must stay separate for residency, compliance, or sovereignty reasons. Posts 4 and 5 cover this category in detail.
- ~70% consolidation candidates — the applications that fail at least one diagnostic. Post 6 walks how to triage this category into retire / merge / replace.
The 70/30 split is not a precise number; it is a pattern. The exact ratio varies by industry, geography, and the maturity of previous governance attempts. What is consistent is that the legitimate-keep category is far smaller than IT organisations initially assume, and the consolidation candidates are far larger.
What to do this quarter
Step 2: run the five diagnostic questions per application. Document the answers. The documentation matters when the rationalisation conclusions are later challenged.
Step 3: bin the applications into the three buckets — legitimate-keep, legitimate-separate, consolidation candidate. Resist the urge to expand the legitimate-keep bucket beyond what the diagnostic supports.
Step 4: for legitimate-keep applications, formalise governance. Owner assigned, procurement formal, SSO integrated, security review complete. The application stays; the chaos around it ends.
Step 5: hold the consolidation-candidate bucket for the next phase. The next post in the series walks the legitimate-separate cases in depth before we get to the consolidation work in Posts 6, 7, and 8.
Closing
The taxonomy matters because the wrong answer in either direction is expensive. Retire too aggressively and you destroy operational capability and produce the next round of shadow IT. Keep too generously and the rationalisation programme produces no savings, the credibility of the next initiative is damaged, and the sprawl that motivated the work continues to accumulate.
The diagnostic gives you the discipline to be neither generous nor aggressive — just honest. Each application gets evaluated against its origin, its current value, and the alternative the enterprise already has. The decisions become defensible because they are grounded in the same five questions applied uniformly.
The next post is the first of two on the legitimate-separate cluster — the cases where keeping applications separate is the right architectural answer rather than a failure of governance. Data residency, compliance, sovereignty. The post that earns trust before we make the case for consolidation.
Five mechanisms. Five diagnostics. Three buckets. One inventory that finally makes sense.
VoltusWave runs the diagnostic as part of the rationalisation engagement. Each application in the inventory gets origin-tagged, diagnostic-tested, and binned into legitimate-keep, legitimate-separate, or consolidation candidate. The decisions become defensible because they are grounded in evidence, not opinion.