The Great API Con

Happy New Year! I thought I’d kick the year off with the Great API Con, as its resulting in systematic failures of innovation projects that should be seeing far more business success. This article is for API providers not consumers.

api con

“Wait! What? Aren’t you an early proponent of APIs? Recommending copying the lead of Web companies? Look at this 11 year old article you wrote: The Telco API: Potential to raise ARPU by up to 36%

Yes and no. I’ve seen over the past decade the term / concept of an API become a tool of dis-information. Resulting in people spending way too much money on stuff that really doesn’t matter, like over-engineered API management; and worse NOT doing a load of stuff essential to successfully deliver projects that an API is a very small part of, like putting the right people and processes in place in engage local communities.

“OK, we know you ‘dislike’ marketing, specifically what do you mean by the API Con?”

Here are a few examples.

The term API economy is nonsense. An API is just a HTTP request. We do not refer to the web / online / internet economies as API economies. Using an API does not open up some vast economy, because there is no API economy.

The implicit assumption is you use APIs, I use APIs, and together we create new wealth. That’s not the case, for example: a bank uses APIs, other banks use APIs, transaction costs lower, making once prohibitively high cost services available or some services more broadly available. The wealth is created through banking services, NOT through APIs. APIs are just a lubricant to business transactions; I’ve been using the lubricant line for 20 years. There is no magic with a HTTP request (API).

Let’s focus on the basics. An API exposes (either privately or publicly) a service. Let’s take something as simple as provisioning a telephone number; http://NumberProvider.com/GiveMeANumber. But that is just the tip of a massive iceberg of the number provision service: does it support SMS, what’s the country/region/city, is the request compliant with local regulations, what incoming and outgoing services does it support, what’s the number format, BILLING, customer lifecycle, rebates / refunds / cancellations, what features are included such as callerID, fax support, can I port the number? The list goes on, and that’s a simple API. Making calls and sending SMS open up vastly more complex billing issues, and a raft of service interaction issues.

An API is just one of a number of ways a person can get telephone numbers. They could use a simple web form (a template), some of the most successful innovation programs (e.g. IdeaMart in Sri Lanka) use simple web forms as it addresses 100 times the number of people compared to an API. It could be a management console in a Unified Communications service. It could be an app on your phone. The API obsession is a mis-focus, enabled by companies with large marketing budgets that want the focus on all the stuff they can sell you, rather than focusing on your software or service and all the work you need to do to make it available ‘as a Service’, and all the people and processes required to engage your local markets that has little to do with API Management.

Another fun example is the dumbass term ‘open API’. It’s a like saying ‘Honest Don’s Used Wall Building Supply’. By claiming something that does not need to be there raises the question, what are you up to? An API is inherently open, it’s just a matter of being public (anyone can ask for access) or private (only people I let know and potentially are on the same network can ask). You’ll find trade bodies and consultancies with virtually no practical API experience use the term open API. When you see the term Open API, know you’re dealing with amateurs, or worse marketeers.

“OK, I get it, focusing on the API is a mistake. It’s all about the service. An API is just one of numerous ways people can use my service. But the analysts, press, trade bodies, even my bosses (because they talk to sales people of our suppliers and believe them over me), are all obsessed on API strategies, markets, stores, and economies.”

The API Con has become an insidious addiction fed by fake news that encourages ‘believe don’t think’ in the industry. We’ve been here many times before with WAP, WAC, OneAPI, IMS (yes deployed in most telcos, but look at the mess they are now in wrt service innovation), SID (Information Model designed to keep TMF toadies employed), Mobile TV (not the broadcast technology popular in Asia), PTT, PTx, NFV, digital transformation, 5G, etc.

When I look at the successful innovation programs over the past decade they’ve focused on so much more than the API, with web forms and management consoles driving more traffic and innovation. AND: focusing intensely on the service; its design; customers’ problems and needs; putting the right people and processes in place; and one of the other essential ingredient of starting small and growing with revenues – no unicorn hunting! This last point really is critical.

As with all addictions it’s a 5 step plan to recovery:

  • Acceptance. The first step is recognizing the problem. Without that recognition and acceptance, willingness to make change cannot begin. And from that change results competitive advantage from focusing on what is important – the whole service (across people, process, and technology) than the current API nonsense.
  • Avoidance. The second is understand what has been causing this API-obession and removing it from your life. Conferences focused on APIs, avoid them like the plague, you’re being conned / indoctrinated. Vendors and trade bodies that focus on open APIs, API management, and all their claimed special processes and consulting services to make your APIs a success. They’re forcing you to go unicorn hunting, rather than building the business together.
  • Exploration. Third step is exploring the concepts of moderation. APIs are a part of life, we need to learn how to use them appropriately and not obsess. Focus on the people, events, suppliers, trade bodies that help you focus on what is important – your software and services. The API really is the easy bit. I see many companies struggling not with their API platforms and programs, rather because they massively underestimating the work required in being able to offer their software / service ‘as a Service’. That’s the hard part.
  • Healthy Habits. This is getting your organization focused away from the API addiction, so as a business you can move forward to success with your innovation programs. Take them on your journey of recovery, help them understand APIs are a small bit of the platform you’re creating.
  • Maintenance. Focus on making your services easy to use wherever your customers are. Focus on the service design and features that make your customers’ lives better. You’re now using APIs as part of a balanced services strategy, rather than wasting time and money on the great API Con.

Its all about the services!

99-no-unicorn-e1515768364784

3 thoughts on “The Great API Con

  1. Michel Burger

    We should not confuse marketing hype and technical design paradigm.
    From a technical design perspective, being contract first is a key approach to make service usable and fit with the demand, and API is a great way to describe your contract.
    In this case, API becomes an inherent part of the design and implementation of the service, and not just a shiny document that hides a bad design. So inherently, there should not be an API program and there should not be an independent API initiative and API should not be a specific line item in a product offering, and this particularly true when moving to a micro-service approach.
    From a system design perspective, these clear contracts almost immediately expose the fact that many solutions lack proper system integration by completely missing system paradigm like FCAPS. Is there a need for a platform for that can be debated (for me it looks more like a discipline).
    After all of that, there is the marketing hype and I agree with what you are saying.

  2. Mark Csernica

    To build on what Mr Burger is saying.

    My first job was technical sales support. I was trained to remember “Don’t confuse selling with installing”. It was the salesman’s job to get a sale. Being technical support, it was my job to ensure the client understood what he was buying. That his expectations were met and my company didn’t underdeliver. Or the salesman didn’t over commit so we could not meet customer expectations.

    APIs (included Telecom APIs) are a programming tools. Like most tools, they are a commodity, targeted for a specific “job”. And their market is quite specific. When somebody needs that tool, is when it is purchased. But companies invested in selling that API, need to generate revenue on it or suffer the consequences. Some companies are better at it than others. From those that aren’t, we see the marketing and sales hype to try and improve sales. And we see the situation you are writing about as fallout.

    APIs are useful tools.

    And I understand the need to “educate consumers” with this article and reset expectations.

    It is the people who confuse “selling with installing” that get into trouble with their selections.

  3. Pingback: TADSummit Americas Agenda, 15-16 Oct, Chicago - Blog @ Telecom Application Developer Summit (TADS)

Comments are closed.