If you are a TM Forum member or reader who visits Inform
often, you’ve probably heard about the Open Digital Architecture (ODA). But you may not know the fascinating history behind this initiative. This excerpt from our recent report Attaining agility and beating disruptors at their own game explains how executives from BT, Orange and Vodafone came together to address a common and costly problem: constant redevelopment of interfaces between systems. Part of
the Open Digital Framework, the ODA was launched in February 2018 as an architectural vision for the future of zero-touch, software-defined telecom operations. It aims to be a de facto standard for open digital platforms and was created using decades of evolutionary best practices in the effort to make communications service providers’ (CSPs’) networks, operations and businesses more agile.
The ODA is a component-based architecture, with the business functions of each component exposed as a set of
Open APIs. The component functionality is typically implemented as a set of services and microservices. The advantage of using services and microservices is that they can be independently managed on scalable infrastructure using
Agile development practices.
Drivers for a new architecture
Put simply, ODA can help CSPs embrace cloud and create platforms, but it’s interesting to look at the drivers for developing a new support system architecture and how the ODA came to be.
BT was a founding member of TM Forum. Underlying frameworks and best practices such as the enhanced telecom operations map (eTOM – now known as
the Business Process Framework), the shared information model (SID, now
the Information Framework), and the telecom applications map (TAM, now
the Applications Framework) became the functional foundation for BT operations.
TM Forum’s Chief Technology Officer, George Glass, was Chief Architect at BT when the company realized that it needed a new architecture to address the problem of multiple software stacks for each line of business and for each service: wireline, wireless, IP, voice and data. Arguably, this is where the Forum’s Open APIs and the ODA originated.
“We looked across the business from the consumer space to enterprise and had five product-specific stacks, and we realized that was completely nuts,” Glass says. “We had designed systems that could bill for anything from a widget to a complex wireline service, but we couldn’t send the customer a single consolidated bill for all of their services.”
The start of abstraction
BT began applying abstraction – encapsulating and representing service definitions using standard patterns built into a single functional process – within a single billing system. ODA makes extensive use of abstraction. Back then it allowed BT to provide a single bill, plus new ways of charging and billing. This facilitated new services, too, as a company can only sell what it can bill for.
BT later wanted to apply the concept across other architectural segments, establishing what it called a platform-based architecture. This comprised separate platforms for customer management, service management and billing. Unfortunately, each system exposed its services in a different way, preventing easy interoperability and BT’s goal of creating a single functional process beyond billing.
Executives at Orange and Vodafone were also frustrated by the connections that IT teams had built many times over between customer management, service management, and ordering and billing for products and services across several lines of business. To address this, BT, Orange and Vodafone began working together as TM Forum members in 2015 to standardize exposure of services, which led to the creation of Open APIs in 2016 and the genesis of the ODA.
The power of sharing
Two things had to change for this early work to evolve into a useful and usable architecture. First, companies needed to be more open in sharing their work so that the industry as a whole could benefit. Second, the Forum’s output needed to go beyond documentation to providing machine-readable code that could be implemented.
In terms of being more open, BT’s CIO said to Glass at the time the company was beginning transformation that, “there was no intrinsic value in just connecting things together. The value is in the functionality and capability you have in the components.” He allowed Glass to share at an open meeting a 200-page document that had been treated as confidential and “for BT-eyes-only” explaining how BT developed its interfaces. Other operators followed suit, and the drive toward collaborative open systems continues.
To progress beyond documentation, TM Forum changed a bylaw so members could co-develop the Open APIs under standard open source licensing terms (
Apache 2.0). Since then Orange and Vodafone, subsequently joined by Deutsche Telekom, have led the charge to create software code that CSPs can use to test ODA concepts.
Originally developed as a prototype of one part of ODA called the Business Operating System (BOS), the scope of this work has expanded to encompass development of a complete ODA Reference Implementation. Now the Forum is working on a legal vehicle and infrastructure platform, called tmf.codes, which members will be able to use to co-develop shared software code for the ODA Reference Implementation under Apache 2.0.
Building consistency
Developing code for publishing APIs gives operators and vendors confidence in the consistency of the interfaces across all users.
“Everyone knew the APIs were not written by a couple of guys in their garage but had the thinking of major telcos behind them and would work in their environment,” Glass explains.
The API work accelerated in anticipation of supporting network functions virtualization (NFV) in new and scalable ways, rather than as a reaction to the emerging threat of disruptive cloud providers and over-the-top content providers, which had not yet been fully recognized.
When the Open API Project was officially launched in 2016, that threat was clearer. The idea of operators transforming to become digital service providers using platform-based operational and business models had caught on.
The Open APIs were extended to the architecture so that operators could begin decoupling components from each other, removing the cumbersome integration between operational and business support systems. Only then could the architecture support further decoupling of functional layers, such as separating the customer experience layer from systems of record, and the engagement layer from intelligence management, and so on.
You can learn more about the ODA in this white paper and by downloading our report using the link below. To find out how to participate in the important, collaborative work to advance the ODA, please contact George Glass. 
