Here’s a new architectural vision for OSS/BSS, created by operators, called the Open Digital Enablement System (ODES), explained by some key contributors, in their own words*.
Laurent Leboucher, Vice President, Architecture, Enablers and Security, Orange, commented,
“A lot of operators’ IT transformation projects either have failed or almost failed – by almost failed I mean that if it takes more than two years to transform a BSS stack, it’s failed,” he said. “When you transform IT, it’s not just about defining the target; it’s really about how you can execute it in a reasonable timeframe that can achieve results in a very iterative and agile way.”
George Glass, Chief Systems Architect, BT, agreed, saying that CSPs’ overall OSS/BSS architecture is “much too big and complex,” and that operators need common components with granularity to enable flexibility in developing and delivering services.
BT has done a significant amount of work transforming it’s OSS/BSS already. Glass gave an example of billing system transformation that required exposing internal billing services to customer relationship management systems. Through this transformation, BT has been able to save about $4 billion over the past seven to eight years.
Overall, operators who participated in the workshops to develop ODES said OSS and BSS must be:
- standards-based, enabling a marketplace of commercial and open source innovation;
- unified in a single architecture;
- data-centric with a single data lake to enable automation and AI;
- platform-based and componentized for agility using TM Forum Open APIs;
- artificial intelligence (AI) capable and autonomous;
- real-time in order to respond to the expectations of customers; and
- ecosystem capable to allow easy interaction with partners
Both of them were speaking at a day-long workshop at Action Week in Vancouver in late September at which there were more than 60 attendees, including executives from AT&T, BT, Globe Telecom (SingTel), Microsoft, Orange, Telefónica and Vodafone, as well as many consulting companies and suppliers. The workshop was to primarily to gather feedback about the ODES architecture (see graphic below) , which has been developed with input from many of TM Forum’s key communicatoins service provider members (CSPs) during a series of workshops.
ODES is consistent with the Forum’s Frameworx definitions and domains. Frameworx is the Forum’s core suite of templates, tools and best practices, developed and evolved by the communications industry for digital business. These assets are in wide commercial use the world over, as this free collection of case studies shows.
ODES uses TM Forum assets including Open APIs and key concepts from the Zero-touch Orchestration, Operations and Management (ZOOM) project’s work on the Hybrid Infrastructure Platform. It also draws heavily from work on OSS/BSS of the future. You can find a more detailed introduction to ODES in in this blog written by Brian Levy, Strategic Advisor to the Forum. TM Forum members can access a white paper about ODES here.
Where do we go from here?
The Action Week workshop produced a spirited discussion and overall agreement on the vision and requirements, with many suggestions for refinement. Here are the most important areas and questions CSPs and suppliers would like to see expanded in ODES:
- Defining OSS/BSS and deciding how to combine them – several workshop participants pointed out that there really is no agreed definition within telecoms of what OSS are BSS are, but it’s clear that in future they will need to be a combined system, even if their functions are grouped as OSS and BSS during the transition.
- How will Frameworx be used within ODES? Frameworx has been used as the language of OSS and BSS design for many years. We will need to componentize Frameworx and bundle elements from each individual framework into a package. In the ODES white paper we have proposed calling these components ‘Framelets’.
- What’s the role for AI? – many participants urged caution against becoming overly excited about the potential for AI and machine learning. The industry needs to “walk before it runs,” they said. In addition, CSPs must determine how they are going to store data, whether to use a single data lake, for example, and decide whether this is something that needs to be standardized for all operators.
- How do we evolve the common language? As an example, the word ‘service’ is used at multiple layers in ODES. Frameworx already provides formal definitions, but we need to understand whether they need to be modified in light of the ODES layering. In addition, lots of new terms like ‘microservice’ need a clear definition. Several members contributed their definitions for consideration.
- How does the work of other standards-development organizations and open source groups affect ODES? Compatibility with open source groups, in particular, was a key consideration for the initial work on ODES, and some of the leading CSPs involved in Open Network Automation Platform (ONAP) and Open Source MANO (OSM) contributed to the alignment. For more about the relationship between TM Forum and ONAP, see this article about the Linux Foundation’s Arpit Joshipura’s keynote at Action Week earlier this week. If you’d like to learn more about ODES, please contact Barry Graham via [email protected].
This is an excerpt from a longer article that provides more information about the drivers for ODES.