Global Logistics Planning Guide: THE GREAT DEBATE
APIs OR EDI FOR SUPPLY CHAIN TRADING PARTNER COMMUNICATIONS?
There’s an ongoing debate about utilizing APIs vs EDI for trading partner communications within the supply chain.
Electronic Data Interchange (EDI) was first created in the 1940s-’50s as a set of messaging standards so trading partners could easily communicate with one another. In a standard EDI process, a company sends an electronic file that conforms to an agreed upon format, for that message’s purpose, directly to the recipient’s computer. Today, EDI is transmitted over the Internet and encrypted using what’s generally called B2B Gateway software to establish a secure connection between trading partners. This includes common transmission protocols such as FTP, AS2 and HTTPs.
Application Programming Interfaces (APIs) were created as means to provide broad connectivity between an application’s services and other users. When Amazon launched Simple Storage Service (S3) in 2006, and made the service available via API, it opened the door for entire enterprises to be supported through the cloud.
Today, IT leaders are challenged with satisfying internal and external customers, while business units outside IT want to reduce cost barriers to integration and use data as a competitive advantage. APIs offer the promise of lower integration costs, the ability to make data more accessible and creating new streams of revenue.
However, new challenges come with new capabilities. EDI is an accepted convention that already follows business processes. For example, if a company sends an 850 PO document to a supplier, the recipient already knows to begin the order fulfillment process.
APIs, in this context, would require more collaboration. Each trading partner must agree on the semantics and granularity of the data. One trading partner may refer to a data set as the “shipping location” and the other partner the “shipping address.” How will the consuming system of record understand the relationship between the data? Also, a single EDI purchase order may require 50 operations within an API. If the message is split into a series of calls, can the consuming back end receive that information without performance issues?
An inherent complexity that’s irreducible in trading partner communications are variances in data structure and messiness in securing a protocol. Some of the same challenges with EDI will apply to APIs when one or more of the following events occur:
At the end of the day, communication standards are really determined by the level of asymmetry in the trading partner relationship.As an example, many credit Wal-Mart with normalizing the use of EDI within the consumer goods supply chain.
On the other side, Salesforce, eBay and Amazon were some of the first companies to make their data available to a broad base of users through APIs. How the data was used to support a particular process was up to the consumer of the API. In either case, a single entity isn’t in a position to ask Wal-Mart or Salesforce to provide a different method of integration to better fit its own needs.
Businesses looking to replace older EDI models with APIs for their B2B transactions should consider the level of asymmetry, and whether their trading partner will be willing to conform data to the intended business process. Bottom line: The information must be translated somehow. The question is, who will do the work? In an API-only world, that work will get pushed down to those with the least leverage.
Previous investments in legacy technology also mean it will be extremely unlikely any business can communicate exclusively via API. Gartner estimates that 25 percent of B2B interactions will be performed through APIs by 2020 while the majority will still be handled by “legacy approaches.” Businesses looking to take advantage of APIs with trading partners should consider whether their technology is able to support both approaches effectively.
Another overlooked challenge with an API-driven approach is compliance.APIs leveraged in a federated development environment increase risk profile and may inadvertently create vulnerabilities or exploits without a strong uniform data governance process and policy.
Developer tools such as iPaaS solutions may be certified “out of the box” but compliance breaks down after the first line of code is developed. Sensitive financial data, like freight payments and invoices, are subject to audits designating which individuals have access to the information. If businesses grant access to an undefined group of future integrators, how will they fulfill their compliance responsibilities to customers?
Ultimately, Liaison Technologies believes the citizen integrator approach is the wrong approach to leveraging APIs and leads companies down a dead end when it comes to innovation. This is because the promises generally stated about APIs replacing EDI reflect an application-to-application paradigm in addressing integration.
By building new APIs for every integration use case, companies are taking their eye off the ball, and neglecting to focus on creating sound governance that will enable the ability to make data available in any scenario. Companies will inevitably constrain their application purchase and design choices around the ability to maintain integration processes. Furthermore, new use cases for the same information will require more APIs to be extended to applications, analytic models, etc. That’s why Liaison engineered the ALLOY Platform to collapse these disparate forms of integration into single service that adheres to the highest levels of compliance.
Application Programming Interface usage will continue to grow in trading partner relationships, and APIs can and should be leveraged where it adds value. However, it is unlikely they will completely replace EDI.
When forming an integration strategy, businesses should consider three key factors before replacing EDI with APIs:
Following these guidelines will allow firms to leverage new technology effectively and sustainably.
No comments:
Post a Comment