Telecoms operators have spent several years trying to decide whether and when to develop their own open APIs. Should they deploy open APIs for a limited number of (content) partners or are they a means of addressing a long-tail opportunity? Should they be viewed as something to be monetized in their own right? And do they represent an opportunity to secure a competitive advantage over rival telcos, or are they a means for the telco community as a whole to build new capabilities and create new roles?
At last week’s TM Forum Live event in Nice, nine leading operators – Axiata, Bharti Airtel, BT, China Mobile, China Unicom, NTT Group, Orange, Telefonica, and Vodafone – renewed attempts to build an operator-centric API alliance, agreeing to adopt 18 open APIs designed to boost operators’ digital capabilities.
Sound familiar? Six years ago another industry body, the GSMA, set up the (now defunct) Wholesale Applications Community (WAC) with the aim of creating common carrier APIs.
What has changed in the six years since to make telcos confident that the latest initiative will be more successful than WAC? And more fundamentally, is it a given that third-party developers will choose to exploit the telecoms API opportunity?
The big change in the industry since the last coordinated API initiative is in how telcos see technology and network evolution. Telcos are starting to adopt virtualized, cloud-based networks, and they want to take the same approach to building their own ecosystems as Internet companies. This will require the adoption of open APIs to allow third-party developers to build services that hook into telecoms networks.
Lester Thomas, group chief systems architect at Vodafone, spoke about the new API alliance at TM Forum Live. Vodafone’s vision is for third-party developers to use its APIs to help them build new products in areas such as smart cities, smart energy, and smart health. Vodafone will provide the scale, the capacity, and the end-to-end operations to enable these new products and will enter into revenue-sharing arrangements with third-party application developers.
As operators’ strategies have evolved so has their thinking about what types of APIs might be important to third-party developers. Much of the early activity was around the consumer market and APIs for voice, messaging, location, and billing. But as operators have refocused their innovation strategies on B2B and B2B2C, they have started to develop new APIs. According to Thomas, most of these APIs will be offered for free, but he specifically referenced big data analytics as one API that operators would seek to directly monetize.
One of the key challenges that operators are going to face in their API programs is persuading developers of the value in building applications that sit on and within their networks. Until now developers have made do with the public Internet and, where necessary, have negotiated peering deals or bought network-based services from operators.
Telcos also need to consider the cost and resources required for developers to adopt their APIs. When developers look at the telecoms industry, they see hundreds of national operators all with different strategies, priorities, and ways of doing business. One of the reasons WAC failed was because telcos couldn’t cooperate with one another. It created a common set of technology APIs, but there was no common distribution framework. A developer would have had to negotiate individual deals with each telco to gain access to its APIs and then work out a revenue-sharing model with each one.
Ovum expects that a common distribution framework will exist for the new API initiative. However, for developers to see the opportunity to create global applications that utilize telecoms network capabilities, more telcos will need to sign up to it. But for companies that are wholly focused on competition in national markets, cooperating with a competitor is never going to be easy.
Straight Talk is a weekly briefing from the desk of the chief research officer. To receive this newsletter by email, please contact us.