Is the TMF Open Digital Architecture the ultimate destination for the adoption of composability?

The TMF Open Digital Architecture promises to provide a unified approach to both APIs and process management – but many legacy systems and functions will never migrate to ODA.

What’s needed is an approach that enables the realisation of the ultimate goal of ODA compatibility while also extending to legacy solutions so that they can be included in automation and transformation efforts.

One API to rule them all – a longstanding goal

Over the years, there have been many (many) efforts to introduce universal APIs to enable efficient integration between systems and entities in the telco OSS, BSS and network domains – in this context, the TMF’s Open Digital Architecture (ODA)is just the latest in a long line of contenders.

However, there’s reason to believe that ODA could just emerge as a champion that will gain widespread acceptance. There are also a couple of reasons to question this, on which more later.

ODA consists of a series of linked APIs and now components that accelerate integration between functions and business processes. It provides an overall architecture, and the goal is to help telcos transform into platform businesses, exposing capabilities under strict governance and control, while accelerating automation for both internal and external purposes.

So far so good. Older readers may recall other initiatives, like JAIN – ‘write one, run anywhere’ – and also consider parallel initiatives like the GSMA’s OneAPI, which is recognised as being complementary to the TMF’s efforts – so much so, that the two influential organisations are collaborating to drive adoption.

Could ODA succeed where others failed?

Why might ODA be more successful? We think it’s largely because this initiative has strong support from the service provider community. In contrast, initiatives like JAIN were largely vendor driven and did not gain the expected traction because there was less agreement among the target user community – service providers.

All of this is great news for the industry, and we can expect many vendors (including We Are CORTEX) to announce their commitment to these initiatives. Great news, because the more players that support ODA (or OneAPI), the more rapidly these will spread through the ecosystem and accelerate the interconnectedness of all things. In turn, unlocking new levels of automation-driven efficiency, and facilitating new partnerships. Wouldn’t that be lovely?

But there is an obvious wrinkle here. Our legacy. The fact is that your OSS, BSS and network domains are fully of a diverse array of different systems and platforms. The simple truth is that some will (and some already do) support ODA – but not all do or will.

Most operators have a huge estate of legacy assets. And, most of these play essential roles in service delivery or in supporting operational processes. These simply cannot migrate to a new quasi-universal standard, like ODA, overnight – and many will not follow this path.

Other kids on the block – 5G SA and MCP

The other reasons to question this integrated utopia is a bit more subtle. Already, the 5G SA core is based on REST APIs – the Service Based Interfaces. So, we already have a different (but likely compatible) set of APIs in many of our networks.

Similarly, many both from the telecoms and other industries are beginning to explore and experiment with Model Context Protocol (MCP). Essentially, this is a way of sharing resources between AI tools and other sources of data, under a strict form of governance.

While in its infancy, it should be no surprise that the TMF is already looking at compatibility between MCP (and AI) and the existing ODA. Equally, experiments and PoCs are already underway to demonstrate how this might all hang together.

MCP will facilitate interaction between different Agentic AI agents and the knowledge exchange necessary to support integration – which will, ultimately, be essential, since AI and AI-enabled interaction will be foundational to 6G – but that’s a long way off. Still, early results seem promising and it’s likely that this approach will gain importance as more vendor AI solutions emerge.

Integrating with the legacy OSS, BSS and network domains

What matters is now, however. And here, while ODA helps with composability for interactions and services, the fact remains that a vast range of systems are not compatible with this approach.

This presents a challenge for automation. Do we focus on the current and future, or do we also extend our view to include those necessary but legacy systems on which we depend? Things like inventory platforms, billing systems, assurance and alarm handling functions – investments you have made but which may not be aligned with the direction followed by the TMF and others.

The clear answer is that we have to extend our view to legacy systems too. Yes, we must transform, and these initiatives provide both templates and a helping hand to support our goals. But we cannot neglect key services and platforms that may not be fully compatible with new investments in ODA, for example.

What we need is a pathway that is compatible with future migration to ODA while retaining backwards compatibility with legacy interfaces which may never be included in the scope of this framework – or simply never updated by the relevant solution providers and vendors.

This pathway is already here. That’s because the ODA has adopted a components-based approach, building on the concepts of Composable IT. Core functions are represented as processes that can then be linked to the underlying systems that require them at different stages of operational flows – think identity management, billing calculation, usage management and so on.

The We Are CORTEX approach

This approach mirrors our own – which is also based on Composable IT. However, the key difference is that our processes don’t just support ODA interfaces, they support an extensive range of legacy methodologies.

In this case, we extend support to protocols like those from 3GPP, SNMP, REST, SQL, SNTP, O365 / Gmail – as well as open API formats from the TMF. So, this provides backwards compatibility with the necessary legacy standards, as well as vendor-specific implementations that are not covered by ODA.

So, this means that you can leverage We Are CORTEX to include any legacy platform in your transformation and automation programmes, while also building in the ability to migrate towards ODA in the future – and align with current investments in ODA migration.

If you’d like to learn more about our approach to Composable IT and how our process-based approach offers you investment protection, read our new white paper – “Composable IT and process fragments”.

It shows how you can build Service Assurance using efficient automation through component-level abstraction and integration – and also extend to other key functions that cross multiple domains.

Download our new paper, “Composable IT and process fragments – Building Service Assurance using efficient automation through component-level abstraction and integration”