OSS and BSS are coupled by history
Interfaces built for products long withdrawn still constrain how new ones can be defined, so launching a product touches systems that have no business reason to be involved.
Technology consulting for telecommunications operators
Telecommunications is where enterprise software meets genuine scale. Event volumes are large enough that architectural choices which are immaterial elsewhere become the dominant cost, and availability is measured in minutes per year rather than percentage points.
Industry overview
An operator's estate divides into systems that run the network and systems that run the business, and the boundary between them is where most of the complexity lives. Provisioning, assurance, mediation, rating, billing and customer management each evolved separately and are connected by interfaces built for products that may no longer exist.
Scale is the second defining property. Event volumes from a network are orders of magnitude beyond typical enterprise workloads, which means retention decisions, aggregation strategy and per-event processing cost are architectural concerns rather than tuning details.
The third is availability. Customers notice an outage immediately, regulators take an interest, and there is no window in which the network stops. Our work is usually about reducing coupling between OSS and BSS, making the data volumes economical, and enabling change without an operational pause.
Business challenges
What operators bring to us most often.
Event volume drives cost more than logic
At network scale, per-event processing and retention decisions dominate the bill. Choices that are immaterial in other sectors become the architecture here.
Provisioning failures surface as customer problems
An order that partially completes leaves a customer in a state no system fully describes, and reconciling that is manual and slow.
Availability leaves no maintenance window
The network does not stop, so change has to be made to systems in active use, under scrutiny, with immediate customer visibility if it goes wrong.
Billing disputes are expensive to resolve
Where rating and mediation cannot be traced end to end, each dispute requires an investigation and the cost of resolving exceeds the amount disputed.
Product change is slow relative to the market
A new tariff or bundle requires change across catalogue, rating, provisioning, billing and care, each on its own cycle, so lead time is the sum rather than the maximum.
Digital transformation challenges
OSS/BSS transformation is among the largest programmes in enterprise technology and has a well-earned reputation for overrunning. The cause is usually scope: replacing several coupled systems at once produces a programme with no independently deliverable increment.
The approach that works more often is to establish a product catalogue and an order model that the existing systems consume, then move capability behind that boundary progressively. It delivers time-to-market improvement early and makes the eventual replacement of any individual system a smaller decision.
- A stable product and order model established before any system is replaced
- Capability moved behind the boundary progressively, not in a coordinated cutover
- New products launched on the new path while existing ones remain undisturbed
- Each increment reversible, because customer-visible failure is immediate
Regulatory considerations
Operators carry licence obligations covering service availability, quality reporting, lawful interception and number portability, alongside customer data protection under the Digital Personal Data Protection Act. Several of these are functional requirements of the systems rather than policies applied to them.
Subscriber data is particularly sensitive because communications metadata is revealing even without content. Retention periods are frequently set by obligation rather than by business need, which makes the volume question a compliance question as well as a cost one.
We advise on technical design and evidence architecture. We do not provide legal or regulatory opinions, and we do not represent NG&NR as holding certifications it has not been awarded.
- Retention periods driven by obligation and implemented, not left to platform defaults
- Quality and availability reporting derived from the estate rather than assembled
- Subscriber metadata treated with the sensitivity its revealing nature warrants
- Access to subscriber data logged in a form that answers a regulatory question
Enterprise architecture approach
The architectural decision with the widest effect is where the product catalogue lives and which systems are permitted to define product behaviour. Where product definition is spread across catalogue, rating and provisioning, every product change is a multi-system release.
The second is order orchestration. A telecom order is a distributed transaction across systems that fail independently, and the architecture has to represent partial completion explicitly rather than treating it as an error state to be cleaned up by hand.
The third is that scale forces decisions early. Aggregation, sampling and retention strategy determine the cost curve of the whole estate, and retrofitting them once volumes have grown is considerably harder.
- One authoritative product catalogue that other systems consume rather than duplicate
- Partial order completion represented explicitly, with defined compensation
- Aggregation and retention strategy decided before volume makes it expensive
- Degraded-mode behaviour defined per channel when a downstream system is unavailable
Cloud strategy
Network functions and business systems have very different cloud positions. Business support systems benefit from elasticity and managed services in the usual way; network-adjacent workloads carry latency, locality and regulatory constraints that frequently keep them where they are.
The strongest early cases are usually analytics, customer-facing channels, and the elastic ingestion of event data — which is also where the cost model most rewards paying for peak rather than provisioning for it.
Non-production environments deserve a mention of their own. Operators typically maintain several, sized for realistic volume because testing at smaller scale is misleading here, and running them continuously is a cost that elastic capacity removes almost entirely.
- Business support and network-adjacent workloads assessed separately, not as one estate
- Elastic ingestion for event volumes that vary by hour and by campaign
- Locality and latency constraints stated precisely rather than as general concerns
- Cost modelled per subscriber and per event, since both drive the curve
Data strategy
Telecom data engineering is defined by volume economics. The same pipeline design that is fine at enterprise scale becomes unaffordable at network scale, so aggregation strategy, storage tiering and what is genuinely queried are decisions with immediate financial consequence.
The second problem is subscriber identity across products, channels and acquisitions. Operators frequently hold several representations of the same customer, and until one is authoritative, churn analysis and lifetime value carry an error nobody can quantify.
Product reference data is the third. Where tariffs, bundles and promotions are defined differently in catalogue, rating and reporting, analysis of product performance compares things that are not the same thing — and that is rarely visible in the output.
- Aggregation and tiering designed against query patterns that actually exist
- One authoritative subscriber identity across products, channels and acquisitions
- Retention split between obligation-driven and business-driven, priced separately
- Quality tested at ingestion, because reprocessing at this volume is expensive
Security considerations
Operators are critical national infrastructure and are targeted accordingly, by capable adversaries with specific objectives rather than opportunistic ones. Subscriber data and network control are both high-value targets and warrant different defences.
The breadth of the estate is the practical difficulty. Retail channels, partner systems, roaming interconnects and a large supplier population all have access of some kind, and access granted per relationship accumulates into an attack surface nobody has enumerated.
- Network control and subscriber data protected as distinct problems
- Partner, dealer and interconnect access inventoried, scoped and time-bound
- Privileged access to provisioning and rating separated by duty and recorded
- Detection scenarios derived from the threat model rather than from tool defaults
Software engineering
Engineering at telecom scale rewards simplicity in the hot path. A per-event cost that is negligible in isolation becomes the dominant line item at volume, and that constraint shapes design choices that would be free elsewhere.
The absence of a maintenance window is the second constraint. Deployment has to be independent of availability, which means backward-compatible interfaces, instance-by-instance replacement and a rollback that has been verified rather than assumed.
- Hot-path simplicity treated as an economic requirement, not an aesthetic one
- Deployment independent of availability, with verified rollback
- Backward-compatible interfaces, because systems upgrade on different cycles
- Load testing at realistic volume, since behaviour at scale is not extrapolated
Integration strategy
The OSS/BSS boundary carries the most consequential integration in the estate, and it is usually the least deliberately designed — accumulated over years of product launches, each adding a connection for a specific need.
Partner and interconnect integration adds externally-set contracts that change on someone else's timetable. Version tolerance and explicit failure behaviour are structural requirements there rather than refinements, because you cannot negotiate a rollback with a roaming partner.
- A designed OSS/BSS contract rather than an accumulated set of connections
- Idempotent, order-tolerant processing across provisioning and mediation flows
- Externally-set contracts handled with version tolerance and explicit failure paths
- Reconciliation between provisioning, rating and billing designed as part of the flow
Recommended NG&NR services
The services usually engaged first in this sector, and why.
Enterprise Architecture
Where the product catalogue lives, how orders orchestrate across systems that fail independently, and what the OSS/BSS contract should be.
AI & Data Engineering
Volume economics: aggregation, tiering and retention priced deliberately, and one authoritative subscriber identity.
DevOps & Platform Engineering
Deployment independent of availability, with verified rollback, in an estate with no maintenance window.
Cloud Consulting
Assessing business support and network-adjacent workloads separately, and elastic ingestion for event volume.
Cybersecurity
Network control and subscriber data as distinct problems, and the partner and interconnect access nobody has enumerated.
Software Development
Hot-path services where per-event cost is the dominant economic constraint.
Recommended technologies
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
Java
Where much OSS/BSS and mediation software is built, and where high-throughput processing is practical to modernise.
Kubernetes
Independent release cadence and horizontal scale for the services around the core, with no operational pause.
Databases
Where volume economics are decided. Tiering and retention design here sets the cost curve of the estate.
Python
Event pipelines, subscriber identity resolution and the analysis that informs aggregation strategy.
AWS
Elastic ingestion and managed event services at volumes that vary by hour and by campaign.
Google Cloud
Where analytical workloads over very large event volumes are the deciding factor.
Delivery approach
How an engagement runs at network scale, with no window.
Free first consultation
Your estate, your volumes, and whether the constraint is OSS/BSS coupling, data economics or release process.
Assessment against the running estate
Where product definition actually lives, how orders fail, and what the event volume genuinely costs to process and retain.
Obligation and volume mapping
Licence obligations, retention requirements and real volume profiles recorded as hard inputs before design.
Target architecture and sequencing
Product catalogue placement, order orchestration and increments deployable without an operational pause.
Delivery with your teams
Your engineers implement while we review design and validate behaviour at realistic volume rather than extrapolated.
Handover
Runbooks, decision records and cost models, so volume growth remains predictable without us.
Frequently asked questions
Rarely as a single programme. Replacing several coupled systems at once produces a programme with no independently deliverable increment and no safe stopping point. Establishing a stable product catalogue and order model that the existing systems consume, then moving capability behind that boundary, delivers improvement earlier and with far less exposure.
Because the lead time is the sum of every system's release cycle rather than the longest one. Where product definition is spread across catalogue, rating, provisioning and billing, each has to change and each has its own cadence. The improvement comes from consolidating product definition, not from working faster.
Usually aggregation and retention rather than subscribers. At network scale, storing every event at full resolution for a period set by platform default rather than by obligation or query pattern is the dominant cost — and it grows with traffic, not with customers.
By representing partial completion explicitly and defining compensation, rather than treating it as an error to be cleaned up manually. A telecom order is a distributed transaction across systems that fail independently, so partial states are normal and should be modelled.
Yes, and at this scale you have to. It requires backward-compatible interfaces, instance-by-instance replacement and a rollback that has been verified rather than assumed. The absence of a window is an argument for better deployment engineering, not for less frequent change.
Traceability from event through mediation and rating to the invoice line. Where that trace exists, a dispute is a query; where it does not, each one is an investigation. It is also the same capability a regulator asks for, so it is rarely wasted work.
Split it: retention driven by obligation is not negotiable and should be priced as compliance, while retention driven by business use should be justified by query patterns that actually exist. Conflating the two is how operators end up storing everything indefinitely.
For business support systems, analytics and channels, generally yes. For network-adjacent workloads, latency, locality and regulatory constraints frequently keep them where they are. Assessing them as one estate produces a position that fits neither.
It matters most where the analysis is commercially consequential. Churn modelling and lifetime value both depend on knowing that two records are the same person, and until one representation is authoritative, those figures carry an error nobody can quantify — which is worse than a known one.
At realistic volume, because behaviour at scale is not reliably extrapolated from a smaller test. Contention, queueing and per-event cost all behave non-linearly, and the point at which they do is exactly the thing worth knowing.
We do not name clients or publish case studies in any sector. The first consultation works through the reasoning on your own estate and volumes, which is a better test of judgement than a reference list.
Frequently because tariffs, bundles and promotions are defined differently in catalogue, rating and reporting, so the analysis compares things that are not the same thing. It is a reference data problem rather than an analytical one, and it is rarely visible in the output — which is what makes it persistent.
Next step
Discuss a telecom estate
A free first consultation covering your OSS/BSS position, your event volumes and what they actually cost, and whether the constraint you are experiencing is coupling, economics or release process.
No cost, no obligation. Pricing is transparent and includes GST.