There’s an ongoing debate about utilizing APIs vs EDI for trading partner communications within the supply chain. EDI (Electronic Data Interchange) was first created in the 1940s-1950s as a set of messaging standards so supply chain 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.
APIs (Application Programming Interface) were created as a means to make data and applications available as a service to a broad base of consumers. When Amazon launched S3 (Simple Storage Service) 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 create 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. For example, 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?
There’s an inherent complexity that’s irreducible in trading partner communications: 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:
- New partners must be tested and onboarded
- Changes to trading partner applications occur
- Changes to internal applications 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% 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. API’s 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, like iPaaS solutions, may be certified “out of the box” but compliance breaks down after the first line of code is developed without the right controls. 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?
In conclusion, API usage will continue to grow in trading partner relationships. When forming an integration strategy, businesses should consider the following key factors before replacing EDI with APIs:
- Are legacy technology assets compatible with the digital era? What level of effort will be required to transform and orchestrate data for consumption via API?
- What levels of symmetry exist in trading partner relationships and will changes to communication be easily accepted?
- Given the previous two questions, will the rate of API adoption justify the effort to establish the capability?
- What types of data are being shared and will the considered approach create compliance and security risks?
Following these guidelines will allow firms to assess their readiness for APIs and the level of effort to execute an API-driven strategy for their trading partners. Liaison Technologies addresses the effort vs. reward problem by providing a secure platform through a managed service that allows our clients to make their legacy data assets available in a modern, digital form.