TM Forum Open API - POC for Orange Poland

Hycom’s PoC based on decoupled, cloud native applications and has been realized in cooperation with Google and Orange Poland. Google shares our understanding of the futureoriented commerce market and has made an investment to build a PoC of such a modern telco commerce solution for Orange together with Hycom.

The goal of the Google Orange PoC was to verify possibilities as well as advantages and disadvantages of replacing the monolithic e-commerce by a solution based on microservices modeled by the TM Forum Open Digital Architecture and its implementation on the Google Cloud Platform (GCP).

On the one hand, the work revolved around the implementation of a selected business process, on the other hand, it was very focused on technical areas, such as:

• investigating capabilities of the GCP platform,

• developing CI / CD pipeline,

• observability and service mesh,

• and finally, the implementation of the TM Forum Open API was supposed to reveal pros and cons of the standard.

Our project was carried out in the spirit of Cloud Native, using open-source equivalents of services provided by GCP, such as Prometheus, Grafana, Grafana Loki, Jaeger, Kafka. The whole stack was developed and maintained on our own (local) Kubernetes installation and later transferred to Google Cloud Platform.
This approach allows us to offer such solutions to our future customers in cooperation with any other Cloud provider like Azure or AWS as well as be able to offer it in an On-premise Private Cloud model.

We encountered many challenges, we had a lot of discussions especially regarding details of the TM Forum usage in particular business cases. TM Forum creates great living standards however it does not solve all custom telco business cases out of the box. We encountered many areas where TM Forum API does not yet address specific solutions for example like relations among:

• Privacy Agreements  

• Shopping Cart/Product Order.  

Thanks to TM Forum’s good community support, we were able to discuss our issues with competitive telco members in order to find a common way to handle such missing solutions. TM Forum APIs and their resources are still under construction, so we expect that many of the issues we faced will be solved in the future by a reference implementation or at least by Introductory Guides. However, there will always be some industry specific gaps which can be filled taking into account the specificity of the customer using the best experience of professionals like Hycom has.

All our decisions and conclusions during the project were documented according to best practices including Architecture Decision Records, C4, UML and OpenAPI / Swagger.

PoC Architecture for universal usage

In Hycom’s vision, Customer Experience is unified across every channel. It doesn’t matter whether this channel is called phone, tablet, smartwatch, chatbot, kiosk or voice assistant, the customer must be able to finish the purchase everywhere.

We built our PoC to be an accelerator for Composable Commerce where every additional third party module like Customer Engagement, Headless Commerce, Headless CMS, etc. can be easily added or make an exchange to any custom solution at a stakeholder request.

As a result, we can boast of 10 services, automatically deployable and fully monitored by collecting real time metrics and alerting, which together carries out the Telco client acquisition process. We also proved our understanding of TM Forum APIs’ architecture and competency in cloud implementation.

PoC conclusions in perspective of TM Forum Open APIs

Our main goal of the Proof of Concept was to validate pros and cons of TM Forum Open API as one of the components included in the Open Digital Architecture. TM Forum Open API was heavily advertised to be a perfect remedy for everything. As usual, the truth is always in between. There are technology agnostic REST based APIs which could be used in any digital service scenario. There are resources and descriptions however there are not enough guidelines on how they should be used. There are no documents with a reference architecture combining all elements into one piece for typical use cases. The most suitable adage we could say is “the more we get into it, the more complicated it becomes”. Why? During our PoC implementation, there were as many opinions as people, for example… which API request should be used in which case, should we save consents in the cart or maybe in the order, what resource object should be updated at what time, should we first update privacyAgreement or privacyProfile and many other.

TM Forum is currently developing high-level concepts but we would expect a reference implementation or at least an example of flows of API calls use cases. TM Forum is talking about it but at this moment, there is no reference implementation. There are few detailed Introductory Guides explaining API usage and new ones are being created each year but now they do not cover most of the scope of APIs created by TM Forum. We expect that it will take a few more years to cover the scope of the telco commerce area with examples. The good news is that in December 2020 TM Forum started project called Open Digital Architecture Component Accelerator for collaboratively developing a reference implementation.

Another good example is the creation of Shopping Cart API (TMF663). The Shopping Cart API was created three years ago. Product Ordering API (TMF622) was created in 2013 year before Shopping Cart API and TM Forum members used Product Ordering API to place orders however there was no Shopping Cart, and many members were asking about it. Then after four years in 2017 the Shopping Cart API (TMF663) was created.
In our PoC, we were operating on this Shopping Cart API. According to this API, when a customer enters the checkout process, this is the end of the cart lifecycle and the start of the order lifecycle. All the customer data and other checkout information are collected on the order object. From our perspective, the cart should be a collection of items which can be easily passed to an order. To our surprise,  it turned out that the cart object and the order object are completely different and not compatible. We had to map each attribute from the cart to the order manually. It looks like the Shopping Cart API was written by completely different people than the Product Order API with very small consideration regarding compatibility between these APIs.
Moreover, this Shopping Cart API does not fit for telco businesses. It fits for standard retail business where customer does simple checkout. For example during the checkout process, prices cannot be changed, customer cannot add anything to the basket, there are no discount consents like for e-invoice etc. In order to have such functionalities, the Shopping Cart API must be customized in many places. At the beginning of the project, we were even wondering to use Product Order API instead of Shopping Cart API immediately when users start checkout, but it also brings some limitations which must be removed by customization…

During our APIs implementation phase, we spent a lot of time discussing whether we should keep a 100% compliancy with the TM Forum specification and map required attributes into existing attributes of an API or whether to customize these APIs and add new attributes and resources where necessary. After deep analysis, we decided that mapping attributes to not dedicated ones is not effective, costs a lot of effort in the conceptual phase and also results in misleading names of attributes used for different purposes like originally designed. Therefore, the decision was to customize each API where it was necessary to achieve business requirements in a more reliable way.

Nevertheless, we see the future in TM Forum as a unified architecture with API accelerators for various functional areas. However, at this point of time, implementing TM Forum Open APIs requires lots of discussions and investigations regarding its technical usage. We believe that TM Forum Open API based on Open Digital Architecture is the future in the telco industry because overall it provides unified and thoughtful standards. At Hycom, we not only understand it but thanks to our involvement, we know how to compose it into a functional working system.

Summary

Composable BSS solutions in the Telco industry based on TM Forum Open Digital Architecture in connection of proper technologies are the key to be the leader on the market. However, please be aware that building solutions based on microservices has also some crucial drawbacks related with distributed architecture and its management. TM Forum APIs seem not to be mature to address many of the telco functionalities without any customization. The knowledge of TM Forum standards, being up to date with its changes and challenges as well as active involvement in cooperation, gives Hycom the ability to identify and avoid risks.

 

Recommendations for Telco companies

• Focus on the TM Forum Open Digital Architecture and transform monolithic applications into microservices to gain flexibility in development, scalability of traffic and get rid of high license fees,

• Be careful with the implementation of TM Forum APIs without experience because they may not to be mature enough,

• Design their apps in a way that your customers can finish their purchases in every channel, even on their fridges or watches,

• Decouple business functionalities, separate frontend from the backend, evaluate Cloud-Native approach to rapidly increase time to market of new business features from months to weeks,

• Listen to global research and advisory companies like Gartner but also consider recommendations of experienced professionals in telco consulting and development.