Last week, we were interviewed by Alex Woodie of IT Jungle, for his Four Hundred Stuff column. The primary focus of Alex’s column was on the trajectory of cloud computing adoption and the challenges that companies face as they add cloud integration to existing EDI, application, and data integration practices. I encourage you to click through and read Alex’s article, but in this post, I want to focus on the evolutionary path that is taking us from traditional EDI to cloud-based EDI.
For most companies, robust EDI software remains the single most important B2B integration requirement. And new characteristics that reflect the way “EDI” is practiced today make it more relevant and important than ever. Fifteen years ago, EDI was almost exclusively batch-oriented, enabled by VANs, and focused on translation between flat files and X12 or EDIFACT standard EDI documents. Since then, EDI has changed in several important ways:
Today, EDI is conducted mainly over the internet, and employs a combination of mediated and point-to-point communications based on standard transports like secure AS2 or FTP. So contemporary EDI solutions need to support a variety of B2B transports, especially AS2 and FTP, in addition to VAN connectivity.
Contemporary “EDI” includes support for non-EDI documents and collaborations, including not just XML cases, but also proprietary flat files and spreadsheets. Supporting both EDI and non-EDI documents is especially important for providers of transportation, logistics, and other supply chain mediation services, companies that deal with offshore partners, and more generally, any company that needs to comply with proprietary documents mandated by customers or strategic suppliers.
More and more B2B partnerships require near-real-time response, typically based on single-transaction interchanges or web services. This is critically important in Logistics, for example, when responding to load tenders, and in Healthcare, when responding to eligibility inquiries, but we see requirements for near-real-time response in nearly every industry. Satisfying this requirement means that modern “EDI” systems must be capable of integrating directly with applications, databases, and other sources of response data, mostly behind the firewall, but also in the cloud.
In addition, for companies that choose to implement and maintain EDI on their own, having easy-to-use software tools that enable rapid implementation and maintenance is critically important. That’s because lifecycle costs for EDI (and business integration in general) are dominated by people costs – whether staffed internally or outsourced – so the less time you spend implementing and maintaining your EDI / B2B systems, the lower TCO becomes. This is especially important in midsized and other close-to-cost businesses.
Not all of the changes noted above surface in every company that uses EDI. But as a whole, EDI has evolved from batch processing of standard syntax documents, implemented with basic mapping tools to a range of cases that requires the ability to integrate partners, applications, services, data, and cloud resources, in combination, using a variety of document types, communication mechanisms, and collaboration models. And there is no sign that this evolutionary path has an end, or that businesses are reluctant to follow its course.
Because trading community standards are tenacious, the core of EDI as it was practiced 15 years ago is still with us. But today’s EDI includes features that have transformed it into something new. Because of that, it’s important that integration vendors offer highly flexible EDI product and service options, to address the spectrum of needs and preferences that exist among EDI buyers today.