Once upon a time, a business could be a relatively monolithic entity. You might have to deal with suppliers and customers, but for the most part your operations were housed under just one roof.
Today, however, it's all about connections. Potential customers visit your remotely hosted website from the comfort of their own homes, while employees out in the field communicate via Slack on their smartphones and contractors use a VPN to log onto the company LAN from the other side of the country. Connecting technologies can make your business drastically more flexible and productive, while slashing operating costs.
One aspect of this that many smaller businesses haven't engaged with is APIs. The abbreviation stands for "application programming interface". A simple definition of an API would be a service that makes some of an application's controls and behaviours available over a network. That might not tell you very much, though, and that's probably appropriate because the big wide world of APIs is one that doesn't really stick very closely to general definitions or rules.
So let's go back to the start. Amazon first popularised the idea of the "API Key" - basically a long, glorified password that grants you administrative access to your Amazon-hosted virtual machines. I rather wish that Amazon had used another terminology because, in fact, what's exposed isn't really a programming interface at all, but quite a simple set of hypervisor management functions: start, stop, make new, delete old and so forth. If you want to interface with the software running on those virtual machines, that's quite a separate process.
Still, Amazon can take a lot of the credit for getting people thinking in general about issuing commands to remote systems, and thus kickstarting the whole API field.
Twilio is bridging the gap between business programmer and mobile network
Now, it's grown to become a lot broader than you might expect. Part of that is down to the rise of the aforementioned hosted virtual machines, which may well be set up to provide useful functions to authorised clients that make the right requests in the right way.
However, some of the biggest advances in API-presenting services have barely involved cloud computing at all. One great example is Twilio, which in effect acts as a bridge between two fundamentally separate worlds - that of the business programmer and the mobile phone network.
Real-world uses
What does that look like in practice? Well, if you've ordered a taxi lately then you'll probably have promptly received a barrage of text messages telling you the driver's name, car registration and mobile number - and it's probably Twilio that's been used to convey that information from the taxi operator's database into an SMS gateway. Once you see what a gateway like this can do, the power of APIs makes perfect sense: it's something that breaks down barriers and opens up new possibilities that businesses can really benefit from.
Uber was one of Twilio's biggest customers until it recently decided to take some elements of its development in-house
Interestingly, Twilio can help your apps interface not only with regular phone services, but also with WhatsApp. Doubtless, WhatsApp has its own API, but if you're working with lots of different data sources and wanting to reach a wide range of customers on different services, the benefits of a single API broker quickly become obvious.
That doesn't necessarily mean that it makes everything simpler, mind you. One of the modern challenges facing a service such as Twilio is proving that the pathway of an aggregated multi-step, multi-partner workflow satisfies the regulatory requirements of both the computing and telephony industries - two quite separate judicial territories. Tracking exactly what you're doing and to whom you are doing it, and maintaining diverse logs of programmed behaviour, isn't something you can afford to get wrong when a screw-up can have a little old lady's phone ringing hundreds of times a day.
On a cloud?
One thing that might seem a bit strange is that even though the cloud isn't really central to what Twilio most usefully does, the company chooses to present itself as a cloud business. Really, though, this is just a statement about what people are searching for, as an API is often a gateway to a specific hosted service.
A prime example of this would be IBM's Expert System service - better known as Watson - which provides natural language-processing, machine learning and data analysis capabilities that you can call on within your own home-grown business apps.
IBM's Watson was famously put to the test on US TV show Jeopardy in 2008
As it happens, for this article I had hoped to be able to tell you all about the hard-won experiences of a business making use of Watson - but once I explained that I hoped to publish details of the choices, decisions and challenges the company had faced, the line went silent. This isn't necessarily unreasonable: when you're reliant on an API, you don't own the technology, and all that's stopping a rival company from doing the same thing you are is the fact that they haven't thought of it yet. Perhaps it's hardly surprising that a degree of surrounding secrecy is part of the deal.
So here's another tale about a friend of mine who used to work in the TV business. Her job was to collect statistics about the relative popularity of the shows they sold to various networks and countries. To do this, she had to regularly visit the websites of the different networks, log into the management area, download the stats and put them in Excel. On the surface, this sounds pretty easy, especially since the companies in question mostly used the same software to manage their data.
Saving time
Unfortunately, those companies didn't all use the same version of the software, and those different versions relied on different releases of Java. My friend's day consisted of endless uninstalls and reinstalls of specific frameworks, punctuated by small bursts of productive work.
This wasteful rigmarole went on for some time - until it emerged that while the front-end requirements for accessing the data were different across different releases of the software, the back-end didn't use Java at all. All of this version-switching was needed solely to make the flashy web interface work. And, wonder of wonders, an API was available that permitted authorised users to query the raw data directly, without needing to go through a browser. With only a small amount of coding in Excel, she was able to create a spreadsheet that automatically connected and downloaded the latest data, saving her a vast amount of time and frustration.
You might question whether such a simple bit of scripting really qualifies as an illustration of the potential of APIs - which is exactly why it's such an instructive example. It shows that you really don't need to make a massive investment in large-scale app development - small, simple automations can yield a significant benefit.
Getting started with APIs
You'll have got the message that one thing APIs are great at is linking services together. That's an idea that's very much entered the mainstream consciousness in the past year or two, thanks to the rise of speech-recognition driven systems like Alexa and Siri. Businesses of all sorts have been scrambling to enable their systems and services to interoperate with the latest smart home hardware.
Meanwhile, the IFTTT automation website has suddenly found itself more relevant than its creators perhaps ever imagined. Only a few years back, it was a relatively quiet and studiously built environment, frequented chiefly by geeks. Now its capabilities extend into all sorts of everyday interactions: the last time I visited, I saw a suggestion of allowing the Domino's despatch system to turn on your porch lights as the delivery boy arrives - a great example of how two utterly disparate systems can be wedded together, and also a reflection of how big brands have already embraced consumer automation.
IFTTT allows users to sync their Domino's Pizza app with their Philips Hue smart light system
If you're thinking of following suit and diving into IFTTT, however, we'd advise caution. There's a reason we started out talking about Twilio above, rather than anything more complex and ambitious. Do you really want your vital customer service logic rubbing shoulders with someone else's pizza-delivery system? It may be smarter to spread your activities across multiple platforms against the possibility of service outage.
Then there's the question of accountability, which has already gained a certain urgency lately in the context of AI. The question there is, if you rely on a black box to do your thinking, how do you know it isn't making mistakes? A similar principle applies to automation integrations. It's always a good idea to break jobs down into small, independent tasks with predictable outcomes and a short list of errors. The more you remove human involvement from the equation, the truer that becomes.
For example, let's say that your ecommerce website generates lists of transactions, and that you need to import them into your accounting product. One idea might be to run an FTP server on the box (or virtual machine) that hosts your database, and open the required ports to allow the ecommerce server to directly connect and deliver the report file. Any competent project manager ought to run a mile from the idea of punching a hole in your firewall, and granting automated write access to one of the most critical components of your business.
Simple solutions
With a little simple automation, much more secure and better-accounted options become available. For example, the ecommerce site might periodically email a link to a specified mailbox, which is monitored by a script looking for messages in a specific format. That script can then open the link, provide the requisite credentials, and download the file with no need to open ports or set up new network services.
Strictly speaking, this isn't using an API at all, but in automating and streamlining the problem it gives you the same benefit - and it's so quick and simple to set up that it would barely register on an IT contractor's timesheet.
Decisions, decisions
Of course, this style of job passing and programmed behaviours is nothing at all new. What's new, however, is the broad spread of tools now available for assembling composite systems across huge varieties of public, private, internet, VPN, or mobile technologies. You might think that automation is happening quickly in the home environment - but it's developing even faster in the business world.
That means it's time to take a long look at your systems and figure out whether you're currently wasting time and money on lengthy, disconnected processes. When you identify potential efficiencies, you might well discover that what you need isn't 250,000 lines of Excel macros or a five-year web platform deployment - just a handful of specialised automated procedures with narrow, easily recorded and accounted capabilities.
