Ericsson aims to make it easier for CSPs to implement Open APIs
Ericsson’s Ignacio Mas, Senior OSS Expert, and Aurelie Zanin, BSS Product Manager, explained why the company created an exposure layer to help communications service providers implement Open APIs.
11 Mar 2021
Ericsson aims to make it easier for CSPs to implement Open APIs
As the telecommunications industry shifts to cloud native principles and adopts microservices, open source technology and standard APIs such as the TM Forum Open APIs, new approaches to classic integration challenges are becoming possible. But integration is also becoming increasingly complex. During a recent TM Forum Global Architecture Forum webinar, Ericsson’s Ignacio Mas, Senior OSS Expert, and Aurelie Zanin, BSS Product Manager, explained why the company created an exposure layer to help communications service providers (CSPs) implement Open APIs.
According to Mas, integration complexity is multiplicative because it is necessary throughout CSPs’ organizations. For example:
Many CSPs are transforming their IT architectures from siloed and tightly coupled to distributed, reusable and loosely coupled. The demand for integration across operational silos has increased substantially because of transformation, which creates practical challenges for integrators.
Ericsson turned to TM Forum Open APIs to eliminate the costly and complex orchestration and data translation related to past integration approaches. The company not only had to create interfaces with and across products, but also needed to be able to expose capabilities to customers and to customers’ customers, said Zanin. The idea is to be able to expose operational and business support systems (OSS/BSS) functions like configure, activate, terminate, notify and report status through a framework based on standard APIs.
Integration is also happening in the context of digital transformation, however, so changes in systems and integration environments are continuous and must evolve as the whole architecture changes. Zanin said the key to shielding each moving part from all the changes in surrounding systems, processes and integrations is to decouple the exposure layer, again through a standard framework.
Ericsson built an exposure framework based on TM Forum Open Digital Architecture (ODA) that is applicable in any transformation or integration scenario. Mas describes the ODA as “the framework we need to evolve how we think about API exposure and enabling capabilities for our customers.”
ODA allows all the integrated systems components to speak the same language using Open APIs. It provides tools to make API development and integration simpler and provides a full microservice architecture to expose all of Ericsson’s back-end systems capabilities.
Ericsson implemented 15 TM Forum Open APIs in 2020 using the new framework, all of which are now reusable components.
One example she provided was of a Tier 1 operator that aimed to transform its consumer pre-paid line of business within a strict delivery timeline. The pre-paid product offering was updated with a new digital CX and new tools to make adding customers, topping up accounts, and accessing support easier via web and app.
Making this happen involved more than 40 system components and required definition of 44 distinct use cases. The common language of the Open APIs “helped us go faster,” Zanin said, adding that the framework made it possible to “harvest everything we created for the customer back into the product” which further reduces integration risk and cost.
An important takeaway is that in a large IT environment made up of multiple suppliers’ systems, the components will reflect different levels of maturity when it comes to Open API implementation, and not all will be compliant. But going back to complex, custom integration work is unnecessary, Zanin said.
Small, microservices-based connectors can be used to provide integration between Open API-compliant and non-compliant components, and the connectors eventually can be retired as all the integrated partners move toward a target architecture aligned with TM Forum APIs and ODA principles, she explained.
According to Mas, integration complexity is multiplicative because it is necessary throughout CSPs’ organizations. For example:
- Business integration is increasing because CSPs want to interact through APIs with partners, customers, and customers’ customers. Mas said enabling this type of integration is a key to spurring service innovation across all players in the value chain.
- Customer experience integration impacts the processes that control how services and networks respond to customers’requests and commands. As CSPs work to automate more customer experience (CX) features, the demand for CX-related integration increases.
- Operational integration brings transitional challenges. As operational systems are in mid-transformation, “we need to have clear and stable integration points to facilitate a smooth transition [from old to new technology],” Mas explains.
- Standardization integration has also become necessary. Mas explains that it’s important to help standards converge in order to bring forward reusable solutions.
Common language
Many CSPs are transforming their IT architectures from siloed and tightly coupled to distributed, reusable and loosely coupled. The demand for integration across operational silos has increased substantially because of transformation, which creates practical challenges for integrators.
“All of the transactions and orchestration to get all the silos to talk each other was becoming much more complex,” Zanin explained. “We needed a common language.”
Ericsson turned to TM Forum Open APIs to eliminate the costly and complex orchestration and data translation related to past integration approaches. The company not only had to create interfaces with and across products, but also needed to be able to expose capabilities to customers and to customers’ customers, said Zanin. The idea is to be able to expose operational and business support systems (OSS/BSS) functions like configure, activate, terminate, notify and report status through a framework based on standard APIs.
Integration is also happening in the context of digital transformation, however, so changes in systems and integration environments are continuous and must evolve as the whole architecture changes. Zanin said the key to shielding each moving part from all the changes in surrounding systems, processes and integrations is to decouple the exposure layer, again through a standard framework.
Ericsson built an exposure framework based on TM Forum Open Digital Architecture (ODA) that is applicable in any transformation or integration scenario. Mas describes the ODA as “the framework we need to evolve how we think about API exposure and enabling capabilities for our customers.”
ODA allows all the integrated systems components to speak the same language using Open APIs. It provides tools to make API development and integration simpler and provides a full microservice architecture to expose all of Ericsson’s back-end systems capabilities.
Reuse and de-risk
Ericsson implemented 15 TM Forum Open APIs in 2020 using the new framework, all of which are now reusable components.
“The framework let us be faster and lower risk,” Zanin said. “If we are faster to implement those Open APIs and decouple the system, then we will be faster to enable our customers’ transformation projects and to lower their risk.”
One example she provided was of a Tier 1 operator that aimed to transform its consumer pre-paid line of business within a strict delivery timeline. The pre-paid product offering was updated with a new digital CX and new tools to make adding customers, topping up accounts, and accessing support easier via web and app.
Making this happen involved more than 40 system components and required definition of 44 distinct use cases. The common language of the Open APIs “helped us go faster,” Zanin said, adding that the framework made it possible to “harvest everything we created for the customer back into the product” which further reduces integration risk and cost.
An important takeaway is that in a large IT environment made up of multiple suppliers’ systems, the components will reflect different levels of maturity when it comes to Open API implementation, and not all will be compliant. But going back to complex, custom integration work is unnecessary, Zanin said.
Small, microservices-based connectors can be used to provide integration between Open API-compliant and non-compliant components, and the connectors eventually can be retired as all the integrated partners move toward a target architecture aligned with TM Forum APIs and ODA principles, she explained.
To learn more about TM Forum’s Open APIs and ODA, please contact the Forum’s CTO George Glass.
