Use and advantages of APIs and EDI in data exchange processes in the Supply Chain
In the world of EDI, industry-specific standards play an essential role. Uniform implementations of electronic data exchange make systems stable, but also sluggish. In contrast, APIs enable real-time supply chain management – transparent and controllable. However, a comprehensive, cross-organisational or even cross-industry implementation often fails due to a lack of standards. Nevertheless, APIs are seen as the way of the future. Some are already predicting an imminent end to EDI. But is that really the case? After weighing the pros and cons, APIs are the future of data exchange. They will replace particularly time-critical EDI processes in the future. EDI will remain with established processes.
APIs in Supply Chain Management – Do APIs herald the end of EDI?
Supply chain management became established in Germany in the mid-1990s. It stands for overcoming internal and external company boundaries. The holistic approach focuses on controlling and improving all production steps. Starting with planning, through procurement and production to distribution, all steps of data exchange are covered. Furthermore, this also includes activities that are not within the sphere of influence of an individual company.
The key to success lies in a functioning flow of information that can be automated. For this purpose, business processes such as ordering or invoicing are digitally modelled. But time-critical processes, such as those that occur in just-in-time production, are also (partially) automated. What sounds excellent in theory often comes up against limits in actual practice. Even in the 2020s, common EDI standards are still derived from standards from the 1990s. And this despite the fact that there have long been more up-to-date versions. In addition to the “never-touch-a-running-system” principle, there is also the fact that EDI standards allow many options. In actual practice, such an open standard leads to a multitude of implementations that deviate from each other to a greater or lesser extent. It must be ensured that all partners involved in the data exchange implement the same variant of a standard. Thus, in practice, standards are degraded to application recommendations.
The data exchange itself is document- or message-oriented. This means that even with small changes to the business process, the entire message must be coordinated with all partners involved and implemented by all of them on the same deadline.
APIs are seen by many as a way out of this dilemma. Even though APIs could be used to transport the same messages from A to B, this is not the idea behind them. Rather, by breaking down the document and message structures, they make it easier to carry out these and entirely new business processes. Supply chain management in real time with APIs is the declared ultimate goal. So do APIs herald the end of EDI? A resounding yay.
APIs the drivers of interconnectivity
APIs are the electronic connective tissue of our global world today. They are now included in almost every piece of software that communicates with other software, for example via the internet. As a means of B2B data transfer, however, they are quite new. For companies, they bring cost advantages, efficiency gains and increased service quality. They improve existing or even enable the implementation of new business processes. It is not for nothing that a study by McKinsey put the expected profit potential of APIs at one trillion US dollars.
With the help of a sensibly designed API, systems that are independent of each other can communicate with each other. The API “lies” between the two systems, so to speak. It builds the bridge between the systems and specifies the format and type of data transmission. But EDI can do that too. It gets exciting when APIs are part of the business logic. For example, they are not used exclusively for data transport, but also take on service tasks. For example, they notify a system when certain conditions are fulfilled in another system. Most people know this when they have ordered something in an online shop. They automatically receive a message when the delivery of the package is not far in the future. If implemented correctly, they offer another decisive advantage over EDI: supply chain management in real time with APIs.
Real-time supply chain management with APIs
This aspect opens up the possibility for companies to cooperate even more closely with each other. Information is shared more quickly across multiple stages of the supply chain. Large logistics service providers often even use several APIs to improve their warehouse management. Via Inventory Management APIs, B2B customers’ systems are informed in real time about the current stock level of a certain product or about free delivery capacities. Thus, customers view stock levels directly in a web shop in real time.
Ordering rhythms and process chains can be managed more precisely via such APIs. This offers decisive competitive advantages over other market participants. In order to use an API successfully, however, a number of requirements must be met.
Barriers in API development
When specifying an API, it is first necessary to define what the API should do. What exact service is to be provided? With which existing systems should it interact? Should the API be freely accessible or only for a closed group of participants? How many queries of the API are expected? And last but not least: What business model is to finance the API? The first two points in particular must be made comprehensible to outsiders so that they can understand the API and use it properly. In addition, data protection aspects must also be considered in order to avoid misuse of the API. Not to mention that there are also intensive testing and iteration phases. But is the effort worth it, and can an SME even afford such a step?
Yes, because the hurdles from a developer’s point of view are much lower than in the EDI world. EDI development usually requires specialists or the corresponding service providers. The further away the partners are from the established EDI markets, the more difficult it is to find the required knowledge and experience. Today’s developers, however, have grown up with APIs around the globe. This is because the current APIs originally come from the provision of services on mobile devices. This starts with map displays and navigation and goes all the way to automatic translator APIs that provide videos with automatically generated subtitles.
The specification of APIs is also comparatively simple. Especially if the tools used allow the existing data structures to continue to be used.
EDI – a phase-out model?
EDI is still the established approach for transmitting structured business-relevant data in the B2B environment. Several aspects speak for a positive future of EDI. The connections established between companies have existed for many years. Certain EDI standards have become established within the industry. Not adhering to these standards usually means having to adapt the established contracts. Successful EDI projects serve as a reference. Their data structures form the blueprint for further implementations. Harmonised EDI workflows have also developed for data exchange between industries through converter software and mappings. Through years of work, developers and supporters know what to look for when fixing errors or setting up a new EDI connection. In many cases, EDI is considered very reliable by companies because they have been using the same message standard since the 1990s. Never change a running system is the motto here.
What speaks against EDI is the lower flexibility and scalability. APIs are designed to be flexible in their functionality and to be used by a varying number of users at the same time. At the same time, they only transmit the concretely required part of the information. EDI messages, on the other hand, can be so extensive that it is technically almost impossible to transmit updated information in a time window shorter than 15 to 30 minutes. The focus on the exchange of business documents entails high maintenance and servicing costs.
Unlike the use of APIs, when an EDI message is sent, the sender does not receive an acknowledgement of receipt or a response immediately by default. Of course, something like this can also be realised with EDI. However, this means the implementation of additional (return) messages.
So, is the API the solution par excellence?
Today, the benefits of API are often offset by the need for greater collaboration to achieve communication standards. Instead of reusing uniform data structures as in EDI processes, APIs are implemented in a company-specific way. This is especially important when new trading partners are connected. Often, the larger partners define the APIs to be used for their suppliers or customers. However, at the latest when there is to be cross-industry or cross-process communication, major incompatibility hurdles arise. But it is precisely at this point that initiatives such as those currently being pursued by large standardisation organisations offer hope.
A clear yes and no to EDI
In conclusion, as an “old” basic technology, EDI works well, but it also has its limits. For companies, introducing a new technology for functioning processes means taking staff away from day-to-day business and thus risking a decline in the company’s performance. With this knowledge in mind, it seems quite unlikely that companies will completely replace EDI (in the short term). Established EDI processes are often mission-critical. They will remain in place unless there is a compelling reason to replace them. APIs are the future of data exchange. For the foreseeable future, however, they should be viewed as complementary to EDI. In particular, they are introduced at an early stage when particularly time-critical processes need to be optimised. Thus, real-time supply chain management with APIs is a realistic approach. But not a complete replacement of EDI.
