Money has always been thought of as the source for all evil, but without it not much good happens either. For CSPs the perennial battle to maintain revenues means they have to keep coming up with new ways of generating it, and that is not always easy or without evil.
Yes, we all know voice revenues are declining even though voice traffic itself is probably increasing thanks to VOIP apps on smartphones and via social networks., none of which translates to money for the carriers that handle that traffic.
Oh yes, that’s now data traffic that customers pay for, usually in one lump sum for one great lump of data each month. What it is made up of is of little interest because the cost of tracking it or billing separately for different types of traffic is hardly worth the effort, or the cost – presuming it is even legal under pending net neutrality rules.
So the logical alternative is to attract more customers or provide as many products, services or bundled add-ons as possible to increase the revenue per user. Increasing revenues always seems to imply getting more money from customers, but there is a limit to what they can afford to pay, and if you squeeze too much out of them they either stop paying their bills or find a cheaper option.
Some enterprising networks operators have looked into peering arrangements with digital service providers or DSPs (a.k.a. OTT players) offering prioritized traffic for services like video. These have since fallen foul of the net neutrality nincompoops who claim that this disadvantages other network users that have to settle for plain old internet speeds, whatever they are.
Telecommunications must be the only industry that cannot differentiate prices for different services. Everybody is, according the ‘new’ rules entitled to Ferrari speeds and quality at Hyundai prices.
Telco CEOs are now publicly questioning the tightening of internet rules that only seem to apply to those providing the networks, and not those using them. For DSPs there is no restriction on what level of service they provide over the networks to their customers, no restriction on the bandwidth they take up and certainly no restriction on what they can charge for their services.
So, why aren’t CSPs acting more like those DSPs and looking more closely how they make money, unfettered by regulations? Better still, why not emulate some things they do to make money that may avoid any regulatory policing.
Jouko Ahvenainen, in a recent article, pointed out that “successful internet giants, like Salesforce, Amazon, Google, Twitter, and Facebook, have been active to offer APIs to third parties. Salesforce has earned more than half of its revenue through APIs, not from its own user interface. Twitter, Netflix, and Google handle billions of transactions through APIs daily.”
He goes on to point out that “we are moving to a new era of the API economy when APIs are no longer the territories of internet and mobile companies alone, and instead are implemented in basically any industry.”
Let’s hold that thought for just a bit longer. Aren’t CSPs actively opening up access to their core systems to attract new wholesale customers and offering the benefits of their vast experience at managing services and charging for them in real-time?
But they are talking about charging for these as services based on volumes, revenue or margin sharing and cost-plus arrangements. This is old school thinking and doesn’t necessarily reflect the true cost of providing the service – something many CSPs are actually unable to calculate themselves.
These ‘finger in the air’ methodologies are not only hard to justify they often lose deals, but if CSPs were to talk to the DSPs in a language they comprehend, then maybe deals could be done for the benefit of all.
And how more equitable could that be than the API mantra Jouko suggests. Every system the CSP opens up has a corresponding API. Instead of charging for the API or the use of the system, why not charge for every API call, or transaction that utilizes that API. It could be a very small amount, sub-cent price per call, but when millions of calls are made the value rises.
If it is true that tracking IoT data will be difficult, as some claim, then it would be reasonably simple to track the API calls, very easy to collect and price them and it would be a truly equitable way of charging for the CSP’s services. With the IoT tsunami about to hit, it could also prove to be the best money-spinner ever to benefit the network operators.
Tony, excellent article. One very important aspect in this ‘new API business’ is that it is not only to have APIs technically available, but really make it easy to use them, and also have supporting business models to scale up the use of them. One could say they have an API, but in practice someone who wants to use it needs a long agreement negotiation, $10M+ project from a System Integrator and high usage fees to use them. That is not “open API economy”. The model should be more like a talented coder can implement a solution to utilize the API in a few hours based on public documents, no high fee to start the service and then a reasonable fee based on the value (transactions or API calls). That is the way really scale up the use, offer cost-effective solutions and really open it for innovations. An important disruption is to enable new parties to utilize the service and really find new innovative solutions. So, it really needs new business models to get it work, but often also culture changes in the organization, and the culture change can be the most difficult part.
I would argue from experience that there is a great deal of talk about using APIs & an equally great lack of knowledge – especially in the CSP industry – on how to use them. I don’t mean in terms of a lack of conceptual understanding or business ideas – though that may be true – but a lack of knowledge on how to write code properly or how to leverage API routes even when they are very well defined. I have to imagine the same can be said for application of technology like real time charging. So the gap between conceptual and practical understanding in this case is very broad – enough so to prevent real progress.
Firstly, what a good article written Tony, very thought provoking.
Way back in 2015 there were only a handful of API Frameworks, now they are springing up all over the place – if you code in PHP/Laravel for example “Apiato” and once you have your end-points sorted and documented, it squirts out 20 types of code ready for some copy pasta + build business logic around your App)…Voip, sure…IoT also??? It’s just a websocket.
You can control microservices or API’s and charge per compute or batch as one desires **Dream up any recurring revenue plan you want?** or keep it in-house for private use.
I’ve experience in the field selling API’s for years and often the demand is for real-time data but also security is high on the agenda as you mentioned this in your article. More recently, I’ve had projects that utilise blockchain to ensure transactional data is safe.
These days the API is the product, so any business whether you are BP or Jack’s tyre fitter can make API, or use one (they use them all day without realising what an API is – e.g Google Maps)
The way to make money from an Private API is to expose “SOME” data to suppliers, customers, improve process somehow…make it more slick to find and do business with you, reatain staff – what do you want it to?
I didn’t know it at the time, but way back when EDI was a thing (2000’s) I made my first API (EDI is basically an API reaching into the DB). Most of the industry for tech suppliers was based on EDI – working at vendors we ‘posted’ product data to resellers and distribution customers which ensured our products featured on their website(s) and where appropriate the consumer would search, find & buy.
Trust me, it took me 2 to 3 full days to ensure the RIGHT data was being sent …before we enabled EDI. One of my clients back then was Amazon, without EDI or API’s Amazon would break – how to make money from API’s I suggest talking to Mr Bezos?
Jack’s tyre fitter’s have the canvas to design or consume API’s for their business improvement. You can bet your bottom dollar Jack hasn’t a clue about accounting (or whatever)
So what if he pressed a button on his phone when he finished fitting tyres – that sms’d his client, who pays online and collects his car and leaves feedback….all that data easily dumped into accounting API (Quickbooks)
You can’t really put a price on an API’s value until the business goes up, or clients are happier, or process bottlenecks stopped, reporting is made easier, staff are more motivated, emails go on time etc etc.
I love modern Rest API’s and I think they will soon become the essential business asset for anyone to invest in. But your post is from 2015 and the API market has moved on a lot in 5 years, have CSP’s managed to get a handle on it yet?