EDI vs API in the Amazon eraOn September 8, 2020 by Karthikeyan Mani Kannan
EDI vs API is a constant debate. EDI has survived and done well against API so far. However, the retail industry has changed at an incredible pace ever, thanks to Amazon and the e-Commerce race between Amazon and the other giant retailers such as Walmart. Is it time to take a closer look at how EDI fare against API? Most definitely, yes.
Let’s analyze what API brings to the table as far as integration goes and compare them with EDI.
The Amazon era customer experience is marked by speed, accuracy, transparency, and omnichannel presence. All the other retailers are catching up to the game, making significant investments in eCommerce and omnichannel initiatives. Organizations are ever-increasingly facing orders that are low in volume at a high frequency. There is a heavy price to pay for non-satisfied customers in terms of chargebacks and, most importantly, online reviews affecting the long term prospects of a brand.
The bottom line is that; the way brands are selling has changed. In an environment that demands tighter integration and more automation, unfortunately, the way organizations exchange information with each other has not changed. Organizations in a supply chain still exchange purchase orders, invoices, shipment notifications using EDI.
This is not the first time EDI is compared with API. EDI has come under scrutiny, and they survived, which is a testimonial to the validity of certain parts of EDI. On the other hand, there are parts of it that have to go away. It’s not an option anymore for retailers, brands, and developers.
The Need for EDI evolution
EDI has been stable enough and worked in the past, but it requires considerable expertise. EDI carries pre-internet era design principles because of which they are not catching up to today’s demands. For business owners, that translates to a substantial investment of time and a high cost to run integrations smoothly. The steep learning curve for all stakeholders, a growing shortage of expertise, longer integration time, lack of real-time validations, and a lack of openness are consequences of EDI’s pre-internet design principles.
Things don’t have to be this difficult. And I am not arguing for the total eradication of EDI as well in the EDI vs API scenario. Organizations that have already heavily invested in EDI for B2B integrations should complement their existing EDI infrastructure with APIs.
EDI vs API – Round 1: APIs makes integration easier
EDI standards dictate (1) the data points that need to be exchanged, for example – Purchase order number, SKU, quantity. (2) The position of these data points in the payload – the segment and element number, and (3) the relationship between two or more data points. These are some hard details to get comfortable with and time-consuming.
As you could tell from Figure 2, the EDI data is positioned based. In simpler words, you need to know where to place the data point, and this has to be done according to the EDI specification. Most modern-day developers lack this knowledge, and they have to go through a very steep learning curve.
APIs can abstract these complexities and simplify things down to the list of data points that has to be exchanged, instead of asking the developer to take care of the position and the relationships. API data formats like JSON, XML are much more human-friendly and easier to read, program, and customize.
EDI vs API – Round 2: APIs can bring in real-time validations
Even a simple user registration form that you come across on any website has validations. They don’t accept your registration if, for example, you enter an invalid email address. Critical business transactions deserve the same as well. One of the major drawbacks of EDI, as it exists now, is the lack of real-time validations.
In contrast, if you are submitting incorrect information to your trading partner, API can reject your request and also list down the errors. That eliminates the exchange of invalid data between partners, thereby increasing data accuracy. With the way things are now, you will have to wait for a response EDI after you have submitted yours, which might be hours or even days resulting in backlogs. In the case of retail, there is a heavy price to pay for the lack of real-time validations in the form of chargebacks
EDI vs API – Round 3: APIs make your EDIs composable, and that’s powerful
All the different kinds of apps that we have on our mobile phones are just different ways in which APIs are composed. When you book a cab using Uber, it’s the power of APIs doing the magic. APIs make your EDIs composable. Meaning, it will empower you to create custom solutions easily that can communicate with other applications, services, and external systems. That makes you omnichannel ready and also allows you to automate the painfully manual portions of your business.
A pattern that we have observed with our customers is the increasing demand for custom tools that automate processes, enable them to monitor issues, and make corrections, and importantly extract KPIs. Such tools empower them to be proactive.
Traditional EDI middlewares act almost like a black hole. Getting information out of them is not straightforward. For an organization that wants to be proactive, this is an obstacle.
EDI vs API – Round 4: Tapping into commonly available talent pool (API Developers)
There are more developers who can figure out your current location using GPS than developers who can send a shipment notification to Walmart. That’s a shame. GPS is no joke. A minimum of three satellites with atomic clocks in them, transmit a signal to your phone, to narrow down your coordinates on earth. These satellites also account for General and Special Relativity. But for mobile app developers, fetching your current location is as easy as it could get. It’s possible because of the power of APIs. The API abstracts all the complexities away. EDI, on the other hand, exposes all its complexities even today.
With such hyper-growth in eCommerce and a shrinking EDI developer population, how are organizations going to find their developers? For a developer new to EDI, the standards can be such a steep learning curve. You don’t learn these things in college. You don’t find courses to learn EDI standards even on the most popular online course platforms.
On Stackoverflow, which is one of the top Q&A sites for programmers, there are only 440 open questions on EDI, while there are around 72,109 questions on API as of December 2019. According to Stackoverflow’s 2019 developer survey, more than 50% of developers are full-stack developers. Organizations should tap into this massive talent pool that is commonly available. Also, that would break the long-held walls of secrecy by large EDI service providers who aren’t living up to the expectations. Managed EDI services rely on slowing things down, not on speeding things up. That’s their revenue driver.
Expert opinion on EDI vs API
Zacc Roelke / DELL
Zacc, is a Product Manager for Dell’s B2B eCommerce offering, Premier. One of his goals has been to understand customer pain points and translate those needs into actionable engineers solutions. DELL has launched an API platform for procurement integration. I spoke to Zacc to get this thought on why they chose API for integrations when they have an existing EDI infrastructure.
Q. Why did you pursue APIs for integration?
We decided to pursue API integration technology, largely for procurement operations, after evaluating strengths and weaknesses we had internally and externally.
Being a part of the eCommerce organization, Dell is strategically positioned to leverage our existing customer base to improve how we integrate with our customers. We have a very mature EDI integration path which integrates very well with ERP systems.
In addition, we have heavily invested in a modern data architecture which enable an infrastructure for a scalable API platform. We also saw an opportunity with customers who had modern ITSM business tools that were built in a much more API friendly manner.
Q. What results are you seeing in terms of ease of integration for suppliers?
We are seeing all of our procurement API Integration customers productivity metrics (time to market, time to onboard, feedback loops) trend in the positive direction. This boils down to simply, easy to read syntax in our documentation and easily configurable workflows from various ITSM business tool.
For simple buying patterns, we have seen customers integrate our APIs in a few weeks. For more complex buying patterns, we are seeing that the consistency in data has ensured our customers that their procurement processes are working as intended with a high degree of automation.
Tytus Wilson / Bulletproof 360
Logistics Operation Analyst
Tytus works with Bulletproof 360 as a Logistics Operations Analyst and has been with them since their early stages. He saw through the first batch of EDI integration Bulletproof did with the major retailers. The company has grown rapidly since then, and they are continually improving their IT capabilities to serve its customers better.
Q. What do you think is the role of API in terms of helping integration teams who dread EDI?
APIs are not likely to replace EDI, even though EDI is 1970s technology. You should develop APIs that account for EDI and have the two work together. APIs should primarily organize data sets for the transmission of EDI.
The best developers who work with EDI and APIs are the ones who visit their warehouses and spend time correlating what is on the floor with what is in the system. There is a nuance involved in working with such technology, but once it comes together, it’s incredibly powerful.
Q: How costly can an incomplete understanding of EDI by an IT team be?
EDI is a silent assassin within an organization, so you want to make sure it’s implemented properly. It can cost millions of dollars to fix preventable issues.
What’s great about EDI, is that it can be as automated, or as hands-on as an organization chooses. It’s important to build out solid standard operating procedures, and to not rely on temporary “duct-tape” solutions over the long term.
Q: What’s the next major step for Bulletproof?
We’re always putting our fans first! Bulletproof will continue to innovate in targeted categories to provide our customers with world-class products.
We are fortunate enough to have the ability to quickly adapt to a constantly changing technology landscape. Between EDI, API, and even blockchain, exciting days are ahead.
Conclusion on EDI vs API
GS1, the organization that develops and maintains global standards such as GS1 XML, GS1 EPCIS, has proposed a strategy to adopt APIs for EDIs. APIs are increasingly becoming a necessity to survive and compete in the Amazon era. The problem is not that EDIs are unstable. Done correctly, EDIs are stable enough. That’s why they have survived the API threat before. But the times are changing.
When you look at EDI vs API, APIs are far easier to deal with, and that’s the contrarian truth. All the complexities of EDI don’t have to stare down at organizations. Instead, they should be hidden behind APIs, just like how the satellites finding your current location are. And to be realistic in achieving this transformation from EDI to API, APIs don’t have to replace EDIs completely. APIs can instead complement them.