By Shawn Ennis | Rapax
There is a number that every VP of Engineering knows intuitively but almost nobody has written down as a single figure: the number of integration paths their environment requires.
Here is the math. If you are running five OSS/BSS platforms with full cross-integration, you have up to twenty potential integration paths. Add a sixth platform and you add five more. Add a seventh and you add six more. The number of integrations does not grow linearly with your tool count. It grows with the square of it. In computer science terms, this is O(N²) scaling — and it is the underlying reason that every expansion of your tool landscape feels exponentially more expensive than the last one.
This is not a procurement problem. It is not a vendor problem. It is an architectural problem — and it compounds silently until a vendor upgrade, an API deprecation, or a staff departure makes the full cost visible all at once.
What O(N²) Looks Like in Practice
A typical Tier 2 operator runs between eight and fifteen OSS/BSS platforms simultaneously. That is not negligence — it is the logical outcome of successive technology cycles, each one adding a platform that was best-in-class at the time of purchase. The fault management system from one era. The performance management platform from another. The ticketing integration built by a systems integrator who is no longer on retainer. The element management system the vendor stopped investing in three releases ago.
Each of these platforms has integrations. Each integration was built by someone who is probably no longer on your team. Each integration carries its own maintenance burden that surfaces every time something changes upstream or downstream.
When Platform A pushes a version update that changes its API, every integration touching Platform A must be tested, potentially refactored, and redeployed. Operators report that vendor upgrades routinely consume two to four weeks of systems integrator or internal engineering time per integration affected — not because the upgrade is complex, but because the downstream dependencies are undocumented or fragile.
When a staff member who built or maintained a critical integration leaves, the operator faces a choice between an expensive contractor engagement and a risky knowledge gap. The integration logic lives in scripts, middleware configurations, or ETL pipelines that are poorly documented and understood by a shrinking number of people. When these integrations break — and they do — the reconstruction cost is rarely budgeted for because it was never anticipated.
The financial result of this dynamic: operators routinely spend $200,000 to $2,000,000 per year on systems integrator retainers and project work just to keep legacy integrations functioning. That is before a single new integration is built. That is purely the cost of maintaining what already exists.
The Combinatorial Trap
The most dangerous aspect of O(N²) integration architecture is not what it costs today — it is how it scales with every decision you make going forward.
Every new platform you add to the environment does not add one integration. It adds a potential integration to every other platform in your environment. If you are running eight platforms and you add a ninth, you add up to eight new integration paths. If you are running fifteen and you add a sixteenth, you add up to fifteen.
This means that the marginal cost of adding a new platform — the true cost, accounting for integration design, build, testing, and ongoing maintenance — is not the license fee. It is the license fee plus the integration cost for every connection that new platform requires with every existing system. That cost is almost never included in the business case that justifies the new platform purchase. It shows up two years later as SI invoices nobody budgeted for.
It also means that rationalization has a compounding return. Every platform you eliminate does not remove one integration. It removes up to N integrations — one for every other platform in your environment that connected to it. The savings from decommissioning a single legacy tool are not linear. They are combinatorial in the same way the costs were.
The Architectural Alternative
The way out of O(N²) is not to integrate better. It is to change the shape of the problem. Instead of maintaining point-to-point integrations between N platforms — where every pair that communicates creates a unique dependency — you maintain integrations between N platforms and one. A single AI-native platform ingests data from network elements, BSS systems, and operational tools through a unified collection layer and exposes functionality through a consistent API and agent architecture.
When a vendor pushes an upgrade that changes its API, one integration adapter is updated — not every system in the environment that touches that vendor’s platform. When a new data source is added, a single collection pipeline is configured — not a new web of point-to-point connections. The integration maintenance surface shrinks from O(N²) to O(N).
This is not a theoretical architecture. It is the operating design of platforms built from the ground up on modern data pipelines, containerized microservices, and event-driven architectures — platforms where integration is a core capability, not an afterthought bolted on by a systems integrator whose engagement ended three years ago.
“Every platform you eliminate does not remove one integration. It removes up to N integrations — one for every other platform in your environment that connected to it. The savings from rationalization are combinatorial in the same way the costs were.”
The Integration Audit Worth Running
Before the next contract renewal cycle, it is worth running a simple audit. List every active integration in your environment — the source, the target, the owner, and the last time it was tested. Then count them. For a five-tool environment, you should see something between ten and twenty. For a ten-tool environment, between twenty and fifty.
Then ask: who would fix each of these if it broke today? How long would it take? What is the SI day rate for that engagement? Multiply by the realistic probability that each integration will require attention in the next twelve months — given vendor release cadences, API deprecation cycles, and staff turnover in your team.
That number is your annual integration risk budget. And it is the first number to take into a rationalization conversation.
The full integration tax analysis — what a typical mid-market operator spends annually on SI retainers and integration maintenance, and what the alternative architecture costs by comparison — is in the white paper below.
The Rationalization Window
Turning OSS/BSS Tool Sprawl Into AI-Native Savings
If any of this lands and you want to map your integration surface against the replacement math — 15 minutes at cal.com/shawn-ennis. No prep needed.
Leave a Reply