OSS and BSS: Rebuilding Telcos from the Inside

A telecom company owns billions of pounds of cable, mast and spectrum, then watches the profit from all of it land in the accounts of firms that own none of it. WhatsApp carries the messages it used to charge for. Netflix fills the pipes it paid to lay. The network still matters as much as it ever did; it has simply stopped being where the money is.

Winning some of that value back means the operator has to stop running like a utility and start running like a software company. The work does not begin with marketing, and it does not begin with new 5G masts. It begins underneath, in two systems most subscribers never hear named: the OSS and the BSS.

What OSS and BSS actually do

The division is quite simple; OSS faces the network and BSS faces the customer.

OSS keeps the network alive

Operations support systems (OSS) watch the network, configure it, find the faults and fix them, and hold the operator to the service levels it has promised. The people who work in the OSS are network engineers and field technicians. When a cell tower begins dropping packets at two in the morning, the OSS is what notices.

BSS runs the money

Business support systems (BSS) handle the money and the customer: billing, orders, the product catalogue, the record of who bought what. The people who work in the BSS are sales staff, billing clerks and support agents. When your bill arrives, the BSS wrote it.

For thirty years these two halves sat apart, each in its own silo, speaking to the other through paperwork and manual handoffs. The result is something every customer has felt at least once: you order a service, the order falls into the gap between two departments, and nothing happens. Operators have a blunt word for that gap. They call it leakage, and it costs them a great deal of money.

Why the wall between BSS and OSS is coming down

The fix is to pull the wall down. When the two systems share their data and speak over proper interfaces, the handoffs vanish and the leak closes. A customer changes a plan in a self-service portal, the order travels straight to the network, and no human touches it on the way:

• The two sides stop lying to each other. Engineers see the sales forecast before they plan capacity. Marketing checks the real coverage before it promises that coverage in an advert.
• Failure becomes retention. If the OSS sees a local outage, the BSS can warn the affected customers and offer them something before they complain, or leave.
• Orders stop falling through. The provisioning that once needed three teams and a ticket queue now runs itself.

That is the whole argument in miniature. The network and the business are not two things. They are one thing, and the software should treat them as one.

The data is underneath and the AI is on top

None of this works without clean data, and most operators do not have it. Decades of mergers and bolt-on systems have left the typical telco with its facts scattered across dozens of databases that disagree with one another. Pull them into a single consistent view and the analytics climb a ladder: first reporting what happened, then diagnosing why, then predicting what comes next. The top rung is the one the industry is now reaching for, where the software no longer merely advises but acts.

The top rung: software that acts on its own

That top rung is agentic AI: a system that closes the loop without waiting for a human. Let it predict a hardware failure and, instead of raising a ticket, it orders the part, books the engineer and reroutes the traffic around the fault, all at once, before any customer notices. It is impressive when it works, and it is only as good as the data beneath it, which is why the dull consolidation has to come first. An agent fed bad data does the wrong thing faster.

5G is the reason the deadline is real

An operator could have delayed all this for years. 5G is what makes delay expensive. The real commercial promise of a proper 5G core is not raw speed but network slicing: one physical network divided into many logical ones, each tuned for a different job. That is where the enterprise money sits:

• Low latency for factories and robotics, where a late packet stops a production line.
• High bandwidth for video and live events, where the crowd all watches at once.
• Private, secure slices for healthcare, logistics and public services.
• Temporary capacity for a stadium or a transport hub, raised for the day and dropped afterward.

But a slice cannot be sold by hand. Each one has to be ordered, provisioned, measured against its promise and billed for, automatically, in minutes. That is not realistic on a legacy stack. You cannot sell 5G slices on a billing system built for last century’s products. The new revenue and the system rebuild are the same project.

The ground under all of it is the move off proprietary hardware and onto the cloud, which Software Mind has mapped in detail. Dedicated boxes become software in containers, fixed capital cost becomes elastic running cost, and the network grows for the cup final and shrinks again at midnight without anyone buying a server for the peak.

How to rebuild a system you cannot switch off

Here is the hard part. A telecom network is critical infrastructure. You cannot take it down for a weekend to change the engine. The rebuild has to happen while the thing is running, carrying live traffic, with no outage the public would notice. That alone rules out the tempting option, the big-bang replacement: it fails too often, and the failure is too public to survive.

The method that works instead carries an odd name, the Strangler Fig pattern, after the rainforest vine that grows around a tree, slowly, until it has replaced the tree and the original rots away unmissed. In software it runs like this:

• Put a façade in front of the old system. Every request passes through it. At first the façade simply forwards everything to the legacy monolith, changing nothing.
• Rebuild one capability at a time. Take a single function, prepaid balances say, build it new, and tell the façade to route only those requests to the new service. Everything else still flows to the old system.
• Repeat until the old system is empty. Module by module the new architecture grows and the monolith shrinks, until it carries no traffic at all and can be switched off and removed.

It is slow on purpose, and the slowness is the point. The risk is spread across months of small reversible steps rather than staked on a single terrifying night.

Standards stop the new parts becoming a new trap

The pieces fit together only because they are built to a shared blueprint, the TM Forum’s Open Digital Architecture: a set of open interfaces that let an operator buy a component from one vendor and slot it in without being bound to that vendor forever. Swapping one cage for a newer cage is not progress, and standards are what prevent it.

The shape of the finished thing

Strip away the acronyms and the argument is plain. An operator that leaves its OSS and BSS as two siloed mainframes cannot provision a network slice, cannot bill for a guaranteed service level and cannot run an autonomous network, which means it cannot earn the money 5G was meant to bring. The rebuild is not optional, and it is not really an IT upgrade. It is the difference between owning the pipes and owning the platform.

Done well, with the data unified, the two systems fused, the migration carried out quietly under live traffic and the standards holding the parts together, the operator stops being a utility that sells connectivity by the metre. It becomes the thing it spent thirty years carrying other people’s businesses on top of: a platform. The companies that reach that point will not advertise it.

Their customers will simply notice that things work, that the bill is right, and that the network had healed itself before anyone reached for the phone to complain.
To learn more about turning OSS and BSS into growth drivers, contact our team.