By: Ritesh Keshri, Director, Software Engineering, LTIMindtree

Infrastructure, in the software world or real, is rebuilt, repaired, or restored over time, but there comes a stage when replacement becomes inevitable. An old infrastructure becomes outdated to meet the current demands or modern infrastructure emerges with superior capabilities. In either case, there arises a need to re-assess the existing infrastructure and plan for the upcoming big thing. In the next few pages, we will analyze one such scenario where an existing and aging but resilient infrastructure, EDI (Electronic Data Interchange), faces the challenges of extinction due to the introduction of APIs. The big boggling question here is – Are new-age APIs on the path to eliminating decades-old EDI?

A vital necessity for B2B integration is to quickly and securely connect and communicate accurate data between trading partners. Different EDI and API (Application Programming Interface) business Integration solutions fulfill this essential requirement, yet they have their own differences that override each other. To complicate it further, there are a variety of legacy systems, cloud applications, integration tools, communication protocols, and multiple standards and versions spread across different trading partners, which makes supply chain integrations incredibly challenging.

EDI, which emerged during the 1970s, is a proven backbone for B2B integrations. It is widely used across the logistics industry, including supply chain, distribution, manufacturing, retail, banking, and utilities. It has been the most reliable, secure, stable, and globally accepted standard, yet it is too rigid to change and cumbersome to implement and maintain. Unlike EDI, which shares information in batches, APIs enable synchronous integrations with real-time data. They allow interactions by exposing the functionality and services of an application to the external world. They are cost-efficient, can be implemented quickly, and are easier to implement and maintain. The code is simplified and structured to clearly define a common understanding between different components of B2B Integration.

Let us take a quick look at the current challenges which are driving industry experts to debate over EDI Vs API.

High level of customizations

While EDI originated to standardize B2B communication, over time, it has evolved into multiple standards, versions, and message types. The following add to the complexity and customizations that are needed before a trading partner relationship via EDI can be successfully established:

• EDI Software
• Communication Protocols
• Transmission Methods
• Mapping & Translation Software
• Business Process

APIs, on the other hand, are straightforward to implement. They are simplified, and structured and clearly define how subscribers can consume the data exposed by API. They run on a standard http protocol, meaning connections to new partners do not require agreed-upon transmission protocols like EDI. By relying on common digital building blocks, an API can make repeated, complex processes across multiple systems highly reusable with minimal code.

Cost of implementations

Customizations call for high costs. The infrastructure, software, and translators come at a premium cost. EDI specialists and developers who implement and maintain the EDI systems quickly add to the cost over a limited time. Third-party EDI providers offer expertise and connectivity with their registered partners. On the other hand, the cost to support can be quite high for large suppliers. It summarizes a substantial investment of time and a high cost to run.

Using APIs as the building blocks for the supply chain enables real-time visibility without the costs of customizing EDI. Re-usability of APIs makes them much more cost-effective. By not requiring ongoing maintenance or translation services, it is easier to implement and cost-effective to maintain. Because programming with APIs is easier than with EDI, it also opens access to a broader pool of affordable talent.

Batch delivery

EDI implementations are designed to be file feed or batch delivery and hence have the inability to adapt to the newer age technology standards. They also lack the capability of real time validations. So, a partner has to wait hours or days for a response EDI, resulting in probable chargebacks for invalid data.

Unlike EDI, APIs enable information sharing between 2 web-based software platforms in real time. They are synchronous and hence work on a request/response format. It allows real time data validations if incorrect information is submitted to a trading partner. An API can reject the request and list down the errors. Via APIs, customers and partners have access to business and data services on any device and from any source.

Integration with other systems

Although EDI standards have a very robust structure, they cannot be used to integrate with software tools, sensors, on-floor applications, etc., in the vast industrial ecosystem. This makes it a stand-alone standard capable of data transmission only between agreed partners.

APIs use the standard HTTP (Hypertext Transfer Protocol) protocols and RESTful services, enabling them to easily integrate with numerous applications. Integrations with all new-age technologies are simpler as they all connect via APIs. So, it empowers the user to create custom solutions that communicate with other applications, services, and external systems.

Interpretation of the standard

EDI standards govern not only the data elements that need to be exchanged between trading partners but also the position and relationships between those elements. To add to the complexity, the entire EDI message is written with pre-defined cryptic tags that require expertise and time to learn and implement.

APIs, on the other hand, simplify these complexities by using only the data elements that need to be exchanged without the need to be dictated on the position and relationship of the data elements. It can take data from numerous programs and present everything in a normalized view. Formats like JSON (JavaScript Object Notation) and XMLs are much easier to understand and implement.

Conclusion

APIs have some innovative features that make them a growingly popular option; still, EDI remains a popular choice because of its robust security and reliability. APIs are essential to sustain in the digital world, but it will take time and financial investments to see significant cost savings in the long run. Although there are multiple forecasts that APIs would replace EDI connections in the long run, it is highly improbable that enterprises that have working EDI connections are going to change their systems so soon. It is so tightly coupled with the core business systems that the risk of failure with the migration to API is remarkably high. Whether it’s EDI or API, organizations also have to align with their trading partners, and compliance regulation needs. The only way we might see a significant shift away from EDI is if all the major players in the supply chain moved away from it, forcing smaller companies to follow.

Even if API is not yet at the point of completely replacing EDI as the new standard, it is still an excellent choice. EDI will remain a significant tool for B2B communications, but there will also be the right balance for API to support the digital economy. Organizations will start to supplement their EDI communications with APIs so that they can enable access to real time data and digitalize their core-business processes. It is only a matter of time and an organization’s eagerness to take risks!