EDI Vs API - complementary not competitive

It’s hard not to notice the up-swell of API Management in the press in recent times. If you come from an EDI background you may dismiss API Management as not being relevant. I also often hear the contrary view - that EDI is old-school and that APIs are taking over. 

I don’t believe either to be true. 

There are plenty of Qualities of Service that EDI gives in spades that API management simply doesn’t touch and vice-versa. In this blog I’ll review those differences and show how API and EDI are complimentary technologies not competitive. I'll also suggest where the future lies for these two differing technologies and that, actually, the comparison isn't EDI Vs API but should be API Vs Web Services.

EDI v API: Compare and Contrast

Below I've shown the two technology stacks side-by-side. We can see that both EDI and API sometimes share HTTP as a common transport and some of the security protocols underlying the transports. 

EDI Vs API

However, we can also see that API Management is missing the specific transports or handshaking qualities of service that EDI has, such as OFTP or AS2. Nor does API Management have any defined message types such as EDIFACT or X12. 

Those message types and security protocols are the mainstay of EDI. It's this rich set of well-known specifications that allows businesses to send messages to each other with guaranteed results.

One conclusion we can draw is that REST is a simple protocol that defines nothing about the messages it sends or any implied flow of messages. We can also conclude that API management isn't providing much benefit when we look at just the protocol stack; therefore, the key benefits of API management are elsewhere.

Origins: Compare and Contrast

EDI has grown into a rich set of message formats covering all the interactions required in the specific problem area of supply chain and B2B. 

API's have come around because of a very different problem statement. API Management has evolved as an anti-pattern to the Web Services standards which are seen as unwieldy both to understand and implement. APIs and the tool sets that are growing up around them are all about helping the developer get up and running quickly with the whole range of the solution: Interaction with the back-end resource, security of those resources and ability to easily expose those resources so that they are accessible to developers.

API Management excels in wrappering those hard problems with simple interfaces and simple development environments thereby making difficult things easier to do.

I've discussed in more detail the comparison of Web Services and API in this previous entry. In this entry I highlight that API-Management has come around due to ever-more real-time requirements and rich mobile client environments. These rich clients are being developed by a new generation of solution programmers who are driving new ways to get to data.

To understand the ramifications of this environmental and architectural change in terms of EDI we need to look at where Web Services fits into the EDI use-cases.

API Management: The EDI use-cases

The figure below shows an EDI exchange where Partner A places an order for some widgets from Partner B and receives an invoice.

Partner A orders from Partner B

What happens next is that the Purchase Order starts a business process inside Partner B. As the order works its way through the order process, Partner A might want to query where their widgets are. EDI doesn't generally help us with these 'secondary' interactions. There are EDI document exchanges that allow e.g. orders to be queried but these are not defined in many of the data sets and are generally not used. In the past these secondary calls from partner A to Partner B would quite often be done via web service calls. This may well utilise an ESB in the middleware.

Partner A Queries Order through WS

The reason for the Web Services interface being used was because it was the best option for Partner B at the time. This could have been because say, Web Services was part of a bigger modernisation strategy at the time of writing the solution, or they had good web-services skills available to them, etcetera, etcetera. 

The point being that there are numerous reasons for choosing to use a specific technology for those secondary interactions and these often change over time. Web Services has been the technology of choice since the late 90's. I've discussed above and in my previous blog that APIs are now that technology of choice because of its simplicity to create solutions and the way it wrappers the underlying complex technology.

This is the perfect storm, as they say. API-Management is usurping the web services domain more and more and the EDI space is no exception. Where once a web service would be created with all of its complexity there will now be APIs with all their simplicity and developer led tool-kits speeding time-to-market. 

This doesn't change the fundamental EDI exchange which starts the process but it does affect the way the process interactions are done later on in the supply chain. Everything from the client looking for an order update all the way to the truck drivers reporting expected arrival times to the end consumer.

Conclusions

In this blog I've shown the origins of EDI; the secondary interactions required with the business process after the initial EDI interactions have taken place and the drivers behind API-management adoption. 

I've shown that the reason for APIs being popular is not because they have the same richness as EDI but because they have been driven by the ever-increasing speed of markets and changing client interface demands.

The natural conclusion to this is that EDI is here to stay in some format. It may well change over time but the richness of the formats and the large incumbency is too valuable to ignore. 

It's in the secondary interactions where API-Management has a large part to play. Ensuring more and more real-time information is available to those rich-client interfaces when it's needed and that the solutions are written quickly in ever more rapidly changing markets.

I will add in one other hypothesis... API-Management excels in the wrappering of underlying technology to enable reduced time-to-market. I believe that this is just one of the first technologies to do this and that its influences are going to be quite profound in the coming years. This may well force EDI and other technologies to take on that simpleness of interface and ease of administration that API-Management heralds.