Abel, could you please provide us with an overview of your involvement (and alvatross’ involvement in general) with ODA?

Certainly! This is going to be a long answer. Although I must admit that I tend to be more comfortable expressing myself through actions rather than words.

That’s understandable. Actions often speak louder than words. Now, could you please share with us some specific examples?

Of course. At alvatross, we have actively engaged in various initiatives related to ODA. One such initiative is the IG1228 – How to use ODA, where we focus on developing real business cases using the ODA architecture. Instead of presenting a lengthy abstract definition, we dive into practical scenarios and identify the ODA components involved, the OpenAPIs they use for communication, and their corresponding information structures. Let me share a couple of use cases we have proposed and developed so far:

The first Use Case is the UC008: Service and resource order management for postpaid mobile subscribers. Here, we aim to illustrate how the delivery of a post-paid mobile service should work in the ODA architecture. We explore the behaviour of product, service and resource orders throughout the entire order lifecycle. Additionally, we present detailed catalogs for the products, services, and resources being ordered. To provide a visual representation, we utilize scenario diagrams to showcase the ODA components involved and the messages exchanged between them. Furthermore, we have encouraged the use of a new ODA component that would better align with our Activation Engine.  

The second use case is UC011: Order fallout management. It focuses on managing product, service and resource fallout and aims to enhance the standard by incorporating fallout management assets aligned with our vision. As a result, we propose the addition of a new fallout ODA component (placed in the intelligence management domain), API, and ABE to the standard.

Apart from these use cases, I have been involved (with the rest of the team) in the ODA component specification, which includes identifying the exposed and consumed Open APIs, determining the ETOM Business processes in which the component is involved, specifying the TAM functions that the component should implement, and identifying the SID ABEs owned and used by the component. And finally, we build the YAML files with the definition and implementation of each component.

It’s impressive to see the breath of your involvement, Abel. Is it possible to share some more details of alvatross contributions to the ODA?

Yes. We have participated in the definition of the TMF007 Service Order Management component. Moving forward, we plan to contribute our knowledge in the specification of more components, actively collaborating with other industry experts. 

We are also engaged in the ODA-CA initiative, which aims to develop a cloud environment where ODA components can be deployed and tested. While our current involvement focuses on providing advice on technical infrastructure aspects, we are planning to deploy some of our own components in the Canvas in the upcoming weeks.

That sound like a lot of different projects. Is there anything else on the horizon?

We are also participating in the SATCOM Catalyst. This catalyst is dedicated to evolving the digital experience of SATCOM products by addressing complex data models across disparate systems and integrating with partners and clients in the satellite industry.  

Currently, satellite operators employ multiple data formats, leading to inefficiencies and increased costs. The industry’s challenge is further magnified by the inability to integrate with respective partners, adopting a common suite of interfaces. We address these challenges with our TMF ODA-compliant OSS suite, which offers a modular stack and leverages the TMF’s Shared Information Data model to unify data modelling. Moreover, our suite exposes ODA APIs for seamless integration with other applications across the operators’ estates.  

Lastly, we are actively involved in phase II of the AsyncAPI Catalyst. This aims to enhance the scalability and performance for operators with complex application suites. By adopting an Async Gateway and utilizing ODA APIs, we tackle potential “bottle-necks” and performance issues that arise when integrating with third-party applications.  

Could you give an example of this?

For instance, our components particularly those related to TMF Use Case 8, are employed to expose appropriate APIs to the Async Gateway, demonstrating the benefits of using industry standards and linking it into an Async Gateway.  

And a bottle-neck could happen when integrating into a multi-tenancy CRM system, north-bound as the CRM platform has set governor limits to handle APIs. Alvatross’s contribution is to employ some of their components and expose appropriate APIs (i.e. around TMF Use Case 8) to the Async Gateway. The catalyst can then demonstrate the benefits of using industry standards along with EDA and an Async API Gateway for communication’s governance and security control.

That sounds very interesting, indeed. So, since the ODA seems like it has become a collaborative hub for industry players. How has alvatross played a role in shaping these initiatives? Do you have any specific instances where alvatross has contributed to enhancing TMF standards or processes?

We try to contribute our knowledge and experience in deploying our products and executing projects in DSPs (Digital Service Providers) all over the world. Based on this background, we have identified gaps and enhancements to add to the standard in areas where it hasn’t yet reached its full potential. Then, we follow TM Forum's internal procedures to incorporate these contributions to the standard. We are currently involved in:

• Fallout management, specifically addressed through the IG1228's use case 11 I mentioned before. 
• Implementation of asynchronous APIs and EDA architectures in ODA, addressed through the AsyncAPI Catalyst phase II.
• Addressing the activation, configuration, and automation of services and network resources, through the IG1228's use case 8.
• Standardization of satellite communications businesses using ODA, addressed through the SATCOM Catalyst.
• Technical implementation and deployment of an ODA architecture, addressed through the ODA-CA.

Additionally, we actively embrace the role of TM Forum evangelizers, seizing any opportunity to spread the TM Forum principles to all of our customers and partners, and also helping them to adopt the standard.

Going back to the beginning of the interview, you mentioned our involvement in the Use Case UC011, which I find pretty interesting because it is all about solving pains and failures. Could you shed some light on its relevance within the telecommunications landscape? How does it address existing challenges to streamlining operations?

The use case 11 tries to highlight the gaps that the standard has in terms of fallout management within the product, service, and resource order execution. Currently, there are no assets in TM Forum that allow implementing a standardized strategy to face these issues, which makes it difficult to implement an ODA-based architecture with the ability to treat and recover from this kind of situations in an integrated and efficient way.  

We already knew this during the implementation of our Fallout Management solution in some clients. Based on this experience we decided to propose the use case in order to leverage the creation and definition of the necessary assets to face this issue. Regarding its relevance, we think that it is massive. Imagine trying to achieve autonomous operation systems without the ability to analyse, treat, and recover from errors automatically. It would be a major hurdle to overcome.

Looking at the bigger picture, how does the progress of this specific Use Case and the rest of ODA initiatives align with the broader objectives of digital transformation in the telecommunications industry?

Representatives of the most important DSPs over the world have a great involvement in the definition of the standard. You can find people from companies like Orange, Vodafone, Telefónica, BT, etc. in all of the TM Forum's working groups with a high, high degree of participation and involvement. Their influence steers the evolution of the standard towards the achievement of their own business goals, which align with the broader objectives of the industry itself.

Considering the journey so far, what excites you the most about the future of ODA? How do you envision these initiatives shaping the telecom industry in the years to come?

I think that we have some very interesting years ahead of us in which we will have to face great challenges to adapt our businesses to the technological development, and their accompanying social changes. Changes which are already taking place. It’s an exciting time, but it also means we’ll need to be nimble and proactive in our approach. For me, there are three crucial matters that will demand our attention:

• First, the practical implementation of all the work carried out within TM Forum in the real world, and how DSPs and vendors will adapt to these changes. And I’m not only talking about the technological side but also their business models and their organization.
• Second, the strategies that vendors will follow to differentiate from each other in a context where all of them will provide the same ODA components through a common Marketplace, and the criteria that DSPs will follow to choose their software providers. It will be very interesting to see.
• And third, how solutions based on AI technologies will contribute to implementing autonomous operation management systems.