I remain amazed that Telco API standards are still considered seriously. I’ve just returned from a quick trip to the Bay Area were I was talking to people who lead the market in APIs, they consider the Telecom industry’s perverse need to standardize APIs amusing at best and at worst yet another death knell for the industry.
My fundamental concern remains the “build it and they will come” mentality behind standards. For a global air interface or carrier service interoperability, absolutely yes we need standards as we have no choice but to buy mobile and fixed communication services and we want services to just work. But for APIs absolutely no, no way should we be standardizing them. Only when there are some solid market proven use cases, like Twilio, should we be sharing best practices only, and no retroactive standards.
Google Maps is one of the most successful APIs on the planet, it is not a standard, it evolved through Google working with partners and developers. It is used on websites around the world. Would standardization help it? No. Have competitors copied its API exactly? No. Because APIs are easy, a little bit of technology. It’s the value transferred through the API, the business models, the go to market, and services wrap that are the hard part. As I’ve discussed many times on this weblog. An implicit assumption is by adopting an API standard, all the other stuff I mentioned comes for free. It does not. Hence all the Telco API failures.
Examining successful APIs, generally they are used internally or with partners first, e.g. NPR or New York Times, then once the API has had some road testing, it may be exposed externally. That is, to real developers, real business people, real applications – not abstract standards. Abstract standards are being created with no real-world road testing, and it should contain the following health warning:
I think we could do the whole industry a favor by admitting API standards are not the answer, if anything they are a distraction, rather work with ‘enabling partners’ that have lots of API experience, focus on the use cases that deliver most value to your ecosystems and from that build a business based on APIs.
An analogy for this perverse need to standardize APIs, is to compare APIs to form filling. We all fill in forms either online, through a CSR (Customer Service Rep) or traditional paper and pen. No standards exist for forms, though there are some best practice guidelines. Forms enable me to get phone service, gym membership, a personal loan, etc. Standardizing Telecom APIs is like creating global form standards. There’s one thing I’m sure we can all appreciate if a form was designed by a global standards committee, it will be utterly crap, a pain to complete, and never used in practice. Please, no more Telco API standards, please.
On a related topic, this post from Eran Hammer, the guy leading standardisation of OAuth 2.0, sums up the frustration and futility perfectly:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
Thanks for the link James. Its a great, personal article.
Great post Alan. Despite all the interest in standardization of telco APIs, I always thought that if a common API was required, aggregation would trump standardization. Aggregate disparate APIs with a common API rather than go through the painful and often ineffective process of standardization. Kind of like Boku and Zong rather than OneAPI.