EDI Must Die

Synopsis: Electronic Data Interchange (EDI) is an outdated technology that companies should actively work on abandoning in order to move into the modern digital age.

Warning: If your email signature has the title “EDI Specialist,” you may find this article offensive. However, it still needs to be said… EDI must die.

Consider this quote from an article published about EDI. See if you can catch any cognitive dissonance:

“In the quest to achieve a paperless society, electronic data interchange (EDI) has long been a leading technology. EDI predates the emergence of the Internet, and is now the chief electronic network connecting just about every business to every other.”

How can something that “predates the emergence of the Internet” still be considered a “leading technology”? Telephones were once considered a modern miracle–so was the telegram for that matter–but I would hardly call them state of the art.

Look at the image at the start of this blog post of the man at his workstation. It’s hard to believe, but in 2019 there are people going to work that are dealing with archaic EDI interfaces that look just like that. It’s heartbreaking!

As surprising as it sounds, many defenders of EDI use the fact that it is a technology from the 1970s as proof that it should be respected and promoted.

“EDI has been tried and tested! This old technology works. If it isn’t broken, don’t fix it!”

I completely disagree with the premise of the above statement.

EDI is broken

That’s why it must die.

In order to understand why, look at this–dare I say–vomit of text:

ST*856*48550002~BSN*00*33211128*20190201*2102*0001~HL*1**S~TD5*B****FEHD~DTM*011*20190102~HL*2 *1*O~PRF*33211128~REF*IV*00002~SAC*C*I132***0~HL*3*2*P~MAN*CP*04288227277943A~HL*4*3*I~LIN*1*VN* 032281286217*SK*95709125~SN1**1*EA**2*EA**AC~SLN*1**I***0~HL*5*2*P~MAN*CP*04288227277944B~HL*6 *5*I~LIN*1*VN*032281286224*SK*95709228~SN1**1*EA**3*EA**AC~SLN*1**I***0~CTT*2~SE*23*48550002~GE*1 *4855~IEA*1*000004855~

Do you know what this is? Most people don’t.

This is a stack of EDI data from a supplier telling their retail trading partner about an order they have shipped.

Why does it look like this? Why is it so incomprehensible?

The reason is that before the internet it was extremely expensive to move vast amounts of data. As a result, companies had to come up with a system to codify their data in order to limit the number of characters they would have to pay for.

But that was in the 1970s, I hear you say, surely that doesn’t matter now?

Actually, this is still going on as a lot of EDI providers and third party solutions continue to charge their customers per character fees on EDI data. And these fees aren’t cheap. If I was an EDI provider charging you to read this article you would owe me $5.40 (that’s words only, no pictures). Read a full edition of the economist and you would owe me over $52,000! Meanwhile, you can go home and stream gallons and gallons of data to watch movies and TV shows in your living room for a small monthly subscription fee.

Keep in mind that the example I showed above is only one type or mapping of EDI. There are hundreds of different versions and “standards” of EDI that companies use. So this block of EDI may work to give a shipping status for one retailer, but totally fail to translate to another.

In short, EDI is expensive, unreadable, and unstandardized.

Does this sound like a “leading technology” to you?

Let’s explore more modern options of sending data . . .

Today I could send the exact same data in that EDI block above in the form of an Excel or CSV file that everyone understands. It would look something like this:

That’s not the only way we could do this. As an even better solution I can post an API call that would update this order within seconds of my warehouse shipping it. Compare this to waiting for my EDI provider to send my shipping data in a massive batch document once a day. The JSON body of an API call would look something like this:There it is. One order that has shipped two different line items, each with a separate package and tracking number that identifies the carrier and method. Clean and concise data.

{

 “poNumber”: “33211128”,

 “packages”: [

   {“trackingNumber”: “04288227277943A”,

     “items”: [

       {“sku”: “032281286217”,

         “quantity”: 2}],

   {“trackingNumber”: “04288227277943B”,

     “items”: [

       {“sku”: “032281286224”,

         “quantity”: 3}]],

     “shipCarrier”: “FedEx”,

     “shipMethod”: “Home Delivery”,

     “shippingServiceLevelCode”: “FEHD”

     }

This data takes a little more effort for a human to read, but it’s a definite improvement from that unwieldy block of EDI text. Not to mention the real-time benefits of an API integration are far superior. API allows applications between two systems to talk directly to each other, without the cumbersome process of delivering a batch file document over an FTP or As2 connection. The result is real-time seem-less exchange of data.

In short, our data technology has moved far beyond conserving characters. It’s time for us to move on as well.

EDI must die.

But Why Isn’t EDI Dead Already?

The reason why EDI is still being used is that EDI-based technology has permeated multiple industries for decades. There are huge companies, thousands of trained specialists, and lots of money to be made off of EDI data integrations. EDI isn’t about to go down without a fight. One of the primary issues keeping companies from leaving EDI behind has been an overwhelming resistance to change.

This resistance to change can best be illustrated by the theory put forward by Everett Rogers called Diffusion of Innovations. When a new technology is introduced to a market, there are only a few “Innovators” and “Early Adopters” willing to take the initial risk to adopt the tech and improve their processes. Only when more and more of the “Majority” join in will the technology permeate the marketplace.

Then come the “Laggards,” or those who resist any change to their technology until the last possible moment. These are the people with VHS players in their living rooms. EDI users should be in this laggard category as well. Hanging on by a thread. Surviving on life support by a few old timers working with a DOS interface.

Unfortunately, EDI is still so widespread that you could sadly say it’s in the Majority on the diffusion graph (albeit the Late Majority). Many companies are simply not willing to let it go, despite the clear advantages to moving to other tech.

The adage “If it isn’t broken, don’t fix it” is alive and well with EDI.

The problem is people can’t see how broken it really is.

To help make this understanding happen, a more flexible approach is needed.

Killing EDI Softly with Standardization

To put the final nail in the coffin of EDI, standardization across multiple data formats is key. In other words, the way you want to send and receive your data should not restrict who you can and can’t do business with.

Today you should be looking for data translation solutions that take your preferred format (be it API, CSV, or *gasp* EDI) and standardizes it in one location. From there, your trading partner can integrate to that standard hub using their own preferred format. This allows for the Early Adopters to update their technology, without leaving the Laggards behind.

Companies stuck with a legacy system should be looking for adaptable EDI solutions that don’t pigeonhole themselves into one method of connection, but rather provide multiple data transmission options to work with. From there the transition out of old tech is made easier, and legacy systems using EDI can still interact and do business with more up to date trading partners.

The company I work for, Dsco, is doing exactly that (and I hope more and more third party solution providers will eventually do the same as well). I’ve spent countless hours working with virtually every EDI filetype in the dropship industry, becoming fluent in several retailer’s specific EDI mapping guidelines in the process. All this in an effort to help companies have their data “flow” between retailers and suppliers on an equal standard. I’ve therefore seen first-hand how cumbersome and inefficient EDI is, and how powerful multiple data transmission options can be, allowing old EDI-based systems to work with state of the art APIs.

For EDI to die, people need to realize that the only thing holding them back from adopting new technology is themselves. For my part, I’ll be anxiously awaiting the day I can lay the last 997* document at the foot of the EDI gravestone.

*A 997 is a “confirmation of receipt” EDI document type. Something completely unnecessary if using API, and something that definitely needs to die.