Why BSS/OSS should not be replaced — build the growth layer around the core

Three years, two million dollars and a box that never went live

Modernisation programmes at large operators in the region tend to follow the same script. The operator announces a billing replacement programme. A vendor is selected, milestones are agreed, parallel run begins. Two years later the parallel does not converge. The old system is running, the new system runs only on paper, the business says “we cannot switch, we will lose quarterly reporting”. The programme is renamed, the budget grows, then it quietly gets closed and the team returns to point modernisation.

This story repeats not because vendors are bad. It repeats because billing and OSS in a large operator are not a “system” — they are the reflection of a thousand configured business rules, historical exceptions and operational memory of the team. Replacing such a system means rewriting that operational memory, and that almost always takes longer than any initial plan.

The alternative path is different. Do not replace the core; build a layer next to it where products, events, rules and partners live. This layer is called around-core architecture, and in most cases it covers 70-80% of the digital growth needs without touching the system that handles the money.

Where the idea of a growth layer comes from

A discussion about replacing BSS/OSS usually begins with a correct observation. The current system does not emit events in real time. The product catalog is hard to change. Launching a new tariff takes months. Integrations with the app, contact centre and partners run through nightly batch loads. All of that is true.

But from the correct observation an incorrect conclusion is drawn: “therefore we need a new system”. The correct conclusion is different: “therefore we need modern interfaces, events and rules — but not necessarily instead of the core, possibly above it”.

Technically the picture looks like this. An API gateway accepts requests and exposes the core through a stable contracts layer. An event collector captures every meaningful customer state — top-up, activation, tariff change, support contact — and emits them in real time. A product catalog describes offers and tariffs in a machine-readable form, separate from how they are stored in billing. An offer engine decides which offer goes to which customer in which channel. Reconciliation matches consumption with billing and payments. An audit trail records who did what. Observability shows the work of the whole stack on a single screen.

Each of these components is implemented as a separate service. They integrate with the core through stable interfaces. The core itself continues to do what it was designed to do — customer accounting, rating, charge calculation, invoicing. Without it, nothing works; but it does not need to be replaced as long as it does that work correctly.

What systems are in the picture

Roughly ten years ago a typical operator ran 3-5 key systems. Today any large operator has 15-25 integrated components, and a substantial part of digital growth issues are born at the seams between them.

In the around-core perimeter the realistic set looks like this. The core BSS handles subscriber, tariffs, rating, charging and billing. OSS handles network and provisioning. CRM stores contacts and service history. The app backend supports application functionality. The contact centre uses data from core and CRM. The dealer portal serves the retail network. The DWH/CDP stores historical data. The campaign system sends communications. Payment integrations connect to banks and payment providers. Fraud monitoring watches for anomalies. Finance reconciliation matches the money.

Around this zoo, the growth layer is built: API gateway, event layer, decision engine, observability. This is not seven new systems — it is a normalising and orchestrating layer above what already exists.

Where the architecture breaks in practice

Architecture diagrams are easy to draw. Implementation breaks in three typical places.

First — data. The customer has five different identifiers in five systems and they do not reconcile. The same subscriber has ID 1234567 in core, 78910 in CRM, a UUID in the app, a historical key in the DWH. Master data management sounds boring, but without it any around-core layer becomes a set of assumptions. Data merges from different sources, but making decisions on that data is dangerous because it is unclear whether you are looking at one customer or two.

Second — events. Billing and OSS were designed as batch systems. They can produce a daily report; they cannot emit a real-time stream. To get an event-driven layer, the operator either has to embed CDC (change data capture) into the core or place an event collector that emits events in the moment they happen. This is investment into the core, but small compared to replacement.

Third — rules. In most operators, business rules (eligibility, suppression, frequency caps) live as SQL queries inside the campaign system or as code in marketing modules. For the around-core layer to function, these rules must be lifted into a decision engine as first-class objects with versioning, tests and audit. This is the work of systematising what has been written in different places over the years.

Approaches and trade-offs

There are three approaches to integrating the growth layer with the core.

The first — embed new functionality directly into the core. It looks like the most direct: one system, fewer integrations. In practice it has two large drawbacks. It slows down any change because everything is bound to billing. And it raises risk because a bug in a new product can take down the core that handles charging.

The second — build a separate layer over the core. A stable API between core and the layer, events through CDC or an event bus, decision engine as a separate service. The downside is integration complexity and the operational load of maintaining interfaces. The upside is independent speed of development: products in the around-core layer ship quickly while the core stays stable.

The third — buy a vertical solution that handles a specific scenario end-to-end. For example, an off-the-shelf wallet or offer engine from a vendor. The downside is vendor lock-in, a new silo and additional integration. The upside is a fast minimum viable product launch.

