“Even a small change has to go through 5 teams and 3 weeks.”
I have heard this so many times that I no longer consider it a complaint. To me, it is a technical signal.
When a minor change to a tariff or promotion has to travel through Customer/CRM, then Sales & Inventory, and eventually touch Billing & Payment, the problem usually does not lie in team capability.
It lies in how the systems are holding hands with each other, and how each one interprets the transaction state differently.
I once ran into a very real-world case. The business team only wanted to add one more rule to sell a package. The CRM system updated customer eligibility. The sales system updated the selling logic. On the surface, everything looked fine.
But when it was time to close the period, reconciliation reports started to drift.
It was not a massive discrepancy that brought systems down. It was the frustrating kind, where some transaction groups looked correct within each individual system but became wrong when stitched together end-to-end.
Eventually, the root cause was in inventory. Some transactions had already reserved resources but had never been activated because a downstream step hit retry/timeout. Meanwhile, the billing system recognized revenue based on a completely different logic.
That night, the entire team sat there staring at logs like watching a detective movie. Each system told a story that seemed right, but there was no single end-to-end story you could actually trust.
In moments like that, many people will propose replacing the core.
But modernization in Telco, from my experience, is not about swapping an old system for a new one. Modernization is about reducing the cost of each change. It means changing faster, with lower risk, and most critically, being able to trace where and why things drift when they do.
A somewhat harsh but often accurate insight. You do not eliminate dependency. You only move it.
If you replace a large block without redesigning the responsibility boundaries between CRM, Sales/Inventory and Billing/Payment, those dependencies will return in another form. Data mapping gets more complex. The parallel run between old and new systems stretches longer. Dual operations become more exhausting.
The main bottleneck is usually not in the integration layer. It is at the transaction boundary.
Each system defines done in its own way
None of them are wrong individually. But together, they do not add up.
When that happens, errors do not die in one place. They spread through failure propagation across systems and only become visible in the most expensive places. Reconciliation. Billing adjustments. Customer complaints at the contact center.
So what is the design implication, if you do not want to stay stuck in diagnosis forever?
For Telco BSS/OSS, the transaction boundary should follow a specific business flow, typically the Order-to-Activate flow, instead of following the technical boundary of each individual system.
Instead of letting each system define its own state and hoping they line up, there needs to be a shared state backbone for the entire flow. This could be a state machine or a transaction journal that all systems refer to.
A few basic questions need clear answers before going any further.
Where is the order in the overall processing flow. Have resources been reserved. Has the service been activated. At which point is billing allowed to recognize revenue as valid. When retry occurs, who is responsible for idempotency and deduplication. And when discrepancies are found, who is responsible for compensation.
For that transaction boundary to actually matter in day-to-day operations, we need to call out something that is often underestimated. That is observability.
In this context, observability is not just about having a few attractive dashboards. What we really need is end-to-end tracing with a cross-system correlation ID that lets us answer within minutes. Where is this transaction in the CRM → Sales/Inventory → Billing/Payment chain. Is it drifting because of retry, because of data, or because of state logic.
If we cannot see through the system end-to-end, modernization easily becomes new architecture with the same blindness.
The fear of change in telecom systems usually does not come from people being unwilling to change. It comes from systems being designed so that every change is a big gamble.
If we look at it correctly, modernization is not just about refreshing technology. It is about reducing risk and friction for even the smallest change. And the first step is not redrawing architecture diagrams or replacing the core to get it over with. It is correctly naming where the real pain points are.
In the next article of the Inside Telco Systems series, I will dive into Order-to-Activate and dissect the most common source of drift. That is inventory state, especially the boundary between reserved and activated. This is where time-to-market and reconciliation costs often get burned together, yet many organizations do not realize it.
When we treat each change as a stress test for our system design, modernization becomes less about technology buzzwords and more about architectural accountability.
Follow BiPlus for upcoming articles in this series.
