Transitioning to Open Digital Architecture (ODA) is a critical step for telecom operators. Monolithic BSS/OSS systems are no longer capable of supporting the dynamics of the modern market, blocking the rapid implementation of innovations such as AI agents and cloud-native services. However, a full replacement of the legacy core using a "big bang" approach carries colossal risks, ranging from the suspension of critical business processes to network failures. Operators require a strategy for gradual, secure modernization that allows for updating the IT landscape in parts while maintaining service stability.
Why monolithic BSS/OSS systems have become a barrier to AI and new tariffs
The telecom industry has long been built on monolithic solutions where CRM, billing, product catalogs, and network management systems (OSS) were tightly integrated at the database and proprietary code levels. Any change in pricing or an attempt to bring a new convergent product to market required months of development and testing.
Today, 3GPP standardization ensures equipment compatibility, and the 5G core architecture (service-based architecture) brings telecom closer to cloud-native principles. Against this backdrop, legacy BSS/OSS systems remain the primary bottleneck. It is estimated that up to 53.7% of integration budgets in telecom may be spent on maintaining complex point-to-point connections between legacy systems. This makes the rapid onboarding of external partners impossible. For example, attempting to integrate a modern AI agent for customer service directly into a monolithic CRM often leads to database performance degradation and creates serious architectural risks.
Anatomy of ODA: how TM Forum standards are transforming telecom architecture
Open Digital Architecture (ODA), developed by the TM Forum consortium, offers a reference modular architecture. It replaces monoliths with a componentized, API-first structure for autonomous operations. Instead of a single "black box," ODA divides the operator's IT landscape into clearly defined functional domains:
- Engagement (interaction with customers and partners);
- Party (management of subject information);
- Core Commerce (catalogs, orders, billing);
- Production (resource and service management);
- Intelligence (analytics and AI services).
Each domain consists of separate ODA components that interact exclusively through standardized TM Forum Open APIs. This allows operators to replace individual modules from different vendors without rewriting the entire system. However, a secure transition to such an architecture requires the right strategy.
Strangler Fig strategy: phased legacy replacement without billing disruption
To minimize risks, the Strangler Fig design pattern is used. Its essence lies in gradually wrapping the old monolithic system with new microservices and API gateways that intercept calls. Over time, functions are migrated to new components, and the monolith is decommissioned.
Real-world scenarios for applying this strategy include:
- Gradual replacement of the billing module with a cloud-native component while maintaining the old CRM via an integration layer.
- Using a low-code platform to create an API gateway that aggregates data from old databases and new microservices.
- Implementing an AI agent for customer support that accesses data through standardized Open APIs without affecting the legacy core.
The modularity of ODA allows for updating individual components in weeks rather than months. Applying the Strangler Fig strategy reduces system downtime risks from critical to manageable.
Low-code as an integration bridge: combining UnityBase with the legacy core
A key element in implementing the Strangler Fig pattern is creating a flexible integration layer. It must not only redirect traffic but also transform legacy system data models into standardized structures.
As a technological foundation for such tasks, the telecom practice of Intecracy Group—an alliance of independent companies linked by partner agreements and share exchanges—uses the low-code platform UnityBase (jointly developed by the alliance companies; the key developer is InBase). Thanks to the Domain metadata concept (a unified data model, interface, and API) and DBMS-agnostic ORM, the platform allows for the automatic generation of REST APIs and the rapid linking of legacy BSS/OSS with new ODA components.
For example, for operator VoIP solutions like DooxSwitch, this architectural approach simplifies CDR data exchange and billing integration with other systems. For mission-critical environments, UnityBase supports role-based access control (RBAC), row-level security (RLS), and detailed audit trails. For projects with high loads or increased security requirements, the commercial Enterprise or Defence editions are officially recommended, as they provide advanced encryption tools and Active Directory integration.
Preparing for the AI Act and implementing AI agents via standardized Open APIs
When an AI agent attempts to access customer data, it should not access legacy tables directly. Instead, it must interact through ODA-compliant Open APIs. This ensures transparency, manageability, and data control—key requirements of modern regulations such as the AI Act.
It is worth noting that transitioning to ODA does not automatically solve all cybersecurity problems, but rather creates a reliable architectural base for access management. Also, one should not expect the immediate elimination of technical debt. Approximately 27.7% of maintenance costs for legacy components may persist during intermediate migration stages, but this is a justified price for maintaining business continuity during a large-scale transformation.
Step-by-step algorithm for BSS/OSS migration to ODA using the Strangler Fig strategy
- Step 1: Audit and map current legacy interfaces to ODA components (TM Forum Open API).
- Step 2: Deploy an integration layer (e.g., based on the UnityBase low-code platform) to create a unified data model.
- Step 3: Isolate the first critical module (e.g., a self-service portal) and create an API gateway for it.
- Step 4: Launch the new cloud-native component in parallel with the legacy module and gradually redirect traffic.
- Step 5: Fully decommission the old module after stabilization and move to the next component (billing, CRM).
FAQ
How can I start the transition to ODA if the budget is limited and it is impossible to replace the entire BSS/OSS?
The most effective path is using the Strangler Fig pattern. Instead of a full system replacement, an intermediate integration layer is created. This allows for isolating and replacing individual modules (e.g., a user portal) gradually without disrupting the core.
Does ODA ensure compatibility with 5G core architecture and 3GPP standards?
Yes. The 5G core architecture (3GPP standards) is built on the principles of service-based architecture, which fully aligns with the ODA ideology from the TM Forum. Both approaches are based on cloud-native principles and API-first interaction.
What is the role of low-code platforms in modernizing telecom systems according to TM Forum standards?
Low-code platforms, such as UnityBase, act as an integration bridge. They allow for transforming legacy data into standardized structures, generating REST APIs, and managing access (via RBAC/RLS), which significantly accelerates the deployment of ODA-compliant components.
Data sources
- TM Forum: Open Digital Architecture (ODA)
- 3GPP — Mobile Standards
- medium.com: Open Digital Architecture (ODA): A Cloud-Native Blueprint for Modern Telco Platforms | by Adheesha Gamage | ADL Blog | Medium
- fiercenetwork.com: Was TM Forum ahead of its time with its Open Digital Architecture? - Fierce Network