In most cases at operators in the region, the second approach wins. The first ends up paralysing speed in practice. The third is fine for pilots, but it must be approached with the understanding that the vertical solution will need either deeper integration or replacement after 18 months.

Risks, dependencies, constraints

The risks of around-core architecture are real and worth discussing in advance.

Financial error. If the decision engine produces an offer with the wrong calculation, the damage can scale fast — until reconciliation catches it, the offer goes out to every eligible customer. Defence: mandatory staging, frequency caps, manual approval on large campaigns.

Privacy. The around-core layer works intensively with personal data. Each use of data beyond the operator’s contractual obligation requires explicit consent. The Uzbek personal data law requires a clear processing purpose. Without consent management, the growth layer can become a source of regulatory issues.

Fraud. The wider the exposed API surface, the larger the attack surface. Dealer portal, partner API, app backend — every integration point can potentially be abused for repeated promotional codes, fictitious activations, rule bypasses.

Vendor lock-in. If the decision engine is bought from a vendor without source code rights and without configuration portability, migration becomes expensive within a few years. Data portability and access to configuration files are critical clauses in the contract.

SLA. The growth layer must operate at least at the level of the core. If it goes down, sales stop. This requires HA architecture, monitoring and on-call discipline.

When core replacement is in fact justified

The around-core approach is not always right. There are conditions under which billing replacement is the only realistic path.

First — when the core is so outdated that the vendor no longer supports it and any change requires manual coding by people who still remember how it works. In that situation the around-core layer is being built on air — every change in the core risks breaking the entire layer.

Second — when the billing model is structurally incompatible with new products. For example, the operator wants to launch subscription-based bundles with dynamic pricing, while the core supports only flat tariffs with fixed rules. This is not an integration question, it is a structural mismatch.

Third — when compliance requires functionality that the core does not have, and that cannot be added for architectural reasons. For example, new real-time reporting requirements that batch billing physically cannot deliver.

In these three cases replacement is justified, but even here the right pattern is the strangler approach. Phased migration of products from old billing to new, with rollback options, no big-bang.

A growth-layer roadmap over 18 months

The first 90 days — diagnostic and base infrastructure. A catalogue of systems and interfaces, a master data plan, a basic API gateway, events for one or two pilot use cases.

The next 90 days — the first product. One offer engine use case, one customer journey end-to-end, a dashboard with the pilot’s economics.

By month 9 — expansion. A second and third use case, partner integration, observability across the whole stack.

By month 12 — operating model setup. Who makes decisions, who carries P&L, how conflicts between marketing and support are resolved.

By month 18 — scaling. The decision engine handles the main flow of communications, the partner platform works with 5-10 partners, finance reconciliation is closed end-to-end.

This roadmap is flexible. The key rule — do not try to do everything in parallel. At each stage one dominant task is chosen, the rest run in the background.

When not to build around-core

If the operator has fewer than 500,000 active subscribers, investment in an around-core layer may not pay back. Simple core modernisation plus CRM can cover the needs.

If the team has no architect with real event-driven architecture experience, the project will become a set of disjointed integrations without unifying logic. Such a person is hard to find; without one, do not start.

If the business strategy is undefined and it is unclear which products will be launched in the next two years, the around-core layer is too early — the layer is designed against products, not the other way around.

If the budget does not include 18-24 months of continuous work and 15-20% of capex as annual operating cost, the project will not survive long enough for the investment to pay back.

Reference architecture

The minimum set of components looks like this. An event collector receives changes from the core and CRM in real time. An API gateway provides a stable public interface. A customer profile service holds the composite profile. A decision engine applies rules and makes decisions. A channel orchestrator dispatches to the right channel — push, SMS, email, app. Reconciliation matches contributions of different systems. Observability shows where the delays are. An audit log records every decision and action.

This is the minimum. A real programme can have more components — campaign manager, offer catalog, consent service, fraud detector — but these seven are mandatory.

How SamaraliSoft can help

BSS/OSS Around-Core Architecture Blueprint — not “let’s draw a diagram”. A comparative analysis of three modernisation options with concrete economics for each, a target architecture with five to seven mandatory components adapted to the operator’s situation, an honest assessment of whether core replacement is realistic (sometimes it is the right answer), and a first 18-month roadmap with measurable checkpoints. The decision on what and when stays with the operator; our role is to remove illusions and offer a fact-based choice.

Related reading

• /en/insights/telecom-growth-after-connectivity/ — where operators look for growth in 2026-2035
• /en/cases/telecom-subscriber-360/ — a real around-core architecture case
• /en/insights/telecom-event-driven/ — events as the foundation
• /en/insights/telecom-vendor-lockin-bss/ — recognising vendor lock-in before contract

Sources

• Digital Government Portal — state of digital infrastructure UZ
• Ministry of Digital Technologies — telecom segment
• UzTelecom — abonent self-service interface