The Rationalization Window
Turning OSS/BSS tool sprawl into AI-native savings.
Every operator knows they run too many systems. Almost none of them consolidate, and the reason is not inertia — it is that for most of the last two decades there was nothing to consolidate onto. That has changed, and the period during which it is straightforward to act on is not open indefinitely.
How did you end up with fifteen platforms?
Not through negligence. A typical Tier 2 or Tier 3 operator runs somewhere between eight and fifteen distinct OSS/BSS platforms, and every one of them arrived with a business case attached.
Networks do not evolve in clean waves; they accumulate. Copper, then coax, then fibre, then DSL, then 3G, 4G, 5G, now XGS-PON — each wave bringing its own vendors, element managers, data models, and integration requirements. Acquisitions add more. The result looks less like an engineered system than a geological formation: layer on layer, each stratum requiring different tools to read.
Each platform was best-in-class when it was bought. That is precisely why removing any one of them has always been hard to justify individually.
Why didn’t consolidation happen before?
Because consolidation requires something to consolidate onto, and the candidates never worked.
Suite replacement meant a multi-year programme with a migration risk profile no operations leader wants to own, and it usually ended with the new suite sitting alongside the old tools rather than replacing them. Middleware and integration platforms reduced the cost of connecting systems without reducing the number of systems — you still ran fifteen platforms, now with a sixteenth to manage the connections. Building internally worked until the engineer who built it left.
What all three share is that they treated the symptom. The underlying problem is that no two of those platforms share a data model, so nothing correlates across the boundary between them and a human has to stand in the gap. That human is the integration layer, and no amount of tooling removes them.
What actually changed?
Two things, and they arrived close enough together to matter.
The first is that a single system can now hold fault, performance, topology, and service management against one data model — which is what makes cross-vendor correlation possible at all rather than a per-vendor exercise repeated fifteen times. The platform page covers the architecture.
The second is that the work sitting between those systems — reading alarms, assembling context, answering the support contact, updating the ticket — is now work that agents can own rather than work that requires a person to be the connective tissue. That is the part that changes the economics, because it is the part that was previously irreducible.
What does rationalisation actually save?
Licence cost is the visible line and usually the smallest one. The costs that matter are the ones spread across the organisation and attributed to nobody in particular.
Every platform carries an integration maintenance obligation that recurs annually and never depreciates — vendor upgrades require re-testing, API deprecations require emergency remediation, topology changes require reconfiguration. Every platform has its own upgrade cycle consuming a maintenance window and a weekend. Every platform adds to the surface area a new engineer has to learn before they are useful, which lengthens ramp time in an environment where experienced staff are already scarce. And every boundary between platforms is a place where an event can be visible in one system and invisible in another.
The saving is not primarily a licence you stop paying. It is engineering capacity you stop spending on holding the current state together.
Why is there a window rather than just an opportunity?
Three clocks are running, and they are not synchronised to your convenience.
Contract cycles. Consolidation is dramatically cheaper when a platform is approaching renewal than when you are eighteen months into a three-year term. Those dates are known, they are spread across your portfolio, and the number of them that align in any given year is small.
Knowledge. The engineers who understand why the integrations were built the way they were are the ones retiring or being recruited away. Consolidating while they are still available to explain what a system actually does is a materially different project from reverse-engineering it afterwards.
Accumulation. The stack does not hold still while you decide. Every quarter of deferral adds another integration point, another vendor, another dependency — which means the same decision costs more to execute next year than this year, every year.
How do you actually approach it?
Not as a rip and replace. That is the version that fails, and it fails for the same reason suite replacement always failed.
The workable sequence is additive first. Bring the assurance layer in alongside what you run today — ingest is additive, so nothing gets switched off to find out whether it works. Prove correlation against your own network with your own data. Then retire systems one at a time as their renewal dates arrive, each decision made on evidence rather than on a business case written eighteen months earlier. That way no single step carries programme-level risk, and you can stop at any point having already gained something.
Where does this go wrong?
Three places worth naming before you start.
Consolidation is political before it is technical. Systems have owners, and ticketing in particular is usually the most entrenched platform in an operator. That is a real constraint on sequencing rather than an objection to argue past.
Topology quality bounds the outcome. Correlation across vendors depends on an accurate picture of what connects to what. If your inventory is wrong, the consolidated system will be wrong in exactly the same places — and reconciliation is a prerequisite phase you should budget for rather than discover.
Savings do not land on the software’s timeline. A licence retires when a contract ends, not when a replacement goes live. Any model showing the full saving in year one is a model to distrust, including one from a vendor.
Get the white paper
The full paper works through the consolidation case in detail, including how to assess your own stack and how to sequence the decision against your existing contract calendar.
About Rapax
Rapax is an AI-native network service assurance and automation platform for telecom operators, bringing fault, performance, topology, and service management into one system worked by six AI agents. It deploys on Kubernetes in cloud or on-premise environments, including local model inference. Rapax is a business unit of Citus Technologies, LLC.
Shawn Ennis is the Founder & CEO of Citus Technologies and the founder of Rapax. He spent 25 years in telecom operations, holds 12 patents in network management and service assurance, and previously founded Assure1 — acquired by Oracle in 2021.
Not ready to download? Book fifteen minutes — no prep, no deck. cal.com/shawn-ennis · sales@rapax.app · More white papers