Telcos, don’t give away your strategic advantage!

“Those who cannot remember the past are condemned to repeat it,” wrote George Santayana in 1905.

That’ll be us, telco industry, if we don’t learn from what happened with Twilio and CPaaS APIs and do something different this time around with network APIs. So, let’s refresh our memories.

Remember the Twilio

Programmable connectivity APIs aren’t new. The first time around, telcos built their own CPaaS APIs. Each team designed its own API signature, and didn’t think about the experience software developers would have when using this product. Sending a simple one-time-passcode (OTP) SMS, for example, was a total pain in the ass. Enterprise developers had to:

• Sign a commercial agreement with each telco—which often took a long time and required a significant upfront commitment;
• Then learn each telco’s different signature for sending an OTP API; 
• And then write and maintain the code to send an OTP API for each network to ensure the message was delivered to the intended recipient.

These first CPaaS APIs were TELCO-CENTRIC, and not DEVELOPER-CENTRIC.

Twilio recognized that and flipped the script. It optimized its product experience around the developer by offering:

1. A single, common API for each use case with an easy-to-use interface and great documentation, eliminating the need to learn, code, and have agreements in place for each network’s APIs; and

2. It built a “multiplexer:” a black box that abstracted away the complicated work of identifying which network the subscriber was on such that delivering a message to the recipient’s network required only one line of code.

Twilio took the pain out of the process for the developer. Not surprisingly, the company was a huge success. It now has a $12 billion market cap from largely SMS revenue that used to flow into telco coffers.Meanwhile, we’re asking ourselves, why we can’t have that? It doesn’t seem fair. Well, with network APIs, we have the opportunity to take back what’s ours. Instead, I fear it’s going to be déjà vu all over again.

The promise and risk of Open Gateway

It’s 2024. MWC is a month away. It’s been nearly a year since the GSMA announced Open Gateway, an initiative to create common network APIs for the whole industry. At launch, 21 mobile network operators (MNOs) had signed on. Today, “nearly 40 mobile operator groups worldwide” are using it, which is great. I love it because it means telco isn’t out of the game; we’re going to fight back and we’re going to monetize the shit out of these 5G networks.

What’s great about Open Gateway is the common APIs everyone’s agreed to. These will smooth the path for developers to add connectivity to their apps. We finally have an easy-to-use interface with great docs! That’s the first step in the Twilio playbook, and it’s absolutely key to monetization. 

But we still haven’t solved the critical second part of the Twilio strategy. How will we do the OTHER thing that Twilio does? Do we have a “multiplexer” that takes developers’ code from their applications and figures out which network to send the network API call to, ideally with little to no effort on the developer’s part? Or are we still requiring developers to know which network they want to use in advance of the API call being sent? 

Unfortunately, Open Gateway is solving only one of the two key problems that Twilio figured out to make CPaaS a breakout hit. When I ask telcos what we’re going to do about this second problem, I get this response: 

“Azure (or another hyperscaler) is going to do it for us!”

Telcos, it’s time to roll up your sleeves

This is what I mean about history repeating itself. Why is leaving the “multiplexer problem” to Azure any different than leaving it to Twilio? Allowing someone else to solve the hard problem cedes our strategic advantage. It puts Azure in a position to do exactly what Twilio did, and telco will be left out in the cold again. The hard part wasn’t the common APIs; the hard part is the multiplexer.

You might be surprised to hear “don’t partner with the hyperscalers on this” coming from me, telco’s leading public cloud evangelist. While there are a lot of reasons to use public cloud technology for all sorts of workloads, this is the one thing the telco industry needs to own together. Telcos need to work together to own the developer community of network APIs, and should not give it up to a hyperscaler. This is the valuable part: getting your code into enterprise applications. Once it’s in there, it will never be ripped out. It will live in those applications generating revenue day in and day out, and that’s what makes it valuable.

If Azure (or another third party) owns the multiplexer, it also has the power to decide how to route those API calls, and will decide which networks to use. Azure gets to use least-cost routing (to save money) for connectivity API calls that are network agnostic, adding markup and margin that should go to the telcos. If Azure wants to abstract you away, it has the power to do that. Since it’s the cop directing traffic to the different networks, it’ll be in control of who’s getting traffic, and who isn’t. This is exactly what’s happening with Twilio now. Have you noticed you’re getting more one-time passwords delivered to you through email instead of through SMS? I am. Twilio wants users to redirect more traffic to email, and away from SMS, because it’s essentially free (it’s certainly cheaper than using SMS). I’ve also seen one-time passwords coming through native apps on my phone, which also cuts your network out of the picture. Swapping SMS’ for email and apps reduces Twilio’s biggest cost and its reliance on telcos. Meanwhile, our share of this pie continues to shrink, even as the market for these services continues to grow.

Hello, Whoosh!

So, how are we going to build our own developer community for telco? I agree it’s not an easy task and will require us to roll up our sleeves and put in the hard work. Lucky for us the building blocks are already sitting right in front of us within our enterprise IT relationships. You already have relationships with the same enterprises that largely use Twilio today. I argue the developers using Twilio are likely to be the same developers that will use network APIs. So how can we capture them from Twilio?

With Totogi’s Whoosh! We specifically designed this product to help you to build your own developer community. Whoosh! targets enterprise customers that already use Twilio, and with a simple one-line code change, moves them over to the Whoosh! API set. Whoosh! is not another CPaaS vendor; instead, we give you the code to sell to your enterprise customers. You add your connectivity (with better margins than Twilio can buy itself), and you are able to undercut Twilio’s price by 50%. This easily swaps developers into your camp. Once you own the developers, you can expand to sell them your network APIs. To learn more about it, watch my Whoosh! launch talk, and if you’re interested, let’s talk!

I’m not saying I have all the answers. Open Gateway is a solution to the first HUGE step of getting the telco industry to agree on common interfaces for APIs. But we still have to solve the multiplexer challenge so that we, telcos, own the developer community, and more importantly, GET OUR APIS INTO THE CODE. We don’t want to hand that relationship to anyone else—not even our pals over at Azure. I love the public cloud, but I don’t think telcos should partner with them on this. This is one of those times that our industry does need to build it ourselves.I’ve been thinking about this a lot lately, and talking to lots of different people in the industry, including Yesmean Luk of STL Partners, my guest on episode 73 of my Telco in 20 podcast, and Ferry Grijpink, partner at McKinsey & Company, who will be my guest on next week’s Telco in 20 episode. Check both of those out, and also stop by the Totogi booth (#2B72 in Hall 2) at MWC 2024, running February 26 – 29 in Barcelona, Spain, to find out more about how Whoosh! can help you build your developer community.

Recent Posts

Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.

"*" indicates required fields

Email*

Name

This field is for validation purposes and should be left unchanged.