When I got into EDI integration back in 1997, the technology had been around since the 70's! At the time of learning the ropes with all aspects of electronic data integration, how it was being used in business, and I mean, all sorts of business sectors were (and still are) using EDI for transacting critical business information from one system to another, it was classed as a stable way of communicating information via defined standards.

It worked well, and continues to work well today (when done right).

True Cost Of EDI

Fast forward to the 'twenties' and EDI is clearly not showing any signs of slowing down. Heck, companies are still using the same EDI standards (i.e. EDIFACT 90.1 meaning 1990) from years ago. If it ain't broke...comes to mind.

So, what does the future hold for EDI. Well, the technology is here to stay, but the way it is integrated will (or could) change. Supply chains across the globe could see a shift from outsourced EDI to having it all back in-house.

Why is that?

Smaller companies who adopted EDI would have had it all outsourced using a third-party, but as companies grow very large, they're finding it's not the best way of doing business.

For example, a simple Purchase Order, companies can pay a couple of cents/pennies per transaction, but soon realise, as more and more PO's come in, and I'm talking thousands per month, those cents/pennies add up to a considerable amount.

That's when they start to see the benefits of hosting an in-house EDI solution.

And now, third-party EDI companies are realising this shift, they too are changing their pricing structure, charging per relationship rather than per transaction.

Here's another trend that's happening on a global scale; there are now less and less EDI companies for clients and customers to choose from.

IBM grabbed Sterling Commerce, Liaison was bought by OpenText, Cleo purchasing Extol, and even EDI VAN's are following the same trend, GXS being acquired by OpenText.

All this reduces the playing field, and makes it more difficult for the smaller companies out there looking for an EDI solution to reduce their processing costs.

This is where it is crucial for EDI consultants, like my good self, help these companies navigate the market in the coming years when it comes to integration.

SME's Demand For EDI Grows

An in-house solution shouldn't be the go-to solution for all businesses. What we're now seeing is a burst of new iPaaS vendors saying they're putting this technology back in the hands of companies. Obviously, this gives the power back to in-house teams without the need for a third-party to be involved. But most of all, it allows more control back internally, which is a good thing for SME's.

Another aspect for increase in demand is being forced by the larger partners (think Walmart/Amazon). They're asked to support all the standards and technologies that are out there in order to do their business in the world of data exchange. And this is not going to go away any time soon. If you want to grow your business, you're going to have to meet these demands.

To eliminate tensions between large and small companies, can now be resolved using iPaaS vendors, controlled exclusively by the small companies themselves.

With that in mind, it makes a lot of sense for smaller companies that are heavily focused on growth, to turn to iPaaS vendors rather than integrate an in-house EDI solution.

This doesn't mean that larger companies won't also benefit from using iPaaS vendors, especially if looking to integrate with the latest technology, thereby replacing traditional EDI.

Happy With API's?

Here's a bold statement; EDI to be replaced by API's in the next 10-15 years. I remember the time back when I started with EDI and there was a bold statement then that XML was to replace EDI. Hmm, not! Anyway, turns out XML complements and adds to the level of versatility of using EDI (not replace it).

Okay, back to API's. So, for those that are new to API's, I have a separate article scheduled, so watch out for this in the near future. In the meantime, here's the crux of API's related to EDI integration.

An API serves as an interface between two endpoints to enable business information sharing in real-time. Companies have been creating API strategies to define how they allow their partner network to access certain information through API's. API's being synchronous in nature, allows for a smaller payload and work on a request/response basis.

If you're considering an API strategy, you might want to think about how you're going to handle communication with external partners that can have access to the company's data through API. While API's make data more accessible and empowers new business models, security should be given a top priority thought.

With that said, API's can be used daily when dealing with IT systems integration. You may wonder, how a legacy EDI solution gets involved with API's.

The simple answer is; EDI can be classed as old-school, time-consuming to implement, and costly to maintain.

Conversely, new entrants to the integration game, are utilising API connections. Can be implemented fairly quickly, and can be viewed as a cost-efficient solution, more so than traditional EDI. As said before, API's are synchronous, meaning they facilitate real-time data sharing, which carries all sorts of benefits for the trading partners communicating with each other.

But here's the thing; EDI and API's 'can' complement each other, especially if the IT landscape has a lot of variables in it, a lot of disparate systems in play, and not wanting to fix something that's not broken.

With all that said above, EDI will remain a significant tool for B2B communication. Yes, API's are becoming more commonly used in the digital economy, most new startups are taking advantage of API's. While EDI cannot match the timeliness of data sharing through API's, in an ideal world, you shouldn’t choose whether you support EDI or API. You could just have the right balance of both.