If you’ve been doing any research on business systems or general technology, you’ve probably seen a lot of chatter about application program interfaces (APIs). The very name sounds complicated and extremely technical, so unless you’re fascinated by technology, you probably skipped over much of it, on the assumption that it’s an “IT thing.”

The History of Enterprise Application Integration (EAI)

Companies, especially manufacturers, need multiple applications to operate efficiently. Most manufacturing companies need ERP, Financials, CRM (customer relationship management), SCM (supply chain management), Field Service and Support, EQMS (enterprise quality management system), Shop Floor Control, and perhaps others, depending on the industry they serve.

Each of these various systems has its own data model design and architecture, and they each include overlapping functions and data with one or more of the other systems in use. In the early days of computer systems, these applications either ran independently—leading to the dreaded conference room wars over which data was correct—or they were integrated.

Early integration methodologies consisted of extracting data from one system, doing some type of data adjustment to ensure that the data was suitable for the parallel system, and then the adjusted data was uploaded to the other system. 

For example, both ERP and CRM include customer records, and they may both include sales order or proposal records. Both systems need the data to operate properly, so companies needed to choose which system would be the system of record, and the data from that system would be exported to the other systems.

Sounds easy. It isn’t.

The two systems usually had different data requirements. One might require an alpha character in a quotation record, while the other might preclude it, for example. So the data couldn’t be exported and imported as is without making a stop in between to ensure the data was ready for import. Every piece of data, from customer number to region or product codes and more, might have to go through the same adjustment process.

This meant that systems were usually not updated in real time, but rather in batches that could run as frequently as every few minutes to as far apart as once a day—or even longer. As a result, it was difficult to ensure data consistency between systems.

These hard-wired integrations, once set up, were difficult and expensive to adjust. They were specific to the release of the software applications, because if one software vendor changed the data model, the integration programs might no longer work. So companies tended to stay on old releases of their software applications for as long as possible, even if they needed updated functionality, because it was easier and less expensive than updating the interface programs.

To combat this concern, many business systems expanded the footprint of the functionality they covered to spare their clients the hassle. But often, the expanded functionality was rudimentary compared to the specific applications designed to handle quality or supply chain management, for example. So if companies differentiated themselves from the competition based on specific business processes, they often chose to buy a standalone system to cover that area, even though it locked them into the integration issue described above.

But technology evolved. Enter the API, a tool to make integration simpler, faster and less expensive.

What is an API?

An API is a feature that acts as a go between so that two disparate programs can more easily work together. In essence, an API takes the data as it’s entered into one system and immediately enters it into another system, using the second system’s own code to ensure the data is formatted appropriately and that all required data is shared between systems.

It’s almost like the API enters the data the same way a user would, except no user needs to be involved.

The Purpose of an API: Standardization

An API simplifies the integration of two systems, moving data seamlessly between the two, and handling all of the data “mismatches” described above so that data can be updated in real time. 

The best part is that because an API connects directly to the system’s underlying data model, it always works, even when one system or the other moves to a new release. And because it operates in real time, the disparate systems stay in sync, with no chance of data discrepancies sneaking in.

The result is more reliability and consistency when disparate systems are in use. The APIs continue to work even after version upgrades, so once in place they operate as they should without the need for frequent changes or updates.

Why Technologists Care About APIs: Simplification

Technologists and the IT team care about APIs because they are simpler to program—in fact, they really don’t require programming as we traditionally consider it. They are faster to set up, less expensive and more reliable.

Why Everyone Should Care About APIs

Most people will never need to see or use an API, but it’s still important to understand them and to know that they are available. For example, if a department wants to adopt a specific business application—perhaps a marketing automation solution—it pays to ensure the solutions under consideration have APIs to make it easy to pass data back and forth from the ERP or CRM solutions in use at the company. This helps to ensure customer and prospect records stay consistent, and can eliminate duplicate records that can be nearly impossible to eradicate once they creep in.

Another key feature of APIs is the ability to add functionality to a system without touching the actual code. So, for example, if a company wants to add a new feature—perhaps a lab report that isn’t included in their EQMS solution—an API could be used to collect and store the data.

This means personalizations and extensions to software can be done faster, cheaper, and with better quality than the old way of having IT or external consultants modify the code. Once a system’s code has been modified, it makes it extremely difficult to support or upgrade. Using APIs and extensions simplifies the process.

What to Look for in an API Architecture 

APIs come in many formats and have varying purposes. There are public APIs, which are available for anyone to use. Other APIs may be proprietary to a specific system, so you would need to be a customer or partner to access them. And there are internal APIs within business systems, which allow a software company, for example, to improve the integration between its various modules and components.

Web APIs have consistent formats, so they work from system to system. Some standard formats include:

• SOAP
• XML-RPC
• JSON -RPC
• REST

The availability of web APIs makes it easier to connect disparate solutions running in the cloud, or to connect cloud applications with applications running in house.

A business system that uses APIs to pass data between functions and modules will provide more flexibility for personalizing and extending the software to adapt to the specific business processes the company needs.

APIs are the most modern way to design enterprise software, and they are ideal for quickly and easily addressing the rapid changes required of modern and adaptive enterprises.