Can API and EDI form a tag team?

Businesses of all sizes can independently innovate using disruptive technologies and create a future that allows EDI and API to augur supply chain collaboration

Every so often people compare EDI with API (Application Programming Interface). EDI in a lot of ways are designed to mimic a paper transaction. At the simplest level, a group of documents in the real world would need to be mailed in a sealed envelope, handed to a mailman who then would send it via a transport to the receiver. In the EDI world, group of documents can be grouped by logical/functional needs as a transaction set, packaged in an interchange, the mailmen equivalent are computers with FTP as the transport. Given that legacy, EDI required a strong handshake between two computers to interpret and process what is intended to be done. While there are EDI standards, translation of file feeds requires skilled EDI analysts. Once implemented, the benefits are the cost savings enjoyed in sharing electronic documents instead of processing paper.

API is the EDI of the 21st century, a better way to transmit information. API enables real-time data exchange between two applications and allows the consumer of API decide on its use as relevant to the internal needs of the enterprise. This ability of one party to publish information to consume for anyone who sees use for it makes API’s very powerful. When the time comes for adoption, how does one choose between EDI vs API? If you are a supplier or wish to engage in business with global shipping lines, they typically dictate the specification and format that smaller parties must communicate. In the maritime world, this still remains to be EDI.

If the choice is not yours, can a maritime partner still innovate independently? Even more so, can they innovate independently by leveraging new age technologies such as IoT, Blockchain and the prevalence in mobile in everyone’s pockets? Consider this example: Let us say a pharmaceutical company wishes to track the temperature of a precious vaccine through its journey. You could say the pharmaceutical company can expect a periodic shipping notice document to understand where it is at selective transit points. While it is important to know where it is, in this case, it is mighty important to know how it is? Using IoT, the transporter can leverage sensors that can be dropped into a palette that measures temperature, humidity and/or tilt and aggregates into a local data repository. A purpose built application can publish API to retrieve this data using a global SIM at points of telecom network availability.

Once the transporter has this data, they can now enhance the periodic shipping notice with this information. This enrichment of EDI by leveraging API will allow both worlds to co-exist. While some may consider EDI to be arcane, businesses have appreciated EDI for the standards it provides. The strict nature in which the handshakes happen between two businesses are very convenient to documents that do not change often. EDI is secure and very efficient when high volumes of disparate documents have to be exchanged with traceability. API’s can make of EDI’s downsides. API’s are agile, low-cost to implement and can be developed to augment the slowness of EDI. In conclusion, enterprise innovation is about understanding and reengineering the business processes to achieve the desired outcome.

EDI will continue to serve its course even though it is complex, gibberish looking document formats. Business of all sizes can independently innovate using disruptive technologies and create a future that allows EDI and API to augur supply chain collaboration.