As a long time service provider in the EDI and EAI (business and data integration) arena, we have experienced the integration toolset and terminology evolution. Those that have been in the business and data integration world for the last 10 to 15 years know today’s world is similar to that of the past, yet in many other ways today is very different.
Organizations (hubs) implementing EDI in the 1980s and 1990s did it for differential advantage and to gain efficiencies. Others (spokes) implemented it because it was a condition of doing business with large organizations. The tools used by both were single purpose software packages capable of taking business system data and standard format transactional data (X12 or EDIFACT) and mapping from one layout to the other. No conditional processing, table lookups, extended rule features, etc. existed at that time, and only appeared as EDI mapping utilities matured over the years. Even communication software to send/receive data files were separate from the translator. Any complex massaging of data had to be done in pre or post translation routines which were developed outside the translator.
About the same time, ERP packages became popular offering a buy versus build opportunity. The advantages were the theoretic ease of implementation, common business processes, and maintenance of these systems over home grown ones. Early ERP packages were not the mature ones of today. They did not cover all functional areas of an organization or in many instances some modules were clearly more robust than others. This led many to utilize middleware tools that served to connect ERP systems to legacy ones and one ERP module to another where a best of breed strategy was employed. Middleware (later Enterprise Application Integration (EAI) software) had early extract, transfer, and load (ETL) and messaging capabilities which allowed data and transactions to be shuttled between one software module and another. The result was internally integrated systems.
These tools, and the associates that used them, were often found in different parts of the IT organization with EDI originating in the communications / data exchange area and EAI originating in the ERP area. They had separate “ownership” and supported different areas of the business. At the time no one realized that that purpose of the tools, and the processes associates used to perform integration with them, were actually quite similar. At the end of the day EDI and EAI integration was about systems analysis, gap analysis, data mapping, testing, and implementation. The associate skills to perform these integrations were overlapping.
Leading vendors, as well as IT organizations, have realized this dynamic and each have been merging tool set functionality and integration team members for some years now. Some EDI vendors have added business process modeling, complex extended rules processing, file transfer options, communications, one to many / many to one mapping, exception processing, and more to their products. Leading EAI vendors have added standards libraries, standards compliance checking, communications, file transfer options, and more to their products.
The result of this convergence of functionality in EDI and EAI tools has been the development of a new class of products. This class of products is complex, yet extremely powerful in its integration capabilities. They allow for application-2-application integration between any systems, and allow for proprietary and standard integration between business partners from a business-2-business perspective.
As we have observed this evolution, Remedi has also participated in it. Over the years we have participated in EAI projects using EDI tools. And we have also participated on EDI projects with EAI tools. We have seen the functionality gaps in both directions and are pleased to work with an Integration Suite class of product where clients have them as part of their integration infrastructure, or are making plans for such an implementation.
While this class of product is clearly not for everyone, it is right if you seek to combine your EDI and EAI environments into a business integration team and provide them a great platform for integration.