Blog Post

Why carriers can’t create common APIs (but need to keep trying)

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Over the past two decades, I’ve built and sold a few companies that have exploited the simple fact that the bigger an industry behemoth grows, the harder it gets for it to serve its customers. At my last company, Intellisync, my teams built products that wireless carriers needed but couldn’t deliver. Today, I run Locaid, a company that simply ?lls a void between giant carriers and giant enterprise developers. It’s hard enough for a single giant to innovate, so why do they always assume a coalition of giants will fare better? They never do.

Coalitions seldom succeed unless the members are motivated by a supreme crisis. Throughout history, a major threat or act of war was often needed to compel independent and competing parties to join forces for common gain: the United States, NATO, the international ban on whaling. Business can be war too, but the stakes aren’t usually high enough to keep a collective of companies aligned under a common agenda. Except for OPEC or Hollywood agencies, coalitions tend to generate more fodder for the press than progress.

Last week, another coalition tombstone was etched. As Kevin Fitchard explained (and eerily predicted) in his recent article: the Wholesale Application Community (WAC) will go down in mobile history as one of the most ambitious, but failed, collaboration attempts of our dear telco friends.

WAC, if you don’t know, was an industry alliance of 47 of the largest worldwide mobile operators. It was formed in 2010 to help wireless carriers compete in an open, unwalled mobile world. Rather than force developers to work with each individual operator to get APIs, the carriers would design a “single API” for location, billing, messaging and more. This would be the “iTunes for carrier stuff.”

Why couldn’t these powerful carriers — all facing common threats from open, data rich, ubiquitous platforms such as Apple, Google, Facebook and Amazon — get their WAC together?

The bullets shot in WAC’s back

Membership impatience. Collectively, the carriers endeavored for more than two years to launch a “single API,” and failed to develop much of anything. Now the carriers are individually frustrated with the GSMA and WAC. Rightly so. You won’t find the AT&T and Verizon chief technology officers publicly bashing the GSMA. But within their carrier walls, you can hear their screams at LTE and 4G speed. Don’t be surprised if splinter groups of carriers leave the WAC’s original 47 members behind to form their own common API solutions. And they should. Developers want tools and APIs that are easy and ubiquitous. A group of 47 single-minded designers won’t ever create a slick, friendly interface.

APIs aren’t backhaul. Deploying servers and towers is easy after developing decades of monopolistic experience. But building APIs is hard. Those of us that do it well (such as Apigee, or my company, Locaid) have spent years and tens of millions of patient investor money connecting behemoth, byzantine carrier networks to create easy-to-use APIs for developers. You cannot create an API by committee. And while the carriers have done a yeoman’s job of offering up more APIs – either directly or through partners – for high-demand services such a billing, messaging, location, it’s not an effort conducive to a group. The task is made more difficult for carriers because top developer talent wants Apple, Google or the latest VC-backed wunderkind on their resume — not AT&T or Vodafone. Carriers are trying to attract top developers, but that takes time. “Coding at carrier” isn’t hip in the college dorms just yet.

Policy versus products. Ultimately, WAC was a policy-setting machine, not an execution machine. And it certainly wasn’t a market-making initiative, which is what the carriers all desperately want. Some of us in the API enabler market have more sales people selling carrier API data than all 47 WAC carriers combined. It takes focus, design and execution to win share. And if you can’t launch product, you won’t survive. Hence, RIP WAC.

WAC will be resurrected. The concept of carriers working together comes around every few years. WAC will rise again (under a new brand no doubt). But even if carriers can get their network technology people to agree on standards, code, enablers, SLAs, etc. (good luck with that), and even if the carriers’ legal teams can agree on liability, privacy, etc. (more good luck to them there), they still have a major issue: carriers will have a hard time selling APIs. These are telcos. The sales teams, commission incentives, even the product offers, need to be dramatically restructured to become “developer friendly” services. Carriers can get there, but the journey will take time.

It’s a shame, really. The carriers want what WAC promised, and two-by-two they will eventually get there. WAC and carriers are populated with smart, innovative folks, and they should be admired for their ambition and fight. But carrier machinery — processing billions of bits per second at five nines of reliability — isn’t built to move at developer speed. Not out of the gate.

This is a great opportunity for developers. The message from the market is now loud and clear: “WAC is dead! Long live WAC!” The holy grail of “one API” remains. Venture capitalists and strategic investors have been funding the market-driven API agenda to date, and they will continue to do so because it’s the right thing to do. And it will be up to nimble, focused innovators to fill the need, one API at a time.

Rip Gerber is the founder and CEO of Locaid. The company offers Location-as-a-Service that connects developers to Tier 1 carriers via a single API.

Image courtesy of Flickr user buddawiggi.

2 Responses to “Why carriers can’t create common APIs (but need to keep trying)”

  1. Rip Gerber

    Tsahi, some things do need committees. Ever try to get a few people (like a family) to agree on where to go to dinner? It gets more complex when you add another family, and another. Let alone finding a table for 12. To your point, the United Nations is one such group that has chalked up some significant wins and progress. It’s under a UN sub-committee that the GSM protocol came about and is managed. Guess we are both right on that.

    The fact that WAP wound down and Apigee took it over is one case fact that supports my view that small, nimble and focused providers can succeed where large, powerful players struggle when going at it alone. Both types working together is the likely optimal approach. Time will tell. I wonder what Apigee has to say about that.


  2. Tsahi Levent-Levi


    While you are probably correct that APIs by committee is impossible, there are things that can only be done by committees – and that’s defining the underlying protocols: be it GSM or HTML – they were both born by committee and brought us the most amazing innovation.

    Carriers should probably offer APIs in a manner that companies like your own can aggregate and translate into a single API on top.