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, and 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 that by adopting an API standard, all the other stuff I mentioned comes for free. It does not. Hence all the telco API failures.
Successful APIs, generally, are used internally or with partners first, for example NPR or New York Times. 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. Such standards are being created with no real-world road testing, and it should contain the following health warning:
"This standard has never been successfully deployed, it ignores the need for a viable business model for the consumers of your API, for a go to market plan for the API, and the services wrap to deliver the value the API consumers need. Bottom-line we've done something that didn't need doing, and you're going to use it and fail because you will ignore doing all the other stuff because you think it's a standard so all you need to do is buy something that implements 'The Standard'."
I think we could do the whole industry a favor by admitting API standards are not the answer. If anything, they are a distraction. Instead, you should 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 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, and so on. 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.
Alan Quayle has 22 years experience in the telecommunication industry, focused on developing profitable new businesses in service providers, suppliers and start-ups. For more information, visit www.alanquayle.com