The operating system for telecom providers

Telecom providers sell more kinds of services than they did ten years ago: fibre and mobile, TV, VoIP, partner add-ons such as security software, each with its own provisioning step and pricing. Revenue has moved from voice and SMS to data, and the back office has to keep up with every new bundle. For regional ISPs, MVNOs and resellers, the hard part is rarely the network. It is the tools behind it. The software behind it is a growing market: Straits Research values the global OSS/BSS market at USD 27.12 billion in 2026 and forecasts USD 78.95 billion by 2034, a compound annual growth rate of 14.29% (Straits Research, 2026).

Large operators can fund multi-year transformation programmes. Smaller operators often end up with a patchwork instead: billing in one system, the CRM in another, provisioning scripts on a server and spreadsheets in between. The same customer and product data lives in several places, and someone on the team keeps it in sync by hand.

This article explains what a BSS "operating system" is, why consolidating on one platform matters for small and mid-sized operators, the principles behind it, and how METAVSHN applies them.

The patchwork problem

Telecom stacks didn't become complex overnight. Over the years, operators added a billing tool, a CRM, network management and order handling, each chosen to solve one department's problem. Integration was left for later or handled with scripts, and the result is a web of point-to-point connections and overlapping databases.

For an ISP or MVNO this shows up every day. Staff re-enter the same customer in several systems. A new tariff or partner means changes in several places. Manual reconciliation causes invoice errors and provisioning delays. And monolithic legacy systems struggle with data-centric services and online sign-up flows, because they were built for a slower, simpler product range.

Fragmented data also limits automation. Any process that needs a complete view of a customer, their services and their invoices has to stitch that view together first. Exposing each system through its own API does not solve this on its own: point-to-point interfaces are built for one caller at a time, not for streaming the same change to every system that needs it. Microsoft's telecommunications team describes the same problem: OSS and BSS environments "have remained fragmented, hindering a unified view spanning the customer, the network, and the business" (Microsoft, 2025).

McKinsey defines digital transformation as "the fundamental rewiring of how an organization operates", with the goal of "continuously deploying tech at scale" (McKinsey, 2023). When core data is spread across several tools, every one of those deployments starts with reconciling the data first.

What is a BSS operating system?

A business support system (BSS) runs the commercial side of a telecom operation: product catalogue, quoting, rating, invoicing, payments, partner commissions and customer care. An operations support system (OSS) runs the network side: provisioning, alarms, performance and inventory. The two often grew up separately, which is where the patchwork comes from. A BSS operating system replaces it with one platform, one data model and consistent interfaces.

The idea builds on standards from the TM Forum. Its Information Framework, also called the Shared Information/Data (SID) model, is a reference model and shared vocabulary for telecom business entities. It is independent of platform, language and protocol, and it groups the domain into areas such as Market & Sales, Customer, Product, Service and Resource, so each entity is defined once.

The TM Forum's Open Digital Architecture (ODA) complements SID with a blueprint for building operations from components with open APIs, so parts can be added or replaced without rebuilding the whole stack. A BSS that follows both becomes the single source of truth for customers, products, subscriptions, orders, invoices and payments.

Event-driven architecture and typed connectors

Legacy integration relies on systems calling each other directly. That works for one request at a time, but it creates brittle dependencies and makes real-time distribution hard. In an event-driven architecture, each business event is published once to a central broker, and every authorised system that cares subscribes to it. One change reaches many systems, the flow is easy to observe, and legacy systems can keep running while new components are added step by step.

Typed connectors give each domain a stable contract: service activation, billing, hardware logistics, identity verification. The connector holds the logic for talking to a specific partner. When you change wholesale partner or payment provider, you swap the connector, and the business logic stays the same. Together with a canonical data model, this makes each integration predictable instead of a new project.

Cloud-native and composable

Modular, cloud-native architectures with reusable components and open APIs have become the normal way to build OSS/BSS. Independent services, for example rating, mediation or the customer portal, can be deployed and scaled on their own, and continuous delivery makes small, frequent releases safer than large upgrades.

Why consolidate your BSS on one platform?

