Various telecom operators are rolling out paid-for API programmes, typically for charging against a phone bill, sending an SMS and so forth. There are some increasingly good individual operator strategies (eg Telefonica BlueVia) and the ongoing (but grindingly-slow evolution) of the industry-standard OneAPI from the GSMA.
However.... it's not easy. And not only that, but operators are increasingly going to find that payments for Internet APIs are two-way. They will (and indeed should) be paying for capabilities from Facebook, Google, Amazon and others, as well as (hopefully) making money from them elsewhere.
I first wrote about payments FROM telcos to Internet and so-called "OTT" players about 6 months ago. It's also something I suggested might happen in yesterday's post about OTTs potentially moving from being "dumb data centres" to charging differentially for priority access from some network operators.
I also asked people at this week's Rich Communications conference whether they expected to make more money from selling RCSe APIs than they'd likely have to pay out, for decent Facebook integration or other third-party services. I didn't get a satisfactory answer.
Today, another interesting development - a new charging structure for the Google Maps API. This one is interesting, as numerous operators use it for a variety of different purposes. Both the BTFon and Vodafone Wi-Fi Finder offload/connection clients use Google Maps to help me find the nearest hotspot, for example. T-Mobile's UK website uses it for helping customers find the nearest store. There are probably numerous other mashups as well.
While the operator may have its own location lookup from the network, or be able to extract it from a handset's integral GPS API, they often won't have a nice, familiar user-friendly map like Google's or Bing's. Especially where app development is being done by a small team decoupled from the main engineering units of the telco (eg a telco-OTT app skunk-works, or many WiFi add-ons), they will just tend to follow the usual paths taken by developers and use whichever APIs make sense.
But in a way, this is a good thing. Although the "balance of payments" for APIs may be negative in the short term (ie telcos paying more money to Internet companies than they get in return), that's not necessarily worrying.
Firstly, operators need to show that they "get" the whole API / web-services / mashup philosophy. By both buying and selling APIs, operators have a much better chance to show that they're serious members of the web ecosystem, rather than taking an arrogant stance that they are somehow entitled to "monetise their assets and capabilities" unilaterally, and have people flocking to their doors.
Secondly, operators should be using Web APIs for the same reason as everyone else - they help lower costs, improve time-to-market and add new and innovative features that improve the value of their own services. Similarly, they should be looking at tactically using hosted cloud services like Amazon's as well, not just trying to sell cloud services of their own.
Lastly, gaining greater experience with buying APIs should also yield a lot more insight into how to market, price, bill and support them, when they move into the API sales arena. That should yield better knowledge about good interfaces, speed and flexibility in evolving their API platforms, and the relative importance of "silo" APIs that just work, versus more complex federated or standardised ones.
However.... it's not easy. And not only that, but operators are increasingly going to find that payments for Internet APIs are two-way. They will (and indeed should) be paying for capabilities from Facebook, Google, Amazon and others, as well as (hopefully) making money from them elsewhere.
I first wrote about payments FROM telcos to Internet and so-called "OTT" players about 6 months ago. It's also something I suggested might happen in yesterday's post about OTTs potentially moving from being "dumb data centres" to charging differentially for priority access from some network operators.
I also asked people at this week's Rich Communications conference whether they expected to make more money from selling RCSe APIs than they'd likely have to pay out, for decent Facebook integration or other third-party services. I didn't get a satisfactory answer.
Today, another interesting development - a new charging structure for the Google Maps API. This one is interesting, as numerous operators use it for a variety of different purposes. Both the BTFon and Vodafone Wi-Fi Finder offload/connection clients use Google Maps to help me find the nearest hotspot, for example. T-Mobile's UK website uses it for helping customers find the nearest store. There are probably numerous other mashups as well.
While the operator may have its own location lookup from the network, or be able to extract it from a handset's integral GPS API, they often won't have a nice, familiar user-friendly map like Google's or Bing's. Especially where app development is being done by a small team decoupled from the main engineering units of the telco (eg a telco-OTT app skunk-works, or many WiFi add-ons), they will just tend to follow the usual paths taken by developers and use whichever APIs make sense.
But in a way, this is a good thing. Although the "balance of payments" for APIs may be negative in the short term (ie telcos paying more money to Internet companies than they get in return), that's not necessarily worrying.
Firstly, operators need to show that they "get" the whole API / web-services / mashup philosophy. By both buying and selling APIs, operators have a much better chance to show that they're serious members of the web ecosystem, rather than taking an arrogant stance that they are somehow entitled to "monetise their assets and capabilities" unilaterally, and have people flocking to their doors.
Secondly, operators should be using Web APIs for the same reason as everyone else - they help lower costs, improve time-to-market and add new and innovative features that improve the value of their own services. Similarly, they should be looking at tactically using hosted cloud services like Amazon's as well, not just trying to sell cloud services of their own.
Lastly, gaining greater experience with buying APIs should also yield a lot more insight into how to market, price, bill and support them, when they move into the API sales arena. That should yield better knowledge about good interfaces, speed and flexibility in evolving their API platforms, and the relative importance of "silo" APIs that just work, versus more complex federated or standardised ones.
No comments:
Post a Comment