EDI Vs API: External Vs Internal Communications
Last year I discussed how I saw the evolution of APIs and EDI evolving. I'm going to grow that argument here to say that agile methodologies have more to do with API management's current proliferation 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.
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 businesses need well-known formats so that they can talk to each other. API's, at the moment, simply don't have those 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. Exactly what EDI was meant to stop and why EDI has been so successful.
External Communications
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.
 |
| Logical: External v Internal Communications |
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 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, I believe, we will see "well-known" APIs that emulate the transaction patterns that EDI has already got. However, before these are defined, APIs are still going to be used externally but just in an ad-hoc, per company, manner.
Why are talking APIs then?
APIs have been driven by the mobile generation so APIs are needed to ensure that your business can communicate with those new "cool" BtoC applications. APIs are also being used to create new channels with new, "cooler" B2B applications. This gives us the picture below.
 |
| Logical: External Comms with new APIs |
What percentage of EDI versus API a business ends up with is going to depend on the size and type of the business as well as its age.
Internal Communications
Containers, microservices and Agile development methodologies are all synonymous with APIs and they're all focused on getting that vital time-to-market down.
APIs are being driven by increased agility to respond to new internal business challenges far more than they are by creating new external interfaces. I would estimate that around 90% of API strategies are initially focused on the internal communication. 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.
APIs are being driven by increased agility to respond to new internal business challenges far more than they are by creating new external interfaces. I would estimate that around 90% of API strategies are initially focused on the internal communication. 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.
 |
| Internal APIs |
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 IBM's "B2Bi" product here")
 |
| Layered view on New API Channels |
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, a current partner has a new mobile 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.
Point (1) shows a connection from a new external API to the current existing partner network. This interaction could occur if, for instance, a current partner has a new mobile 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.
Conclusions
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 standards being created around REST/HTTP APIs that will allow EDI like "well-known" interactions in the future.
Finally some sense in the discussion on API and EDI. There is one point I would like to emphasize though. Apart from the standardisation that sets it apart, EDI and API are different in another way and I think this differentiator will stay, since it is (business-)process related.
ReplyDeleteEDI usually has a predefined trigger and communication is one-directional as a result of it. API on the contrary rely on a request/reply protocol and will (assuming data portion to be equal) therefor mean more traffic and higher system payload.
Or do API protocols have a solution for this?