Telecom operators are trapped by their own legacy BSS/OSS systems. Monolithic architecture, which for years ensured stability in billing and resource accounting, has now become a primary barrier to growth. Launching new products takes months, and integrating partner services has turned into a complex engineering challenge. In an era where agility defines market survival, the industry requires a radical shift in architectural approach.
The solution lies in transitioning to Open Digital Architecture (ODA)—a standardized concept from TM Forum that involves replacing monoliths with a set of compatible, independent microservices with an API-first design. However, a complete replacement of the core (the rip-and-replace strategy) carries colossal operational risks. A practical path to modernization involves the evolutionary decomposition of the monolith using modern low-code platforms, which act as a reliable intermediary between the new digital world and legacy systems.
The legacy BSS/OSS trap: why 5G Standalone requires moving away from monoliths
Mobile communications development has reached a stage where legacy infrastructure cannot support new business models. According to the Ericsson Mobility Report (November 2025), over 90 service providers globally have already launched or are preparing to launch commercial 5G Standalone (SA) services. 5G SA technology paves the way for dynamic network slicing, real-time IoT device charging, and ultra-low latency. To monetize these capabilities, BSS/OSS must respond to network requests in real time.
Traditional billing systems were designed for static tariff plans. Attempting to add dynamic pricing logic to them leads to an avalanche of technical debt. Furthermore, legacy systems pose serious security threats. The ENISA Threat Landscape 2025 report emphasizes that the exploitation of outdated signaling protocols, such as SS7 and Diameter, remains a critical risk for mobile networks. Monolithic systems with direct access to these protocols become vulnerable targets.
Another challenge is financial loss from fraud. According to the CFCA Global Fraud Loss Survey 2025, losses in the telecom industry from subscription fraud, based on the use of forged or stolen identity data, amount to approximately 5.31 billion dollars annually. Combating this requires flexible customer verification tools, which are difficult to implement within closed legacy code.
Open Digital Architecture: decomposition instead of destruction
TM Forum has proposed the Open Digital Architecture concept as an alternative to the chaotic customization of monoliths. ODA involves dividing an operator's IT landscape into clearly defined domains (Core Commerce, Production, Intelligence, Engagement, etc.) that interact through standardized Open APIs. This allows for the breakdown of monolithic systems into dozens of independent components.
The core principle of ODA is the decoupling of systems of record, where basic data is stored, and systems of action, which interact with customers. Instead of attempting to shut down an old billing system, an operator builds a layer of ODA-compliant microservices around it, implementing new features without the risk of compromising the integrity of the main database.
This approach eliminates the fear of critical business process downtime during migration. By creating new digital services as ODA components, the operator reduces the load on the legacy core, gradually decommissioning outdated modules.
Low-code as a bridge: building ODA-compliant modules using the UnityBase metamodel
Developing ODA components from scratch using traditional frameworks often proves too slow. For rapid data structure design and API generation, it is advisable to use enterprise-class low-code platforms. The technological foundation for such modernization can be the UnityBase low-code platform, a joint development of the Intecracy Group alliance (where InBase is a key, but not the only, developer).
The main technical advantage of UnityBase for BSS/OSS lies in the concept of a Domain metadata-model. It integrates data descriptions, security logic, interfaces, and APIs. This allows developers to design business entities, while the platform automatically generates REST API, DML queries, and documentation.
Practical application examples:
- Subscription management module: Instead of rewriting code in legacy billing, a new ODA-compliant module is created. It provides standardized APIs for partners, handles subscription logic, and interacts with the legacy system via a secure gateway without changing its database structure.
- Integration gateway for digital channels: Mobile applications connect to UnityBase, which acts as an orchestrator. The platform accepts requests via modern APIs and converts them into formats understood by legacy systems, ensuring the preservation of on-premises data.
Thanks to its built-in DBMS-agnostic ORM, the platform supports work with heterogeneous databases (Oracle, MS SQL Server, PostgreSQL). Using a unified metamodel allows for avoiding the chaotic writing of point-to-point connectors, which, according to analyst estimates, can consume up to 53.7% of the IT modernization budget in complex projects.
Architectural security: data protection at the metadata level (RBAC/RLS) and fraud prevention
When dozens of microservices access customer information, traditional perimeter defense is insufficient. The UnityBase platform addresses this by applying Role-Based Access Control (RBAC) and Row-Level Security (RLS) mechanisms directly at the metadata level. Access rules are described once in the domain model and are automatically applied to all generated APIs.
For example, a call center operator sees only general subscriber information, a financial analyst has access to detailed transactions, and third-party service developers receive only depersonalized data via API. For projects with heightened security requirements (e.g., integration with government registries), official documentation recommends using Enterprise (EE) or Defence (DE) editions, which support Active Directory, hardware tokens, and integration with certificate authorities for the use of digital signatures.
This level of control, supported by a built-in Audit Trail system, allows for the detection of anomalous activity and proactive counteraction against subscription fraud at the transaction initiation stage.
Evolutionary scenario: a step-by-step migration plan without business disruption
The transition to ODA via a low-code foundation is a managed process. It includes the following stages:
- Analysis and domain identification: Identifying the most critical points in legacy BSS/OSS (e.g., order management) that are hindering the business.
- Metamodel creation: Describing the entities of the new ODA component in UnityBase with subsequent REST API generation.
- Building the integration layer: Configuring connectors to legacy systems. For processing specific voice traffic or implementing LCR routing and real-time VoIP billing, specialized software can be integrated, such as DooxSwitch (which is also part of the Intecracy Group technology alliance portfolio).
- Phased channel switching: Moving digital channels to the new ODA module while keeping the legacy system as the system of record.
Comparative analysis of BSS/OSS modernization strategies
| Comparison parameter | Rip-and-Replace strategy | Evolutionary ODA transition (UnityBase) |
|---|---|---|
| Speed of change implementation | Low (years for design and migration) | High (weeks to create individual ODA modules) |
| Risk of data integrity breach | Critical (complete database transfer) | Minimal (unified Domain metadata-model over legacy) |
| Capital expenditures (CAPEX) | Ultra-high (licenses and consulting) | Moderate (phased microservice development) |
| Vendor lock-in | Full dependency on the new monolith | None, thanks to open APIs and ODA standards |
It should be remembered that low-code platforms do not replace professional development. Complex integrations, query optimization, and network architecture design require high engineering expertise. However, low-code frees the team from writing boilerplate code, allowing them to focus on business logic.
The evolutionary transition to ODA provides telecom operators with the flexibility of cloud-native architecture while preserving investments in a functional legacy core. This is a pragmatic path toward the full-scale launch of 5G Standalone and new digital products.
FAQ
How can TM Forum ODA be implemented without a complete replacement of the billing system?
Implementation occurs through the construction of an Open API integration layer around the existing billing system. New functions are developed as separate ODA-compliant microservices based on a low-code platform, which interacts with the legacy system via secure connectors without disrupting its internal database structure.
What advantages does the UnityBase Domain metadata-model provide during BSS/OSS decomposition?
The Domain metadata-model integrates data descriptions, business logic, access rights, and APIs. This allows the platform to automatically generate REST APIs, synchronize database structures, and form documentation, significantly reducing the development time for ODA components and integration gateways.
How can personal data security be ensured when integrating legacy systems with new digital channels?
Security is ensured at the platform's metadata level. Role-Based Access Control (RBAC) rules and Row-Level Security (RLS) filtering are applied in the ORM layer, so every request from an external channel or API undergoes automatic verification, preventing unauthorized leakage of subscriber data.