APIs vs. EDI: Not yet an either/or question

A panel at eyefortransport’s North American Logistics CIO Forum in Austin, Texas explored what is driving forward, and what is holding back API usage in the logistics and transportation world.    Earlier this month, I moderated a panel at eyefortransport’s North American Logistics CIO Forum in Austin, Texas on the use of application programming interfaces (APIs) in logistics, and also whether APIs might eventually replace electronic data interchange (EDI).
   This is a topic I’ve written about extensively over the last year, and so it was interesting to hear the perspective of representatives from three logistics companies, one transportation management software provider, and a software-as-a-service API provider on the state of acceptance right now.
   My takeaways were:
     • Because of the pervasiveness of EDI in freight of all modes, it’s not really a question of either/or when it comes to APIs and EDI. Logistics providers and transportation software vendors really need to be able to provide whatever the customer requires at this point. As Eric Rempel, chief information officer at Chicago-based Redwood Logistics put it, if a customer wants data by carrier pigeon, he’ll make it happen.
     • Progressive logistics services providers (LSPs) understand the value of APIs and can build an API layer that essentially transforms data in other formats into APIs for their own backend systems. As a corollary, it’s important to note that APIs can impact an LSP in multiple directions – integrations to customers, carriers, but also through backend connections to outside point systems that enable things like dynamic rates or inventory management. So even if none of an LSP’s customers are ready for APIs, the company can still take advantage of the structural advantages of APIs in other areas.
     • There was robust discussion about the build vs. buy question. In other words, should an LSP or software company develop its own APIs or use an API specialist to develop them instead. Some companies choose to build their own APIs, seeing it as key to keeping control of the customer connection. But others see turning to API developers (there are freight-specific developers such as project44 and SMC, and more multipurpose developers such as MuleSoft) as a more effective way to marshal in-house technology resources.
   Most of the panelists acknowledged that there is still some way to go before the freight and logistics industry wholeheartedly embraces APIs, primarily because they have invested significantly in creating EDI connections and building business processes around EDI.
   But as an attendee at the forum noted, EDI is sort of like the huge entertainment system your father bought in the ‘90s for a ton of money. It works for what it was designed to do, but it’s a little clunky, and probably needs to be replaced, if you can convince your father to part with it.