Let's talk
Most computer systems work best if they can talk to other systems - it saves users from double-entering data, allows processes to be triggered, and makes sure that data is current on multiple systems. These integrations normally take place using an Application Programming Interface or "API". However, as anyone who has worked in systems integration for a while can tell you, there's a wide range of quality when it comes to system APIs.
What could possibly go wrong?
Unfortunately, plenty. Many companies provide an API as an afterthought, or see it as a costly distraction from their core activities of feature development and sales. Even large companies providing household-name products can have APIs that provide merely a fraction of the functionality available through the program interface, or with documentation that fails to give the developer the information they need to write robust integrations. Worse still, some companies hide their API behind locked doors, requiring developers to sign up to a paid program in order to even see the API specifications: this is a nightmare for anyone trying to quote on an integration before funds are committed.
Another key problem is performance. I recall one software package (which I will not name and shame here) that offered an API with good documentation: we quoted a client for integration work, and found that the system rapidly crawled to a halt when the system was tested with real data. The reason? Each call took a second to complete, and detailed data could only be retrieved at a rate of one record per call. Populating a list of users took the best part of a minute. We implemented workarounds, but all attempts to engage the company in discussion on their API performance were ignored, and we learned a valuable lesson about not making assumptions!
An opportunity missed
The real annoyance is that many of these companies who think of APIs as distractions are failing to realise the opportunities presented by a good integration. Why?
- A key concern in most procurement operations that we've been involved with is whether the new system integrates well with existing systems
- Clients who integrate with your platform are clients who are unlikely to switch vendor tomorrow
- White-labelling your service can be a very happy arrangement, allowing you to offload some of your support (and sales) workload
- Community-developed add-ons and companion apps can often add a killer feature to your service, making it best-of-breed
A lesson in sales
My Dad grew up in Australia, and he tells (apocryphally, I suspect) of how a dog-food salesman once came to call. His pitch was to open a tin of the dog food, get out a spoon, and tuck in. After a couple of spoonfuls, he said "if it's good enough for me, it's good enough for your dog".
The practice (or the rumour) was clearly widespread enough that the phrase "eating your own dogfood" has caught on in tech circles, where it has come to mean "using your own product". People will cite good examples such as Windows NT, which was developed almost entirely on machines running the NT operating system and was arguably the most stable OS of its time, as well as negative examples such as Google CEO Eric Schmidt, who admits openly to using a BlackBerry rather than an Android phone.
How does this apply to APIs? The answer is simple - make your product use your API. Sure, if it's internal then you can probably simplify the security layer, but if you are constrained to using the same methods that you open up to the public, you'll soon find out which features are frustratingly missing from your API. Likewise, if your API calls are inefficient and slow, it won't be end users who complain first, it will be your own developers - the people who have it in their power to fix the issue.
Are you interested in getting your software packages to talk to each other? Do you want to offer an API to an existing system? Get in touch.