Data Integration Using API Technology Is Inevitable. Are You Ready?

At other times, APIs serve as a data connection to populate applications with information that can then be filtered or manipulated as it’s served to users. One of my favorite examples of an API in action is the public transportation function in Google Maps I use almost daily. When I punch in date, time, and travel coordinates, Google Maps instantaneously pings a database to receive the information I’ve requested in the application by way of the transportation authority’s API. And because bus routes are constantly monitored, I can refresh the app to see if my bus is behind schedule. (I just hate arriving home hangry because I mistimed my commute from work.)

Web APIs come in two flavors: Simple Object Access Protocol (SOAP) or, more recently, Representational State Transfer (REST). The latter is a flexible, lighter-weight architectural style that doesn’t have to rely solely on XML to execute API-based tasks. (For the technically inclined, this Smart Bear post provides an in-depth look at differences between the two.)

 

Data Integration with API

APIs have gone from servicing apps on your phone to replacing (or threatening to displace) older communications technologies like electronic data interchange (EDI) in a number of industries. Service providers to the transportation and shipping industries are alternately proclaiming API’s clear superiority (migrate now!) or EDI technology’s staying power (not yet!). Other industry groups like in the financial technology, or FinTech, sector are trying to create API standards within the industry to harness API’s strengths while minimizing associated development costs.

And therein lies the rub.

Even with the well-chronicled advantages this newer technology offers, perhaps API’s biggest disadvantage is the absence of standards that dictate a universal format. In other words, an API is infinitely customizable to meet the requirements of the business for which it was produced. One is not like another. A company can spend thousands of dollars building a single client API, but that investment will not carry over to another partner. API technology doesn’t necessarily create more efficiency in the value chain (or in industry, for that matter) so much as shift the burden of data integration to external parties.

So, given all the havoc a company could cause suppliers by moving to a proprietary data integration system, why do it?

Simple: Because it can.

The operational efficiencies an organization creates for itself by creating a proprietary API outweigh the loss of suppliers that can’t adapt. And it’s one thing for an E-Commerce business to dump Joe’s Shipping for onerous data-integration requirements, but it’s quite another when Amazon says the only way to automate the receipt of purchase orders is through its MWS API.

 

How Should You Build Your API Client?  

When the business case for establishing a connection to an exposed API is clear, the next step is to decide whether to use your business’s IT development resources—if you have them—to build your connection or to acquire a license to a third-party tool, like an integration platform as a service (iPaaS), to service your needs.

Here are a few things you’ll want to weigh in your decision:

 

• One-off or harbinger? API clients range in complexity, from executing a single microservice to several processes—all of which impact development time and cost. Yet perhaps just as critical as determining the specs of the first is anticipating whether you’ll need more API clients to integrate with other partners in the future. Third-party tools can be more adept at handling the same process or processes with multiple partners. And aside from skirting development costs, you may be saving your IT team from dealing with an increasingly long set of maintenance responsibilities.
• Is your software equipped? If you plan to use an application like an enterprise resource (ERP) software to send/receive API calls, be prepared to check (and probably question) the fine print. Although your application of choice may be dynamic in its own environment, don’t be surprised to learn it doesn’t play well with others. Specifically, make sure it supports your partner’s API. If not, be prepared to look into middleware, like an iPaaS, to connect the dots.

 

So, if looking into a third-party solution is the way to go, here’s a few companies you should add to your short list:

 

• Babelway – Specializes in B2B integration and streamlines support for companies that need API connections to multiple partners. Because not every API connection is available off-the-shelf, Babelway’s experienced—yet agile—development team can guide you through the selection of available connectors or the production of an ad-hoc platform.
• Boomi – Supports real-time integration and elastically scales to meet high-volume needs in mobile, batch (ETL), and EDI environments.
• Jitterbit – Designed to handle the most complex integration challenges between legacy, enterprise and On-Demand applications.
• Mulesoft – Uses API-led connectivity to create an application network of apps, data, and devices, both on-premises and in the cloud.
• Snaplogic – Allows enterprise IT organizations and lines of business to connect faster and accelerate the adoption of cloud apps.

 

Data integration using API technology doesn’t have to be daunting. When the time comes to establish an API connection (because it will!), you’ll be ready to assess future needs and software integration capabilities before you do.