Electronic data interchange (EDI) has been around since the late 1960’s and has been adopted by thousands of organizations since that time. Many of these organizations purchased or developed their back-end software systems and communication methods with the intention of supporting EDI. Not only were the back-end systems and communication methods “EDI-centric”, but organizations also needed to purchase or develop programs to translate the EDI data to and from their applications and data. Because EDI has been around for decades and because many of these older systems were constructed for EDI, the word “legacy” tends to come up a lot when referring to EDI. In reality, EDI is a mature technology that is utilized by older systems, but it isn’t outdated. It is the hardware and software systems built around the EDI data that are becoming legacy, not EDI. In fact, thousands of organizations are currently implementing EDI for the first time. Some of these organizations may have to implement EDI because of new relationships with other organizations that mandate EDI (new trading partner relationships) or they may decide to use and implement the EDI as a canonical model for their application-to-application (A2A) initiatives as discussed in Mark Denchy’s blog, Canonical models, not just your ordinary middleman . No matter the case, EDI is a proven interchange model and not going away anytime soon.
Now that we identified the fact that EDI is still a viable option, what can we do to “modernize” it? We can do this a number of ways, from changing the back-end software and/or hardware systems to implementing tools to improve the way the data is processed. But first, let’s start by enhancing the definition of EDI. EDI can be defined as the electronic transfer of standardized structured data from one organization to another to enable business-to-business (B2B) collaboration. This definition provides more meaning than the traditional “legacy” definition, being the computer to computer exchange of structured information, that some of us are more familiar with.
Let’s look at changing our back-end systems. This can be an update/upgrade of a legacy system, or a complete replacement. This option can start with either the hardware or the software with the rest being defined as each piece is identified. A very high level example of this is if the decision was made to purchase a new enterprise resource planning (ERP) system, the size of the company and package(s) purchased may influence the hardware and operating system (OS) specifications. On the other hand, if the decision was made to use a specific hardware / OS combination, then the software package(s) would have to conform. Once the software and hardware system(s) specifications are determined, the data migration plan can then be created. Included with the data migration plan, the EDI translation programs would have to be updated to accommodate the new environment. Eventually, a master plan would be executed. Sounds easy enough, but in reality it can be an extremely time consuming and costly option. In the long run, it can pay off by providing an up-to-date more efficient processing environment in a centralized platform.
If this is too radical a change, another less invasive method would be to implement a middleware integration solution. This option allows the legacy systems to remain intact by providing the tools needed to move the data between the EDI documents and the back-end system, implement event driven B2B processes based on: system events, schedules, data flow, etc., enable real-time visibility to the EDI metrics and even allow for rule driven data validation. What this really means is that many of the manual business processes will be automated; transaction reporting can happen immediately instead of in a report at the end of the month; errors can be identified and corrected in a timely fashion. One of the benefits of this route is that if the back-end system has to change, this integration platform can remain intact. With the right tools to automate migration from older interfaces to newer ones, it can be updated to accommodate the new environment which means there will be minimal impact to the EDI processing.
In addition to implementing a middleware solution, another option is to look into changing the communication methods traditionally used to receive/send EDI data. Traditional EDI processing was typically batch-oriented, meaning that multiple transactions from multiple organizations were retrieved from a VAN and processed as one large transaction. Nowadays, there are other point-to-point communications alternatives such as Web Services, AS2 and even FTP that can process EDI data in real-time or near real-time. And many trading partners mandate the use of specific communication methods in order to help streamline their processes so it’s important to support a variety of communication options. Finally, another option is EDI transformation services, which can be cloud-based or Software as a Service (SaaS) models.
Any way you look at it, EDI stays the same, what continually changes is the way systems interact with it.