API integration can often be like a story about four people named Everybody, Somebody, Anybody, and Nobody. As you may know, the story goes like this:
“There was an important job to be done, and Everybody was sure that Somebody would do it.
Anybody could have done it, but Nobody did it.
Somebody got angry about that, because it was Everybody’s job.
Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn’t do it.
It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.”
The Age of “API economy”
We live in the age of “API economy”. Pretty much all modern software vendors and cloud service providers provide an “Application Programming Interface” (an “API”) or several APIs that can be used to interact with, and import or export data to and from their system. No matter in which industry you operate, API management is unavoidable. In some cases, like with the banks in Europe, such APIs even are forced upon them by mandatory legislation (i.e., the banks must provide third parties access to their systems through an API in order for such third parties to be able to offer their services to the public). More often, though, APIs are provided by private or public organizations that have some data or functionality in their system(s) that they wish to make available for other systems and users.
APIs allow for organizations to provide their services on their platform and possibilities to monetize and grow their services in a new direction. In a perfect world, APIs help application developers to improve productivity by making things easier and even allow organizations to create completely new businesses for them by monetizing the data and/or other assets that they already possess.
There are numerous examples of businesses that have been able to increase their business and profits through the use of APIs that allow third parties to access their systems and services. The use of API instead of a User Interface (a “UI”) typically allows a higher level of process automation and thereby increases productivity. So, it’s no surprise that API integration, API integration tools, API integration platform, and the API economy have been sold to us as “the best thing since the sliced bread” for a while now and depending on your point of view, this may very well be the case. However, this really depends heavily on who you are.
API Integration 101
API is a standardized way to access an application in a programmatic way. In other words, API is an interface that can be used by other software solutions to interact with the application providing such API. Through the APIs, software programmers are able to work with other software applications that have been written by others.
Typically, application interfaces come with detailed documentation that describes how the API works and how it can be accessed. This documentation makes it easier for external developers to make their applications function with the API. The API documentation acts as a set of instructions on how to use the API.
The benefit of using APIs is that they do not rely on the internal workings of the systems. Therefore, a back-end system developer can change how the system internally works without any knock-on effect on external parties. As long as the API remains unchanged, internal system changes will not affect the third-party applications accessing the system through the API.
Without a doubt, a good API can:
- make it easier to integrate other systems and data,
- enable easier data and information sharing,
- enable easier transaction flows between third-party systems,
- allow systems to use third-party services more easily, and
- even help create new products/services and business models.
But the crux always lies in the word “can”. You should never mistake that for “will”. An API is always just an enabler for all these things, it will not make them happen somehow automatically.
Modern cloud-based IT solutions and platforms such as Salesforce, Hubspot, Nesuite, etc. have always had well-documented APIs (e.g., REST API, developer APIs), and other solution providers have followed their lead in creating the same event. From an integration expert’s point of view, there’s nothing better than a well-documented application programming interface that remains “stable” over a long period of time. Unfortunately, this is not always the reality.
Field of Dreams
We often see that various organizations proudly announce that they have an API to their system that anybody can use to connect with them. Then a few months later, they start wondering why nobody is using their API. So, they have a typical case of “Everybody, Somebody, Anybody, and Nobody” at hand.
Organizations that rely solely on building an API are falling into a “Field of Dreams” (a 1989 blockbuster movie starring Kevin Costner that some of you might still remember) type of illusion about data integration. The thinking of such organizations is "If you build it, they will come". With the API approach, the organization is, in a way, “passing the bucket” on the integration to third parties that are either
- not really interested in taking on the responsibility or
- simply incapable to doing so (regardless of how good or bad the API and the related API documentation are).
As an organization, you should never rely on simply building an API and expecting Everybody to just start using it. Data integration is never so simple that “Anybody can do it”. Instead, you should identify a third party, Somebody, who can help your customers and business partners to integrate with your API in case they are not capable of doing so themselves so that Nobody is left behind.
Practical Challenges of API Integration
While APIs are usually more stable and have far fewer changes made to them than a regular UI, even APIs tend to change every once in a while. What’s frustrating about this is that when you are a third party connecting with such API (either as a customer or an application provider), it’s your job to make the necessary changes at your end to make sure that your application keeps working with the API. The platform owner has basically outsourced all responsibility for the integration to you. If the API is under development and the changes are frequent, this will become quite a nuisance very quickly. Over the years, we have seen several cases where an API can keep changing even several times a month.
Another challenge that we have been faced with regarding APIs is the quality of the API documentation or, rather, the lack thereof. Typically, there are two extremes to this case. Sometimes the documentation is extremely high level and only provides the very basic information about the API and leaves the user to figure out or query the missing details. In other cases, we have seen API documentation that has been extremely detailed and extensive (expanding over several hundred pages), to the point where it gets incredibly laborious to work your way through the whole thing. Having said that, if we had to choose between the two extremes, we would pick the extremely detailed and extensive API documentation every time. Needless to say, whenever you create API documentation, you should keep the end user in your mind.
Why Even a Good API Alone Is Not Usually a Silver Bullet for Integration
Good API-based integration provides a great foundation for integration, but most APIs are typically not “active by nature”, i.e. they can be used to access the system, but you need to have an active component doing all the “leg-work”. Just like any UI needs a human (or a software robot) to use the UI to access the system, a REST API will not do a job by itself, it needs a computer system to use the API actively.
This can lead to a situation where companies may have multiple different systems and applications, all of them equipped with APIs but none of them actually transmit any data actively between these systems. In analogy, this would be the same as having two hardware devices, both with USB ports but no cable to connect them to each other.
In a best-case scenario, if you are only using “mainstream” applications such as Salesforce, SAP, Oracle, Netsuite, Microsoft Dynamics, Microsoft Navision or Dynamics, Sage, etc., you may find some packaged ready-made integration tools (typically called “adaptors”) in their “Appstore” that help to connect such systems with each other. These integrations are almost always “point-to-point integrations” designed for single use only, but on the other hand, they can be quite straightforward to take into use.
Such “self-service” integration tools were often referred to as “citizen integration”, a relatively wide promoted concept a few years back. However, unlike predicted at the time, we haven’t seen as wide uptake of such self-service integration tools as was expected. There may be a number of different reasons for this, but probably one of the key reasons is that “it’s not as easy as it seems”.
Also, citizen integration tools are not very handy unless the whole integration can be done with a simple “plug and pay” approach and even in that case some people will feel unsure on what to do. Unless it’s like installing an app on your smartphone (download and click) most people do not feel comfortable configuring such tools.
Moreover, as soon as you venture outside the mainstream applications, you will find yourself short of self-service integration tools very quickly and have to build the integration separately case by case. In that case, unless you’re an integration expert yourself, you probably need an expert to help you out.
APIs are great, but you need API experts, too
As discussed, from an integration perspective, most APIs are great. They really are. For an integration experts, they provide a clear, safe, and structured way to work with each system. However, do not expect that everyone is an integration expert, most of us are not. So, in addition to having an API integration platform, you should always make sure that you have expert resources available that can help build the API integration when needed. Alternatively, you can partner with integration experts like Youredi, who will help you with all your API-related challenges.
