Login
Register
The journey to transform IT systems with goals of significantly reducing costs and complexity starts with digitizing customer-facing systems because they are critical to running the business. These systems also help communications service providers deliver personalized services.
Dawn Bushaus
Using APIs to ease integration headaches
The journey to transform IT systems with goals of significantly reducing costs and complexity starts with digitizing customer-facing systems because they are critical to running the business. These systems also help communications service providers (CSPs) deliver personalized services. The graphic below shows the three drivers for using Open APIs that ranked highest in the survey we conducted for our recent report, How to lead in the Open API economy. About half of all CSP respondents said reducing costs and complexity are very important drivers.
In the past, systems that handle product, order, revenue and customer management collectively have been called business support systems (BSS). Now, many CSPs refer to them using terms such as “engagement management” and “core commerce management”. This is the terminology TM Forum uses in describing the Open Digital Architecture (ODA). No matter what they are called, simplifying customer-facing systems is paramount because CSPs’ subscriber and revenue growth is stagnant. To compete they must focus on improving loyalty and upselling customers by delivering personalized experiences on par with those delivered by digital natives. At the same time, operators must lower their operating costs through automation. CSPs’ current IT environments consist of many commercial software applications that have been modified over decades. These often either have overlapping functionality or present gaps in the end-to-end customer journey, which operators must address through customization. As a result, operators spend millions of dollars and huge amounts of time on complex integration and further customization whenever changes are needed. In addition, CSPs face integration headaches when they acquire other companies and must merge completely disparate systems. Many suppliers are now selling customer-facing systems that include support for TM Forum Open APIs, and CSPs often request Open API compliance in any new systems they procure. But many implementations of Open APIs so far have consisted of “wrapping” suppliers’ legacy APIs with Open APIs. Often this is because CSPs are building digital experience layers across markets, but they are modernizing back-end systems of record (also known as operational support systems – OSS) more slowly.
Simplification is a chief goal in wrapping systems. Most CSPs spend 80% of their IT operations budgets on integration and customization, leaving only 20% for innovation. They are hoping to reverse this 80:20 rule. Deutsche Telekom is using the Open APIs in this way. The company is the top downloader of Open APIs and an active ODA collaborator. Its European division has used Open APIs to introduce a single self-care mobile application for consumers called OneApp across Europe. The German division is also using Open APIs for customer-facing systems. “There are thousands of initiatives looking at the TM Forum Open APIs within Deutsche Telekom, varying from just one system architect using a single API to very big projects,” says Alexis de Peufeilhoux, Senior Enterprise Architect, who works in the company’s German operating company. “Even so, we have one effort to provide Open APIs at the enterprise level, and this is where we are currently concentrating on developing the APIs we need for the commercial front-ends on customer care, such as online shopping and the call center.” The goal of the enterprise Open APIs is to wrap still monolithic business support systems (BSS) with a decoupling layer to increase agility and improve customer experience.
“Standardizing on the Open APIs reduces complexity,” De Peufeilhoux explains. “They bring a common neutral language that everybody can speak to the others within the company. And so, if I use a Customer API, most of my colleagues now already have an idea what that is because they are currently adopting the TM Forum vocabulary and data model.”
Vodafone Group, the No. 2 downloader of Open APIs and an ODA leader, is guiding transformation of operating companies in 24 markets globally as part of a strategy called “Flip IT”, which got underway in 2015. A chief goal has been creating digital experience layers in the operating companies.
“We are undergoing a two-phased transformation,” says Dr. Lester Thomas, Chief Systems Architect, Vodafone Group. “The first stage is creating a digital version of our own business, and the second phase is developing digital ecosystems… If you do the first phase right, all the investment helps you become more agile.”
Doing it right means investing in people who understand the value of APIs and will be devoted to developing the API strategy. Thomas says that in the Vodafone companies where Open APIs were adopted first, the common success factor was that the local team had API evangelists. The operating companies are transforming digitally in strategic phases, driven by local challenges. For example, one of them needed to integrate several acquired fixed-line companies, so they wrapped legacy systems using Open APIs so that they could sell quad services quickly and effectively. Two others were greenfield operations, so they started with an Open API strategy. Vodafone UK is an Open API success story in terms of quantifiable benefits. With its digital experience layer, the company has increased digital sales by more than 50%, implemented end-to-end automation for more than half of all customer interactions, increased sales conversions by 30%, and has realized a 3X improvement in NPS. Vodafone Group is also beginning to deliver platform-based services using Open APIs and ODA, which we’ll cover in an upcoming article.
The move toward a true platform-based architecture requires using Open APIs not only in customer-facing systems, but also in the production layer where systems such as orchestration and service assurance interface with network components. CSPs can then open these systems to partners and customers using Open APIs. This can include adopting network-as-a-service (NaaS). NaaS is a flavor of software-as-a-service that enables CSPs to provide network experiences that are similar to cloud computing, in that customers can use self-service portals to make changes, with service activation executed on demand. NaaS can be viewed narrowly as a way for CSPs to deliver enterprise connectivity services like SD-WAN over fixed networks. But increasingly, some operators are adopting NaaS as a transformative architecture that builds on network functions virtualization and software-defined networking. As CSPs deploy software-defined 5G core networks, it will be possible to deliver NaaS as a mobile service using network slicing. The graphic below shows the simplification that is possible when CSPs adopt a layered NaaS architecture.
In this approach, CSPs can use intent-based management, where operational domains abstract the complexity of the network at a high level and expose network services (service function chains made up of interconnected virtual and/or physical network functions) through an Open API like the TM Forum Service Configuration and Activation API to an orchestration system. The goal then is to manage the lifecycles of these network services autonomously using the customer’s intent, policy, closed control loops, data analytics and AI. Importantly, the network services exposed and used for products sold to customers can be reused without having each product defined and associated with the complete resource definition for each network service. Instead, products are linked to network services through Open APIs, and it is the responsibility of the operational domain to decide how that network service will be delivered. This is an excerpt from our report How to lead in the Open API economy. Be sure to check out the other articles in this series listed below and download the full report. The next excerpt will look at how CSPs can use Open APIs to develop platform-based business models.
