Login
Register
Implementation focuses on providing machine-readable specifications and code so that ODA principles can be embedded in software systems, while the deployment architecture ensures the efficient management and operations of these systems, including automation.
Dawn Bushaus
ODA explained: Tools for implementation and deployment
At the end of March, TM Forum’s Research & Media team published its first Benchmark report about the Open Digital Architecture (ODA). As an introduction to the report, this is the second article in a three-part series highlighting one of the sections: ODA explained. Here, we look at ODA tools for implementation and deployment. You can read the first article, which focuses on tools for business and information systems, here. A final installment will examine the role of governance and AI.
The image below shows the ODA and the various TM Forum projects that are working on tools in each area. Descriptions of the key tools for implementation and deployment follow.
ODA implementation and deployment are closely related. Implementation focuses on providing machine-readable specifications and code so that ODA principles can be embedded in software systems, while the deployment architecture ensures the efficient management and operations of these systems, including automation. Both require Open APIs and standardized ODA Components, and deployment also requires a run-time environment, or “canvas”, which we’ll look at in more detail below.
TM Forum, 2025
The specification also describes complementary functions relating to how the component is deployed and managed on the ODA Canvas. These are shown in red, yellow, blue and grey in the image.
“We’re developing a market for ODA Components, so that everyone can buy and sell compatible software,” explains TM Forum’s Andy Tiller, EVP, Member Products & Services. “But we’re not – at least not yet – developing a marketplace like an online shop where you can buy a component. It’s still too complex for that.”
ODA Component conformance certification gives software suppliers a set of tools and processes to test and verify whether their commercial software products adhere to the ODA standards. This allows them to claim conformance and potentially gain market advantage by demonstrating compatibility with other ODA-compliant systems. General availability of these tools, including assistance for vendors in using them, is expected in June 2025.
An ODA Component Directory, helps CSPs find the Components they need and the suppliers that are developing compliant products. So far, more than 35 Components have been specified, with others at the prototype stage. Around 70 in total are planned to cover the OSS/BSS landscape.
More than 100 software providers have mapped their commercial products to the ODA Components and listed them in the directory. CSPs viewing the directory can see all the vendors for every component, including where they are on the journey to compliance based on formal Open API and ODA Component conformance certifications.
Development of the ODA Canvas began in 2019 as part of the Business Operating System Catalyst project, which aimed to produce an interoperable reference implementation of a telco’s core commerce management system including a product catalog and order management service. The point was to drastically simplify integration of IT systems by developing a plug-and-play environment to enable zero-touch operations.
To understand the Canvas, it helps to think of Components as Lego building blocks. The size of the studs and the dimensions of the blocks are standard so that they can be plugged together to construct objects. But to build a city out of Lego blocks, you need a stud board to support the Components and supply common services (imagine an electricity supply to light up or power multiple Lego blocks). So, TM Forum members needed to agree on the functional standards that make Components interoperable, but they also had to specify how they should plug into a cloud-native runtime environment.
Ongoing development of the reference Canvas is happening in TM Forum’s Innovation Hub – a physical lab in India – using a DevOps continuous integration/continuous delivery (CI/CD) pipeline. The reference Canvas is being built on Kubernetes, but the specification is platform independent and interoperable through the Kubernetes API.
The ODA Canvas became available for widespread use in January 2025 and, as such, CSPs are only now starting to benefit from its ability to automate operations using Site Reliability Engineering (SRE) practices. That said, nearly a third of respondents to our CSP survey said their organizations were making good progress towards an ODA Canvas DevOps environment (see pie chart).
CSPs and cloud providers are developing their own canvases based on the reference ODA Canvas. Vodafone’s version is its TaaS platform, for example, while Deutsche Telekom is developing a canvas called Magenta. Similarly, Orange is using ODA to create its Telco Cloud Factory. Bell Canada and Jio have ODA-compliant canvases as well.
“TaaS already exists as a way for different markets and functions within Vodafone to effectively be a tenant of a Kubernetes platform. It is used by our Site Reliability Engineering teams to host mainly our digital engagement systems, which run on Kubernetes,” says Dr. Lester Thomas, Head of New Technologies and Innovation at Vodafone Group. “But this canvas adds a layer on top so we can run core IT systems… Today, those systems typically run in an older environment. And even if they’re running in the cloud, they’re running in separate, siloed cloud instances, not as modular components in a single platform. Creating a single platform is what the ODA Canvas does.”
Vodafone Greece is pioneering the use of the ODA Canvas in a live, commercial environment. Since adopting the ODA in 2022, the company has modernized its core IT systems as part of Vodafone Group’s broader effort to streamline and automate its IT infrastructure.
Vodafone Greece’s ODA-based canvas enables the reuse of microservices across different clusters, ensuring seamless compatibility and functionality. It has already led to significant benefits, including higher productivity and lower costs through automation. For instance, configuring an API gateway now takes just three seconds, compared to two weeks with the previous manual approach.
Among hyperscalers, Microsoft and Google Cloud are contributing to the development of the ODA reference Canvas in the Innovation Hub, and each has also built its own compliant canvas. Amazon Web Services (AWS) has a compliant canvas as well. All three cloud providers are developing full suites of managed services with their canvas platforms.
For example, Microsoft has announced an open-source toolkit available in GitHub that makes it possible for telcos of all sizes to build ODA canvases on Microsoft Azure. Microsoft’s ODA Canvas Operators – software that automates the management of applications and services – enables developers to build an ODA Canvas on Microsoft Azure and integrate services from Microsoft including security, monitoring, logging and API management.
Google has developed a similar toolkit that is now available in GitHub. In addition, Oracle offers a compliant canvas for Oracle Cloud Infrastructure, and Red Hat offers one for OpenShift.
These developments promise to provide key benefits that could drive ODA uptake. Using an ODA-based canvas with managed services from the hyperscalers will make it easier for CSPs to move workloads from one cloud to another, while also encouraging innovation by cloud and software companies. Developers at smaller telcos and software companies will have the same tools as bigger industry players, fostering a more competitive and diverse telecoms ecosystem.
Even so, there will be differences in how companies deploy a canvas. One member has described the ODA Canvas as a broom: You can change the head and the handle, but it’s still a broom and works as such.
