Today a lot of the time and money for what we think of as programming is really spent connecting APIs (Application Program Interface). APIs are defined as a software component that defines the operations, inputs, outputs, and underlying functionalities of a specific program that are then used to have a reliable interface with a given program so that programmers can query programs or can link different programs together.

The software world is full of APIs that are the basis for building and operating most complex software systems. APIs can be simple, such as an API that just looks up a customer’s address when querying a database with their name. Or an API can be more complex, such as having an API routine that calculates the outstanding balance for a given customer and then ages the accounts receivable. The process of connecting a new software package to all of the needed APIs is time-consuming and expensive and is one of the reasons it sometimes takes months to implement a large new software package.

APIs have been integrated into almost all parts of the software world and there are plenty of them in the telecom world. For example, an integrated billing system uses a lot of APIs. APIs are used to allow OSS/BSS software to gather calling details from a voice switch to add or delete features. APIs connect to the software in a cable headend to define what channels a given customer should be receiving or to capture billing information from a pay-per-view event.

But there is a downside to using API-based software that anybody paying for software is all too familiar with. Almost every complex software package you buy these days in a telecom environment requires signing up for software maintenance – and it’s not cheap. Software maintenance is often set at an annual fee of 10% – 12% of the cost of the original software package. A large percentage of that money is to pay for keeping abreast of the changes in APIs. Every time the software changes somewhere in a telecom system, such as in your voice switch, those changes then ripple through the rest of your software systems.

Even if a large telco employs their own programmers a lot of programming time is used in working with and updating APIs. Reliance in APIs goes far beyond the telco world. Establishing the right APIs is the number one hassle of writing an application for smartphones, and it’s the difference between the APIs of iOS and Android that requires app makers to create and maintain two versions of their software.

There was an attempt a decade ago to make it easy for software packages to communicate with each other under the label of the Semantic Web. That initiative ran into a wall because of the massive effort required to make APIs work easily. However, it looks like maybe we are on the verge of doing away with the need for a lot of those APIs, at least in the manner we use them today. It seems likely that we are headed towards a time when bots are going to take over a lot of the tasks that require API interfaces today.

I use the Amazon Echo with the Alexa bot. Already today I can ask Alexa a question in English such as, “Which Baltimore Oriole has the most home runs?” and Alexa will search the web and bring back the answer Cal Ripken. Alexa and other personal bots are improving at breakneck speeds. We are getting close to a time when we are going to have bot-to-bot communications, which over time will replace a lot of the software in place today.

Soon we are going to be able to use our personal bots to interface with other software systems. I should be able to ask Alexa to go my bank and get a copy of my June bank statement. Alexa will then interface with my bank’s bot and get the needed information. The plan is for bot-to-bot communication to be in English, so if I don’t get what I want I can look to see what went wrong with the transaction between the two bots.

The beauty of bot-to-bot communication is that each customer is going to be able to find out what they want. Today, the owners of a web site for something like a bank have to pre-determine what they think customers are most interested in and then set up menus to supply those answers. But with bot-to-bot communication the bank doesn’t need to guess what customers want and doesn’t have to arrange the data in a format needed to support the APIs. The bots will figure this out for each customer inquiry. Bot-to-bot communication means doing away with a lot of clunky customer service interfaces and that means cheaper software costs for the bank. And for customers it means getting what you want by talking to your own bot in plain English. That should cut down on a huge percentage of customer service calls.

APIs won’t die, of course, but even interfaces with APIs can be automated using bots so that when something changes in a hardware or software system the bots in connected systems can figure out what this means on their own. That’s bad news for computer programmers, because today a lot of their work is connecting to or updating APIs. But it’s good news for consumers and it should be good news for any company spending too much money maintaining software that uses a lot of APIs.