Integrating systems for the purposes of interoperability has become more important, and more efficient, than ever before. With companies using a wide range of software solutions to keep their businesses running, these types of integrations are ubiquitous and necessary.

The standards for designing an API have settled and solidified over the past decade. When developers do integrations we can now count on a standard REST API or http API because everyone has come to accept a few parameters.

Along with the advancement of consumable cloud services, this move toward standardization has greatly simplified integration—and led to a significant shift in the way software developers approach a build.

A Deeper Look at APIs and Interoperability

Before we go any further, let’s quickly define APIs in order to better understand how they’ve fundamentally changed the software development game.

API stands for Application Programming Interface, and it’s essentially a way for an application to interact with another application, system, database, library, etc.

In other words, an API is what allows applications to talk to each other. It is what enables the interoperability of multiple systems, making it possible for those systems to communicate with each other and perform a myriad of different tasks.

1. Many people find it helpful to think of APIs as a waiter at a restaurant. The customer (user) has a menu of options and the kitchen has the food, but what they need is a system for sending a request and receiving a response.
2. Or, you may want to think of an API as your debit card. When you drive up to the ATM, you have a need. Your bank has the data (and the dollars). But you still require a secure way to access your account and take action.

For a real-life example of an API in action, think about booking a flight through a travel site. If you went directly to the airline’s site to book your ticket, the software would simply have to access its own internal database. No integrations or APIs necessary.

However, if you use a site like Priceline or Orbitz to compare prices, the software needs a way to push your requirements out to a dozen different databases and return with responses from each—all in a couple of seconds.

These websites depend on interoperability with each airline in order to provide you with all those prices.

Clearly this is a much more difficult process, but the user expects the same kinds of results at the same speed.

This is where standard APIs have become indispensable. There are a set number of ways that users tend to need to access data, and a set number of actions that they need to take on that data, so it makes sense to standardize and simplify.

Why reinvent the wheel when APIs have made interoperability so much easier?

How Integration has Changed the Way Developers Think

Developers used to build software as a self-contained unit, which meant you began your requirements and design phase by discussing what you wanted the software to do.

One of the things that has come out of our experiences creating custom software for our clients is a pivot away from this type of design thinking, made possible by more standard APIs.

We’ve found that building an API first—building that interface, describing what the data looks like, and defining the actions that users will be able to take on the data—has a number of important advantages for interoperability.

In this new model, we begin by asking questions such as: “How do we want this data to behave?” and “What other systems will our software need to connect to?”

Starting with interoperability in mind, we then move to the software itself, and the other pieces we build to work with the interface just become additional consumers of the API.

For example, in a recent build for PalmettoPride, South Carolina’s anti-litter and beautification organization, we didn’t start by determining everything we wanted the LitterBusters Hotline app to do.

Instead, we began by thinking about where the data our clients collected needed to go. Who would need to access it and how?

Determining the answers to these questions upfront, and building the application as if it were already part of a system from the beginning, allowed us to more easily automate interactions—in this case, pushing data to the DMV to automatically generate a courtesy letter for litterers reported through the app.

The Benefits of Building for Interoperability From the Beginning

Building with interoperability in mind comes with numerous advantages:

• Simplifies automation.
• More efficient software development process, leading to time and resource savings that result in a nearly cost-neutral API that your clients can use going forward.
• The resulting integration is more effective and feels more organic compared to an integration done after the software is developed.

From Architect to City Planner

For decades, developers have thought of what they do in architectural terms: Design-build. Interoperability is forcing us to think more like city planners now, sketching out the roads, pipelines, and other connective tissue first, followed by the buildings themselves. 

Like all paradigm shifts, this creates both challenges and opportunities.  

Ultimately, it’s impractical to continue to develop software as though it’s going to exist in a vacuum. Developers can’t assume that their software is going to live by itself anymore. If you do, you’ll be doing your clients a disservice—or you’ll sink resources into your SaaS only to find that it becomes obsolete in a few years.