We’ve all more than likely been in a meeting and heard the phrase “it comes with an API” and we all accept that this is a good thing, for some reason. Probably because the IT team just perked up. But what is an API? Why does it really matter? What does it mean to you and your business? In short; because we live in a world where software needs to play well with others. There is (quite rightly) simply no place for enclosed systems any more.
What is an API?
Let’s get this out of the way; “API” tends to stand for “Application Programming Interface” and can refer to many things, but what’s important here is two types;
1. External API
This is what people normally mean. It’s a mechanism by which other applications can communicate with the system in question. I see it as “drive-thru” – you don’t need to know how the burgers or chips inside are made; you just need to put a request in, and the window will magically provide what you asked for.
The key here is that you don’t need to know anything about the internal functions. You just need to know the available options (e.g. burgers, chips, …). Similarly with an external API, you just need to know the requests you can make (e.g. user lists, document submit, process status, …) and the system will provide the appropriate output. The key is that to obtain the information you need, you don’t need to know anything about the internal workings or storage structures of the system.
There are (ever-evolving) standards around how these work. Top vendors will provide support for multiple standards including SOAP, REST, Java and JSON.
Why are these important? Systems integration is increasingly a business-critical requirement. For instance; you want various systems to be hooked up with your helpdesk so their dashboard can reflect issues and they can proactively troubleshoot, instead of waiting for the screams from users.
2. Internal API
Plugins, to you and me. This is a little more complex to provide an analogy for. Essentially the software will enable programmers to extend the functionality of the system by having a standard “shape” for functions which can be attached. Think of Lego blocks. As long as your block has the right outside shape, it will fit into the overall system.
Not all systems permit the use of plugins. They need to have a specifically designed (and documented) capability to attach these plugins.
Why are they important? For simple systems they might not be important at all, your system might perform one single function and not require extensibility. However, increasingly companies will require some level of customisation, and rather than having developers bash a resistant system into shape, it’s preferable to use plugins which can do the customisation through a vendor-supported mechanism. This is also helpful in the long run when you upgrade systems.
Ok, you’ll likely pay more on licensing for a well maintained API, but in the longer run it works out a lot better.
It’s always possible to integrate, customise and extend your in-house applications, but if you haven’t done so through a supported and maintained API, you’ll likely end up with a carefully constructed, intricate and very delicate spider-web of strings between the applications which could unravel at a touch. Upgrading any single component in your infrastructure would lead to a horrible cascade of failures and money spent on programmers hacking their way back to a functional network of applications by pulling all the strings back into place. This usually means IT won’t touch it once it’s up and results in a vast ecosystem of out-of-date applications, which comes with its own security and performance risks which will affect your business’ bottom line.
So, in addition to significantly lower maintenance cost/effort, APIs are critical to improved organisational security and operational effectiveness.
Availability of skills
With technical skills already hard to come by, the last thing you need is to introduce another application into your ecosystem which requires some specialised skillset. As if it doesn’t cost enough to get these people on board in the first place, there’s no job security for them like being the only person who knows how the warp-coils are integrated with the dilithium crystal matrix… thing.
It’s much Easier to find developers who can interact with an API using well-known standards (such as JSON or REST). This way you know that the skills are out there, and equally importantly, that they are interchangeable.
Not intending to suggest that any developer is as good as any other, they are often highly skilled specialists in their own right and bring unique skill-sets, but when purchasing a software application for your company, you need to know that its integration with the rest of your environment won’t be one of those unique skills.
Access Controls and Data Consistency
Particularly for more complex systems, you’ll need to manage user permissions, roles and access controls through the system itself. This is another key reason all external systems need to interact through the API; this places responsibility for consistency in managing those functions with the system, rather than the integration mechanism.
It’s much easier to find developers who can interact with an API using well-known standards (such as JSON or REST). This way you know that the skills are out there, and equally importantly, that they are interchangeable.
For instance; some years ago I was involved in a project where the IT team had integrated a system directly into SharePoint databases to extract data. After much work they were able to extract the data correctly for the intended purpose.
However, at upgrade-time this posed a tremendous challenge. Had they been able to integrate through an API (which wasn’t possible at the time), it would have placed the burden of maintenance and consistency with SharePoint instead and saved a great deal of time and money.
In addition; when there is a compliance aspect to the collection of data it is completely indefensible to obtain data through any mechanism but a documented API; because otherwise how will you be able to guarantee that the data is correct and complete?
When a software vendor commits to providing an API it forces them to put more effort into thinking about maintaining those functions. This results (hopefully) in much improved backwards compatibility between versions. Whereas the back-end structures might be completely different, the external access to the data should be consistent. There’s no guarantees of course, but that’s the point of having an API so your vendor should stick to that.
It also encourages improved testing, because in software development practices it’s possible to hook automated test-scenarios to an API. When new work is performed, these tests ensure that regardless of behind-the-scenes changes, the API still provides consistent and correct data output.
So all-in-all, use of API inherently encourages better development practice, resulting in higher quality software for the customer. At Gravicus, we consider our API to be one of our most important features. From day 1, the Gravicus Osprey Platform has a been built around a carefully designed and maintained API, both for external integration, and extensibility through plugins.
All our development work begins with the API design and is built backwards from there. This is best practice for development and keeps us thinking from a “what would our customers want?” perspective.
In fact, our entire GroundControl application suite is built on the API. That’s how we know it’s good enough. We have libraries that make it super-simple to integrate with our platform using standard technologies such as Java, SOAP and JSON. We even have standard libraries that handle some of the integration for you; such as plugins for Activiti BPM (enabling complete workflow integration) as well as Zendesk integration.
As for plugins; the entire Osprey Platform is a framework of plugins. Any of its features can be extended and customised. That’s why we call it a platform; it’s designed to be built on.
For more details on how easy it is to use Osprey or to get your hands on a trial, just get in touch!