In a previous post, APIs vs EDI: Complementary, Not Competitive, I shared my perspectives on the evolution of APIs along with EDI. I'm going to expand on this topic with the idea that agile methodologies may have more to do with the current proliferation of API Management than the usurping of EDI.
Let's be clear…EDI is most certainly here to stay for a long time to come. I've read many articles and debates on this subject but, for me, what it comes down to are those well-known business interchanges.
We can't just ignore the fact that EDI has evolved to where it is today because business needs well-known formats so that they can communicate with each other in a standardized manner. APIs, at the moment, simply don't have those standardized formats. When a company creates an externally-facing API they are, today, writing their own business interchange format (i.e. trying to reproduce an EDI interchange).
Now, that's fine, however, if each company is going to create its own format then communication between companies is going to revert back to being a spaghetti mess of protocols. This is exactly what EDI was meant to overcome, and why EDI has been so successful for so many years.
You may have noticed that I'm being very explicit when I say "external" communications. I define "external communications" as communication that makes its way to the external partner. I then define "internal communications" as how those external communications make their way back to the core systems, SAP etc.
I see these external communications as where most people seem to discuss the API vs. EDI debate. At this point, I stick with my previous argument - APIs simply don't have the common protocol and format to allow business to communicate effectively. However, it's more complicated than that...
There will be attempts to recreate in APIs those interchange patterns and wire protocols that EDI already has. This happened when SOAP and XML came into favour and it's the natural direction for APIs to go as well. So, we will see "well-known" APIs that emulate the transaction patterns that EDI has created over the years. Before they are defined, APIs are still going to be used externally but just in an ad-hoc, per company, manner.
APIs have been driven by the mobile generation, so APIs are needed to ensure that your business can communicate with those new "cool" B2C applications. APIs are also being used to create new channels with new, "cooler" B2B applications. This gives us the picture below.
What percentage of EDI versus APIs a business ends up with is going to depend on the size and type of the business as well as its age.
Containers, microservices and Agile development methodologies are all synonymous with APIs, and they're all focused on shortening that vital time-to-market.
I would estimate that around 90% of API strategies are focused initially on the internal communication. APIs are being driven by agility to respond to new internal business challenges far more than they are by creating new external interfaces. Companies are using APIs hand-in-hand with their agile methodologies to get them from A to B quicker than they could with Web Services architectures.
The picture below shows the internal systems API layer. There are then one or more API layers above that. the final layer is that external B2B or, more likely, B2C exposure layer. Alongside that is the current estate using an EDI/B2B platform (I've chosen to use the IBM B2B Integrator (B2Bi) product here.)
There are two other things to note here.
Point (1) shows a connection from a new, external API to the current existing partner network. This interaction could occur if, for instance, the partner has a new app that they are exposing to their customers and they need your data for it.
Point (2) is showing that the B2Bi platform could make use of the new APIs as well to augment itself with new function.
I don't believe that EDI is going away anytime soon. API's simply don't have the rich protocols in place to replace it. However, APIs certainly have a very big part to play in today's B2B world by allowing enterprises to maintain agility when creating new channels and applications.
Finally, we will almost certainly see B2B/EDI standards emerging for REST APIs. These will enable EDI-like communications to be executed effectively and consistently via APIs in the future
To learn more about this and related integration topics, check out the API Management and B2B integration sections of our Resource Library.
About John Hawkins
John Hawkins is the CTO for Lightwell.
He has extensive experience in the middleware and integration stack having worked at IBM, IBM Business Partners and WSO2.
During his time as an IBM MQ architect he led IBM's Cloud strategy and architecture for next generation, Cloud Centric, Messaging.
John is an innovator and naturally "sees the big picture" which he has demonstrated not only through his work at Lightwell and previous roles, but also his large patent portfolio.