• Faster launches: when catalogue, quoting, provisioning and billing share one data model, a new offer is a catalogue entry, not a project across departments. China Telecom reported that its cloud-native BSS, built on TM Forum's Open Digital Architecture and Open APIs, cut the time to launch a new service from two months to three days (TM Forum, 2020).
• Less operational work: fewer tools mean fewer hand-offs, fewer copies of the same data and fewer vendors to coordinate. Event-driven integration lets you modernise one part at a time.
• Cleaner billing: one source of truth feeds invoicing and the accounting export, so there is less to reconcile and fewer invoice corrections.
• Clearer customer experience: correct invoices and a self-service portal that shows the same data as your back office reduce disputes and support calls.
• Data you can build on: reporting, automation and any assistant or agent you connect later all read from one consistent model instead of several partial copies.
• Security and compliance at the core: access rights, audit logs and identity checks are defined once for the whole platform, not per tool.

Principles of a telecom operating system

1. Canonical data model: use an industry information model such as TM Forum SID. Customer, product, subscription, order, invoice and payment are defined once and referenced everywhere.
2. Typed connectors and open APIs: give each domain a connector with a stable contract, and use TM Forum Open APIs where they exist, so partners can be changed without touching business logic.
3. Event-driven backbone: publish domain events such as order.created, subscription.activated or invoice.sent to a broker that any authorised system can subscribe to.
4. Independent services: split the platform into services that can be deployed and scaled separately.
5. Reporting and automation on the same data: catch revenue leakage, flag unusual usage and automate repeatable steps from the canonical model, not from exports.
6. Configuration over custom code: workflows and products should be changed through configuration, so a new service doesn't need a development project.

Starting the move

Large change programmes often miss their targets. BCG's 2020 research, based on a survey of 825 senior executives, found that 70% of digital transformations fall short of their objectives (BCG, 2020).

Replacing back-office systems is a large change, and projects that only wrap old systems without fixing the data model rarely deliver what they promised. To lower the risk:

1. List your systems: document every system that touches customer, product and network data, and note where the same data is stored twice.
2. Map to a canonical model: align your entities with SID, even before you retire anything. A shared vocabulary is what makes later steps possible.
3. Add events before replacing systems: put an event layer over existing systems first, so old and new can publish into the same backbone while you migrate.
4. Adopt in phases: start with billing and the product catalogue, then add provisioning, partner settlements and the customer portal.
5. Use open standards: TM Forum Open APIs and ODA components reduce lock-in and speed up partner onboarding.
6. Plan for the team: new tools change how people work. Involve the people who run billing and support from the first step.

METAVSHN: one platform for regional operators

METAVSHN is built on the principles above. Customer, product, subscription and order data share one model that follows TM Forum SID. Typed connectors handle service activation, billing, hardware logistics and identity verification, so partners can be swapped without rewriting business logic. Domain events go out through webhooks, so accounting, support tools and analytics stay in sync without polling.

It is made for regional ISPs, MVNOs and telecom resellers that have outgrown spreadsheets and accounting tools but don't need a Tier-1 BSS suite. Because it is modular, you can adopt it in phases: new tariffs become catalogue entries, the same model feeds your accounting system, and your customers use a self-service portal built on the same data. See the billing engine for the SID-based data model, the integration hub for available connectors, or the enterprise suite for hosting and security.

Conclusion

Data-centric services, more partner products and higher expectations for self-service all need a back office built on one data model. A patchwork of tools can be kept running, but every new product and every new partner makes it more expensive.

A telecom operating system built on a canonical data model, typed connectors, events and independent services removes that cost: launches get faster, billing gets cleaner and your team stops copying data between tools.

For regional ISPs, MVNOs and resellers, METAVSHN is a way to get there in phases, on a platform hosted in Switzerland that follows TM Forum standards.

Sources

All sources accessed on 3 October 2026.

1. Straits Research, "OSS BSS Market Size, Share & Trends Analysis Report (2026–2034)", last updated 24 August 2026. straitsresearch.com/report/oss-bss-market
2. Monte Hong, Microsoft, "The transformative impact of AI and generative AI on OSS and BSS in telecommunications", 8 April 2025. microsoft.com
3. McKinsey & Company, "What is digital transformation?", McKinsey Explainers, June 2023. mckinsey.com
4. TM Forum Inform, "China Telecom's BSS 3.0 turbo-charges agility, reducing time to market from months to days", 31 March 2020. inform.tmforum.org
5. Patrick Forth, Tom Reichert, Romain de Laubier and Saibal Chakraborty, Boston Consulting Group, "Flipping the Odds of Digital Transformation Success", 29 October 2020. bcg.com