It seems to me that we regularly go through a phase where everyone is talking about telco API opportunity. We’re regularly disappointed. Since stories on the notion seem to be on the upswing again, let’s look at the topic and try to work out what’s really happening, and why that which has already happened has largely missed the mark.
APIs represent the way that programs can access features and services of some sort. Every application uses them because operating systems and middleware are both sources of APIs and a universal piece of developer toolkit. We’ve used APIs for network services for decades; you could initiate a call, set up an over-the-Internet session, or a bunch of other things directly from a program by using APIs. A “telco API” is a way that telcos can expose services or service features to applications, but more and more the “applications” we’re talking about are some sort of higher-level service, and more and more we’re talking about APIs as something software developers would pay to use.
If an API is a cost for developers and a revenue source for operators, it has to deliver value to each. To be valuable to operators and developers, it has to generate revenue sufficient to cover costs and earn a reasonable profit. Since the price of an API is revenue to one and cost to the other, you have to strike a balance. To do that, you have to address two points, universality of availability and superiority over alternatives. The trouble is that both these points also have to be balanced between the developer and telco.
The GSMA’s Open Gateway initiative is targeting the first of these points. Higher-level service opportunities of the sort developers and OTTs would want to address aren’t likely to mirror the boundaries of operator markets, so there’s a risk that incompatible or unavailable APIs could create a credibility problem for these new services, or raise costs and deployment complexity. I think this is an important development, and the fact that so many operators have joined in suggests that operators overall feel the same way.
The second point has, perhaps, been peripherally addressed by the same initiative. The story I cited above point out that there’s work to expand operator services exposed by APIs into “geolocation, fraud detection and device information”. These features or capabilities can be provided without operator support, but there’s no question that the operator features can be highly valuable.
But what about the balance of interest, the tension inherent in the space? There’s no shortage of sources.
One that’s hinted in the article is the public cloud providers. A widely deployed service that draws on features from APIs published by a series of operators has to be widely deployed in a software sense, meaning it has to have resources to run on. If developers of future applications draw for APIs not only on operators but also on their cloud providers, those cloud providers are almost certainly going to act as agents to direct API calls for telco features to the right telco for the service geography. They’re not going to do that for free, so the margins available to the developer/OTT would be impacted.
Then there’s the question of whether these public cloud types might not decide to offer their own service. In fact, some of the services that could be supported by telco APIs are already supported by cloud providers. Unlike the telcos, these providers have little interest in promoting global standards for APIs; they’d love to be able to differentiate their stuff to command better prices. This means that a natural alternative to telco APIs could emerge, and could be available at a lower cost from a single partner, one OTTs are already comfortable with.
You can also wonder whether telcos themselves might feel competitive relative to the APIs. In market areas like the EU, which have wide mobility of users and a large number of competitive operators, it might be difficult for even a major telco to decide to break ranks with the GSMA approach, but surely areas like North America might see a push for per-operator API specifications to provide differentiation, because the major operators all cover whole countries and a single operator could well satisfy the “universal availability” constraint.
All of this, of course, depends on telcos exposing stuff that’s truly useful, which means going beyond connection services to things that are, in most cases, either elements of OSS/BSS systems’ scope or perhaps something that’s newly provisioned to be exploited. IoT presented a great opportunity, but most operators hunkered down on either the notion of making “things” into mobile customers, or device management. That the latter initiative largely disappointed but still made its way into the GSMA API plans is indicative of the conservatism of telcos and the way that impacts opportunities.
Telcos do have an asset they could play here, which is their own low internal rate of return on invested capital. Where IRR is low, the ROI a project can fall to and still be justified is also low, and that means that competition would face a fundamental economic barrier to market entry. That’s the sort of thing that could cement a telco role in future services, but for it to work the telcos would have to frame their solution and deploy before others bit the bullet and rolled out their own strategy. Nothing is cheaper as a service foundation than an investment you’ve already made.
I’d like to say that I believed telcos had a great opportunity with APIs, and I think I could if the positive of their IRR advantage wasn’t offset by their inherent conservatism. You’d think that a vertical market as wedded to the classic supply-side “build it and they will come” would be looking for things to build, but that’s not been true in the past and isn’t much more likely to be true today or in the future. Without some insight into where services are going, and willingness to jump out and get there in time to earn a role, telco APIs are an exercise in futility, and maybe even self-delusion.
