APIs (Application Programing Interface) in telecoms have a long history, starting in 1998/1999 when Telenor began its Content Provider Access API program and the launch of the Parlay API standards group. With such early beginnings it would be fair to expect APIs in Telecoms to be as, if not more, pervasive than most other industries. However, for a variety of reasons Telecom’s adoption of APIs has not been as rapid as other industries, e.g. web-based service providers. In part this is related to the characteristics of the Telecom industry which was general quite self-sufficient in delivering services to its customers.
However, as technology has evolved, telecom services are increasingly embedded; for example in applications on smartphones, in web browsers, in business processes, in the check-out of online stores, and in the SMS appointment reminders from doctors and dentists. Technology change now requires operators to embed their services across many ecosystems, APIs make that possible. Competition from a variety of sources, not just web-service providers with Over The Top services, but also handset suppliers with bundled services like iMessage and Facetime, and enterprise software suppliers and integrators embedding communications into their products means Telcos must operate with greater agility and efficiency to remain competitive, APIs make this possible.
The recent failed focus on long-tail developers in developed markets prompted by the success of Apple and Android’s app stores should not been seen as a failure on the relevance of APIs to Telecoms. Rather a failure of a particular business model, simply operators cannot match the direct access to a large engaged customer base (likely over 1B in 2013) willing to pay on just two operating system platforms, Apple and Android.
2012 was a watershed year for Telecom APIs; enough time had been given to building the long-tail business model to understand it was not a viable stand-alone business model for telecom operators. For most operators, especially those in developed markets, it was clear; the money wasn’t in the long-tail, as was presciently stated by Jose Valles the head of BlueVia at the SDP Global Summit in September 2011.
Instead, Operators like Telecom Italia, Portugal Telecom, and Telefonica were now able to share what is working: it is using APIs internally and with partners. Telecom Italia shared at the SDP Global Summit in 2012 that over 99% of the API calls came from internal and partner applications, less than 1% came from long tail developers. An important point is not to close the door to long tail innovation, rather to make an investment proportional to the expected return, and it’s clear the investment must focus on the internal and partner applications of APIs for business success. The business success for APIs is measured in operations savings such as reuse (lowering costs of new services by up to 95%) and agility (shortening time to market from years to months); and functions (new revenue) such as enabling cloud based services and migration to cloud services, mobilization of business applications, and working with partners to deliver new value.
Layer 7 is the leading independent API management provider, as recognized by Gartner as a Magic Quadrant leader and Forrester as a Wave leader. The company’s products and services help approximately 300 organizations worldwide, across telecoms, governments, healthcare, web service providers, financial services, and many more verticals open APIs to developer communities, securely connect applications to cloud services, expose internal information assets to mobile apps and bridge departments and partners through SOA (Service Oriented Architecture) style integration. We have jointly written a Telecom focused whitepaper, “API Management and the Business of Telecoms”, that provides a review of Telecom APIs and how Layer 7 provides the leading independent solution.
Layer 7’s leadership is built on its 9 years of excellence in APIs since 2003. The case studies reviewed in the whitepaper show that API success rapidly leads to complexity, and Layer 7‘s approach is focused on simplification in managing APIs. Enabling developers of all types (internal, partner, long-tail, business focused or technology focused) to easily discover and consumer APIs relevant to their needs. As those businesses are running a part of their business through those APIs providing the tools to monitor performance and usage.
API life-cycle management processes become critical to operations, and Layer 7‘s solutions are built to support those processes around API life-cycle and global versioning, enabling APIs to evolve to support innovation while avoiding existing uses of the API to make updates. Through Layer 7’s government, financial services and telecoms deployments they are able to support the heterogeneous performance and availability requirements to optimize implementation and not waste resources. In supporting the many API consumers, security and SLA (Service Level Agreement) can only be effectively managed through policies. And finally, APIs need to evolve quickly to win new business opportunities, and Layer 7 enables the fast abstraction, adaptation and orchestration of new APIs.
Currently mBaaS (mobile Backend as a Service) is generating much interest with telecom service providers and enterprises, in aiding the development and deployment of applications and services such as supporting the mobile workforce and BYOD (Bring Your Own Device). It solves the mobile challenges of: Identity, Security, Adaptation, Optimization and Integration. What is unique about Layer 7’s mBaaS solution, called the Mobile Access Gateway, is its deployed today for customers such as Amerigroup , Alaska Airlines, Eli Lilly, and Northern Trust. Layer 7’s mBaaS is not slideware, it’s deployed and available in a range of configurations that meet the needs of Telcos and their enterprise customers, enabling Telcos to offer cloud, hybrid and on-premise solutions today. This weblog reviews the importance of APIs to enterprise mobilization in a recent article, “Mind the Mobilization Gap.”
No Telco can afford to omit Layer 7 from their API management evaluation, APIs are now strategic to the future success of telecom service providers. I recommend you spend the time to review the whitepaper, “API Management and the Business of Telecoms”.
I disagree with the point of long tail does not matter 🙂
a) We may remember how Microsoft Office become “de facto” standard thanks to everyone learnt to use it using very cheap (or even cracked) licenses, the the companies which can pay choose it as their tool for docs, spreadsheets, presentations etc. Then, an API easy and friendly to be used by the long tail will produce experts that could promote/lobby the use of that API in their working environment.
b) The API business is not only the business of the API usage. In telco world it could generate additional telco “user identities” revenues, you may need to deploy your app/use case. Long tail means a lot of extra lines/identitities just to have deployed the use cases created by long tail developers.
I think that both groups of API users may be stimulated simoultaneously from the very beginning, enterprise and long tail. We may think in telco API companies exposing SMS and Voice as REST that won contracts with Fortune 500 companies using the “referral” of thousands of cases implemented by the long tail community.
Disagreement is good, without it our thinking can never get better 🙂 Though to be clear in the whitepaper I do not say the long tail does not matter, rather we need to focus where the money / success is.
Given the failure of most telco API initiatives that focused on the long tail and the relative success of those that focused on internal and partner applications, the facts would appear to back the assertion that we’re better focusing investment where telcos have relevance. BlueVia is achieving significant success with its mobile payment service (enabled through an API) now its focused on partners rather than the long tail, offering mobile billing as an option at the check-out of on-line stores. This isn’t long tail, this is mid-tail and BlueVia is also building momentum by partnering with the likes of Telenor, Etisalat (likely as they’re already partnering with Telefonica Digital) and others.
By 2013 there will be >1B customers / devices in the Android / Apple ecosystems with their direct channel to a large engaged customer base and free APIs makes even telcos the size of AT&T and Verizon look insignificant in comparison. If RIM and Microsoft are struggling to gain long tail developer attention, how can operators with their less relevant pitch for the long tail garner any interest? So let’s park the consumer-focused long-tail, not exclude it, but rather focus on building business and services enabled by APIs where telcos have a chance.
Microsoft was an enterprise monopoly, see link below, their OS APIs made it easy for developers to create apps that would work on most desktops. Telcos do not have the monopoly Microsoft enjoyed. Also Microsoft’s monopoly is now being eroded as it failed to innovate and rather milk its monopoly. Let’s face it the OS has stagnated for a decade+ and increasingly we see Mac books and tablets being used instead of laptops. This link shows it quite nicely: http://www.businessinsider.com/chart-of-the-day-consumer-compute-shift-2012-12?nr_email_referer=1&utm_source=Triggermail&utm_medium=email&utm_term=SAI%20Chart%20Of%20The%20Day&utm_campaign=SAI_COTD_120712
APIs are the easy bit. They are simply a bit of technology. It’s all about the business / services enabled by that technology. For example in the BlueVia case it’s the mobile payment service that is generating value, N.B. is needs to include fraud management, refunds, currency management, tax management, customer support, etc. Not just a billing API. To call this simply an API, is like calling a car a steering wheel. The steering wheel is essential, but you need much more than that to make a car.
So I’m not saying the long tail doesn’t matter, rather we need to focus where we can build a real business as telcos, and of course in doing so promote open innovation as we simply can not think of all the cool ideas people can have. However, the cool ideas are likely to be delivered to a market of >1B rather than an unclear telco market. In time this position could change if say RCS can achieve customer adoption and telcos work together – its the later bit I think is the more unlikely. But for today, lets build a business based on what’s working as telcos.