Telecom operators have spent years building BSS platforms around billing, customer management, product catalogs, charging, order management, and provisioning. These systems handle critical business operations, but many were designed as tightly connected applications where changing one capability can affect several others.
That architecture becomes a problem when operators need to launch new services, support 5G business models, integrate digital partners, or introduce new pricing strategies. A simple product change can involve multiple development teams, vendor dependencies, testing cycles, and integration updates.
Composable BSS architecture offers a different approach. Instead of depending on one large platform for every business function, operators can build their BSS environment from independent, interoperable components that communicate through APIs and events.
The objective isn't to replace every existing system immediately. It's to make telecom IT easier to change, integrate, and expand without repeatedly rebuilding the entire environment.
Why Monolithic BSS Architecture Is Becoming a Problem
Traditional BSS platforms often combine several business capabilities within a tightly coupled application. Billing, product configuration, customer management, and order processing may share databases, business logic, and deployment dependencies.
This structure can work for years, particularly when products and business processes change slowly. However, it becomes difficult when an operator needs to introduce new services or modify existing workflows quickly.
For example, launching a new 5G enterprise offer may require changes to the product catalog, pricing engine, charging platform, order management, provisioning, and customer channels. If these functions are tightly coupled, even a relatively small enhancement can require coordinated development and regression testing across the platform.
The problem isn't necessarily that the individual functions are outdated. It's that the architecture makes them difficult to change independently. TM Forum's Open Digital Architecture (ODA) addresses this challenge through modular, interoperable, cloud-native components and standardized Open APIs. Its objective is to help operators reduce integration complexity while modernizing BSS and OSS capabilities incrementally.
What Is Composable BSS Architecture?
Composable BSS means organizing business support capabilities as independent components that can be selected, integrated, replaced, and scaled according to business requirements.
Instead of relying on one application to handle everything, an operator can use separate components for product catalog management, customer management, charging, billing, ordering, and provisioning.
A simplified architecture looks like this:
Digital Channels
|
API Gateway
|
+------------+------------+
| | |
Product Customer Order
Catalog Management Management
| | |
+------------+------------+
|
Event / API Layer
|
+------------+------------+
| | |
Charging Billing Provisioning
| | |
+------------+------------+
|
Network / Partners
Each component owns a defined business capability and communicates with other components through agreed interfaces.
This doesn't mean every function must run as a separate microservice. A composable architecture can include modular applications, microservices, existing legacy platforms, and external services. What matters is that dependencies are controlled and capabilities can evolve without requiring a complete platform deployment.
APIs Make Independent Components Work Together
A composable BSS environment depends on consistent integration contracts. For example, when a customer purchases a new mobile plan, the order-management component should be able to communicate with the product catalog, customer system, charging platform, and provisioning workflow without relying on proprietary database access.
TM Forum Open APIs provide standardized interfaces for capabilities such as product catalog management, product ordering, customer management, and service operations. These APIs help reduce the amount of custom integration required when connecting different telecom platforms.
For developers, this means treating each BSS capability as a service with defined responsibilities, supported operations, authentication, and data contracts. Event-driven integration is equally important. An order-accepted event, for example, can trigger provisioning and billing workflows without requiring every system to continuously poll another application for updates.
Replacing Monolithic BSS Without Disrupting Live Operations
A complete BSS replacement can be risky, especially when the existing platform handles millions of billing records, active subscriptions, and critical customer transactions. A more practical strategy is incremental modernization.
Operators can identify the components causing the most operational friction and replace them individually while keeping stable legacy functions running.
For example, an operator might introduce a modern product catalog while continuing to use its existing billing engine. Later, it can modernize order management, introduce API-based provisioning, and gradually migrate charging capabilities.
This approach is sometimes called a strangler pattern: new capabilities take over selected responsibilities while the legacy system continues supporting the remaining workloads.
A simplified migration could look like this:
Existing Legacy BSS
|
API Integration
|
+----------+----------+
| | |
Modern Existing Modern
Catalog Billing Ordering
| | |
+----------+----------+
|
New BSS Services
|
Gradual Migration
The important part is maintaining consistent customer, subscription, product, and billing data during the transition. Operators need clear ownership of each data domain, synchronization rules, transaction monitoring, and rollback procedures.
A real-world example discussed by TM Forum at DTW Ignite 2026 was Telekom Slovenije's ODA-based BSS transformation. The approach used ODA-aligned components and Open API wrappers around legacy systems to support phased modernization rather than a disruptive replacement.
Cloud-Native Architecture and Microservices
Cloud-native technologies can make composable BSS easier to deploy and operate, but moving an existing monolith into containers doesn't automatically make it composable.
The architecture needs meaningful separation between business capabilities, independent deployment pipelines, controlled service dependencies, and consistent API contracts.
For example, product catalog management should be able to evolve without forcing a complete billing deployment. Similarly, customer management and order processing should expose stable interfaces that other services can consume.
Microservices can support this model, but they also introduce operational complexity. Distributed transactions, service discovery, observability, security, data consistency, and version management all need attention.
For some operators, a modular monolith may be a better starting point than splitting every function into a separate service. The decision should depend on business boundaries, scaling requirements, team ownership, and deployment needs rather than following microservices as a default architectural rule.
How Composable BSS Supports 5G and New Revenue Models
Composable architecture becomes particularly valuable when operators move beyond traditional mobile subscriptions. 5G introduces opportunities around private networks, network slicing, IoT, enterprise connectivity, and partner-based services. These business models often require different pricing structures, service configurations, charging rules, and fulfillment workflows.
A tightly coupled BSS can make these changes expensive because multiple functions need to be modified together.
Composable BSS allows operators to introduce new monetization capabilities without redesigning the entire platform. For example, a new enterprise connectivity product can use existing customer management and billing components while adding specialized product configuration and charging capabilities.
This is also where Amdocs and Optiva are relevant to the discussion. Their telecom BSS portfolios cover areas such as product management, billing, charging, and monetization, illustrating how operators can modernize business capabilities through modular platform approaches rather than relying exclusively on traditional monolithic deployments.
Why MVNOs Have Different Composable BSS Requirements
For an MVNO, composable BSS isn't only about supporting enterprise 5G services. It is also about controlling everyday operations without depending on multiple disconnected platforms.
Subscriber management, SIM/eSIM activation, plan configuration, billing, wholesale reconciliation, and provisioning need to work together. If each capability operates independently without reliable integration, the operator simply replaces one monolithic problem with several smaller integration problems.
Telgoo5 provides a modular telecom platform covering billing, online charging, customer management, product management, and wholesale enablement. These are examples of the business capabilities MVNOs need to connect when building a flexible BSS environment.
TelcoEdge Inc. takes an integrated MVNO operations approach, bringing together real-time billing, subscriber management, product and plan configuration, SIM/eSIM operations, and API-driven integrations. Its platform also describes a staged migration from existing BSS environments, which is relevant for operators that want to modernize without interrupting live subscriber services.
The architectural decision for an MVNO is whether to assemble separate components or adopt a more integrated platform with clearly defined capabilities and interfaces. Both approaches can work, provided the operator maintains control over data, integrations, and future migration options.
Common Mistakes When Implementing Composable BSS
One common mistake is treating composability as a technology upgrade rather than an architectural and operational transformation. Deploying containers, adopting Kubernetes, or introducing APIs won't solve problems if business functions remain tightly coupled.
Another mistake is creating too many independent services. Every additional component introduces integration, monitoring, security, and lifecycle-management responsibilities. Components should represent meaningful business capabilities, not simply individual database tables or application functions.
Data ownership is another major challenge. If billing, customer management, and product catalog systems maintain conflicting versions of the same information, the operator can experience inconsistent invoices, failed orders, and provisioning errors.
Finally, modernization projects need measurable business objectives. Faster product launches, lower integration maintenance, reduced operational effort, and improved billing accuracy are more meaningful outcomes than simply counting how many microservices have been deployed.
What Developers Should Prioritize
When designing a composable BSS environment, developers should begin by identifying the business capabilities that need independent evolution. Define clear API contracts, establish ownership of customer and product data, and introduce event-driven integration where asynchronous workflows are appropriate.
Migration should happen in controlled stages, with automated regression testing, data validation, observability, and rollback plans. Teams should also monitor integration failures and transaction consistency across both legacy and modern components.
The goal is to create an architecture where individual capabilities can change without destabilizing the entire telecom business.
The Future of BSS Is Modular, Not Fragmented
Composable BSS architecture gives telecom operators a practical alternative to maintaining large, tightly coupled platforms indefinitely. It creates room to modernize billing, charging, product management, customer operations, and provisioning at different speeds while preserving the systems that still deliver value.
However, composability doesn't mean building dozens of disconnected applications. It means creating a coordinated architecture where each business capability has a clear responsibility, reliable interfaces, and the ability to evolve independently.
For telecom developers, the most important shift is moving away from thinking about BSS as one enormous application and toward treating it as an ecosystem of connected business capabilities.
The real measure of successful BSS modernization isn't how many legacy systems an operator replaces. It's how easily the business can introduce a new capability without having to change everything else.
Top comments (0)