ODA Components: building blocks for the future of BSS/OSS

TM Forum’s Open Digital Architecture (ODA) provides telcos with a blueprint for replacing legacy systems with a modular, cloud-native approach. Leonardo Hodgson considers how ODA Components are creating agile, interoperable digital ecosystems, and why they matter.

The telecoms industry is undergoing a major transformation, driven by the need for greater agility and more flexible, composable approaches to technology and business. Yet traditional BSS and OSS that underpin telco operations are increasingly unable to keep up with the speed and complexity of modern digital services.

This is where the Open Digital Architecture (ODA) offers a solution.

Developed by TM Forum, ODA provides a comprehensive blueprint for Communications Services Providers (CSPs) and technology vendors. It helps modernise IT and network environments, enabling faster innovation, lower operational costs, and significantly improved customer experiences.

ODA Overview

As I outlined in a previous blog, the foundations of ODA are built around several core elements: Common Language, Open APIs, Components, Canvas and Governance. Each ensures that digital solutions align with ODA’s principles of openness, modularity and interoperability.

Innovative CSPs are now actively working to establish their own Kubernetes-based Canvases on leading cloud platforms such as AWS, Azure and Google Cloud. These environments serve as the starting point for modern production, testing and development ecosystems, enabling the deployment of ODA-compliant components from vendors, partners and their own internal teams. Earlier this year, Vodafone Greece made headlines by becoming one of the first to launch TM Forum’s ODA Canvas in a live commercial setting.

On the vendor side, significant efforts are underway to align existing solutions with the ODA framework. For providers with legacy or monolithic architectures, achieving compliance often requires substantial modernisation, shifting towards cloud-native, standards-based architectures built on interchangeable components.

Inside an ODA Component

An ODA Component can be thought of as a self-contained, deployable unit of software with a specific business purpose.

Much like a building block, it can be combined with other components to construct complex systems or end-to-end solutions. These components can originate from various sources, including in-house development, public cloud marketplaces, open-source projects, partnerships or independent software vendors.

Key characteristics of an ODA Component include:

• Microservices-based architecture
  Components are designed for cloud-native deployment, supporting features like autonomous management, self-healing and elastic scaling.
• Independent deployability
  Each component includes a machine-readable “envelope” containing metadata that describes its interfaces and operational characteristics. This enables fully automated deployment and lifecycle management with minimal manual intervention.
• Specific business function (core function)
  Every component is built to fulfil a well-defined role or task within a broader business process.
• API-first design
  Components expose their capabilities through standardised APIs, making them easily composable and interoperable with other components in the ecosystem.

How do you build an ODA Component?

One of the key principles behind ODA Components is that they should be self-deployable, making it easier and faster to integrate solutions into a CSP’s environment. This is a major shift from legacy software models that often require significant manual effort for installation, configuration and integration.

ODA enables this through digital definitions that describe how a component should behave. For this to work smoothly, each component must provide the right level of information in standard metadata files. These tell the Canvas what the component does and how it should be deployed.

Once deployed, the ODA Canvas reads these definitions and automatically manages the entire lifecycle of the component. This includes everything from deployment and operation, to updates, maintenance and decommissioning, ensuring consistency and reducing the need for manual intervention.

TM Forum’s guidelines recommend starting with containerised, modular software that includes these descriptions, making the components ready for deployment in cloud environments.

To support vendors and developers, TM Forum also provides publicly available metadata templates and schemas, offering a practical starting point for building, converting or testing ODA-compliant components. This  makes ODA adoption more accessible for everyone.

The ODA Component Directory

TM Forum has broken down the telecom IT and network landscape into dozens of individual components, each representing a specific capability required to run a digital service provider business. These are catalogued in the ODA Component Directory, a central platform where organisations can discover, share and collaborate on ODA-compliant solutions.

The directory serves two main purposes: it provides detailed specifications for each component defined by TM Forum; and acts as a marketplace where vendors can showcase their solutions along with their certification status and technical details. While the framework is highly granular – there are currently 66 components – most vendors choose to group multiple components together into broader composite components that make up the products they sell.

For example, at Cerillion, our Enterprise Product Catalogue covers the Product Catalog Management (TMC001), Product Configurator (TMFC027) and Service Catalog Management (TMFC006) ODA components. This enables us to deliver a full catalogue solution while remaining flexible and open to integration with other third-party systems, fully aligned with ODA principles.

You can explore Cerillion’s full listing in the ODA Component Directory.

Component Certification

In January 2025, TM Forum launched the first set of conformance certification tools for ODA components under a Special Availability programme. This initiative allows software providers to validate that their components meet ODA specifications and can operate within an ODA Canvas environment.

Following successful trials by several members, including Cerillion, conformance certification has recently moved into General Availability and was officially launched at this year’s DTW event in June. Today, any organisation can access the certification tools and begin validating their components directly through the TM Forum website.

Conclusion

ODA is already proving to be a powerful framework for building agile, interoperable and automated systems. With the conformance certification programme now live and the ODA Canvas available for public download, the key enablers are in place.

Vendors and service providers have everything they need to start building or adapting their solutions to the ODA model. By embracing this architecture, companies can accelerate innovation, streamline integration, and position themselves for long-term business success in a fast-evolving digital landscape.