A new communications pipeline?

A new communications pipeline?

A new communications pipeline?

A new communications pipeline?

A new communications pipeline?
A new communications pipeline?
  • slideshow
  • slideshow
  • slideshow
Tracking
Search field
Number
Online support
(+84) 38729686

A new communications pipeline?

A new communications pipeline?

EDI has dominated the freight sector’s communications for decades, but the industry’s systems may soon have a whole new way of talking.

   It goes some way toward explaining how behind the times the transportation industry can be when you consider that electronic data interchange is considered by many to be advanced technology.
   EDI is the de facto means of communications between systems in most modes. For some, it’s a goal to even get to the point where actions like shipping instructions or a load tender are transmitted via EDI.
   But is there a better way?
   To answer that question, one would do well to look to the IT industry at large, where something called application programming interfaces, or API, are the standard way that systems “talk” to one another.
   “It’s not an alternative to EDI, it’s the standard outside of the transportation sector,” said Wally Ibrahim, chief technology officer of the Chicago-based API platform Project 44.
   Ibrahim came to transportation from a technology background, including a stint with Oracle.
   “I just assumed everyone was using web services (APIs) in transportation,” he said. “They said, ‘nope.’ And I said, ‘why not?’”
   To which Jason Roberts, a co-founder of the transportation management system Freightview, has an answer.
   “For the early adopters of EDI, there was lots of legacy code,” Roberts said. “EDI is not very nimble or flexible, but when it’s in place, it runs. That said, it doesn’t make any sense to make any new developments on EDI.”
   Both Ibrahim’s and Roberts’ companies are at the forefront of a movement to transition the transportation industry from EDI to web services API. For them, the equation is simple: EDI is a limited and rigid means by which to exchange data in a world where data is becoming as important as the actual cargo it accompanies.
   “EDI wasn’t designed for the Internet as it looks like now,” Ibrahim said. “It was designed three or four decades ago. At the time, real-time communications wasn’t possible. APIs don’t define what you can talk about. You can exchange data about scheduling, address information, rates, or postal code validation, unlike EDI, where the codes tell you exactly what you can do.”
   Ibrahim made a simple metaphorical comparison.
   “EDI is one way,” he said. “It’s like a fax. I don’t know if you’ve read it, whether you’re going to read it, or whether you’re going to get back to me. API is like a conversation—there’s a real-time back and forth. The nice thing about web services API is they open up whole new ways of doing business. I believe API is to [business-to-business] what the web browser is to [business-to-consumer]. It’s been happening in the e-commerce world for a long time. Taking orders, order management, tracking. There’s a precedent for it.”
   So again, why isn’t everyone using APIs?
   The main stumbling block is that it takes two to tango. If one company, say a shipper, wants to set up an API between its transportation management system (TMS) and its carriers, it generally needs to go to each of those carriers and establish that interface one-by-one. It can be onerous for both sides. Imagine a shipper that uses 15 different trucking companies and five ocean carriers. Now imagine a carrier being asked by its hundreds of customers to set up an API with each one.  
   Project 44’s model is actually quite simple to understand (if not fairly comp