Last week (post published May,29/2016) it was announced a manifest from the world’s largest Service Providers to promote the suite of APIs, following the standard OPEN API proposed by TM Forum (https://www.tmforum.org/press-and-news/open-apis/). Despite the interest aroused in the industry, it is early to known if this is another technological standardization initiative that will not reflect on new Operators’ business models.
The standardization of APIs for telecommunications network resource exposure began in the 2000s with the standard OSA / Parlay (3GPP Release 99), followed by Parlay X (3GPP Release 6) and culminated with the GSMA One API and other derivative initiatives (e.g. Mobile Connect). None of these standards had widespread adoption. The key question is what is the real obstacle for standard API exposure in a common environment with broad acceptance by Service Providers, especially after the experience gained over the past initiatives?
The initiatives mentioned were primarily focused on core network features such as call control, messaging or location. The evolution of 3GPP and GSMA initiatives did not change this scenario being basically a technology update, from CORBA to SOAP and lastly REST. Such technological standards were not associated with comprehensive business models and have been adopted in a limited way by few players.
By the same time, Web 2.0 services, web search services and social networks had grown in traffic and acceptance. This new service category enabled the direct access of new companies to customers, including their relationships, behaviors and even their location. As a result, information on communication habits, consumption and customer database previously restricted to a limited group of companies, including the Service Providers, have become commonly available and easily captured, beside the privacy discussion.
With the next wave, the OTT (Over the Top) app introduction was made possible due to technological developments in mobile data networks and smartphones processing power. Now individual apps running on top of handsets’ operating systems can deploy and use proprietary messaging, location and call control, among others resources. The OTT apps allow the creation of new forms of communication above the network Operators’ control plane. It was a paradigm shift; developers now have APIs available on the device’s operating system and from any cloud service. Telecommunications services could now be created without the use of network Operators’ API, which were regionally restricted and no always available. The OTT apps can have worldwide reaching using basically two SDKs sets (Apple and Google).
Concomitant with the above revolution, quite a few Operators had dared to create own API exposure programs and SDK aimed at new demand for long tail services. The business models gap for developers to get access Operators specific features ended up being filled by external players that sell and expose their own API (e.g. Twilio, Mobyt, etc.), using the APIs or direct connection to different Operators.
Returning to the new initiative, the standard TM Forum’s Open API is described as an API family that enables end-to-end services management and throughout their life cycle in an environment where multiple partners are involved in the services delivery. The standard focuses on the business aspects (IT) and not on network features, seeking to simplify the integration processes, the DevOps adoption and new virtualization technologies (SDN and NFV). In a way, this is a standard that aims to belatedly fulfill a gap left by previous initiatives.
In my conclusion, we are again seeking a technological framework for the development of APIs for network operators, now in a model focused on business processes. But the centerpiece of a complete and comprehensive API ecosystem leaded by converged service providers, is not being treated and continues to be the result of individual initiatives.