Many enterprise integration solutions meet the mark at implementation time, and even adequately provide the tools needed to monitor and maintain the day to day activities. But, what happens when unexpected changes occur at the document level? Sometimes the metadata that defines a document’s structure and content changes. This can happen for a number of reasons including different trading partner specifications, application interface upgrades and back-end system replacements. More often than not, the changes are minimal and localized to the existing document. The syntax remains the same, but there may be additions or deletions to the existing structure, such as the addition of a content model to an XML document. There may be changes to individual elements, such as the data types, lengths, etc. In such cases, the map may need to be updated, but can usually be handled rather quickly with minimal effort.
Once in a while, the structure of the document will change. Again, the syntax stays the same, but an entire section may be relocated creating a different hierarchical structure, such as completely relocating an XML content model to a different section of the document. This type of change can be a bit more complicated to address. Most of the time, the maps associated to the altered structure are also broken and have to be corrected. There is generally more effort required to address this type of change than the former. And occasionally, the entire document syntax changes, such as a conversion from a flat file interface to an XML interface. In this case, a great deal of effort is required to address it because the associated maps have to be completely reworked and in some cases recreated. The impact of this change can be felt in many areas of the implementation and can impact business operations. Continue reading
Why does this take place?
While new projects often get the most visibility, you also know that maintaining what is already in place is as essential as the new projects. Delays in responding to customer changes or adapting to new versions of software can be a serious impact to your business. ERP cut-overs, changing customer/vendor document formats and industry-mandated document changes (e.g. HIPAA) cause changes to our stable integrations. These changes can cause business disruption or penalties if they cannot be dealt with effectively and efficiently.
How has it been dealt with in the past?
The brute-force way to deal with changing document requirements is to clone your maps and make the (hopefully) minor adjustments. This approach works, but does not scale. Consider a company with 10 trading partners. Occasionally, a partner will upgrade their EDI maps to a new version. This rate of change can be incorporated into the work schedule with relatively little impact. Now, consider the company with 1000 or 5000 trading partners and an industry-wide mandate (such as HIPAA) is coming to bear. Very quickly, the company could be faced with updating thousands of maps. This effort would be measured in multiples of person-months. Continue reading
From tactical to practical – leveraging design-time automation to master change
While lofty strategic goals drive most business integration plans when dealing with major events such as on-boarding a new business, a merger, or an ERP cut-over, dealing with the inevitable day-to-day changes – the normal lifecycle of existing integrations, that often takes a back seat. Managing existing integrations is the unsung hero of a successful business integration shop. The key areas where change occurs are the data formats, the communications technologies and the business processes that bind everything together.
Automation and leveraging history
Let’s take a look at how to best leverage design-time automation to address each of these with minimum disruption and maximum accuracy. Managing changes in data formats, whether new fields, restructured records, or substituting an entirely new syntax – think moving from a flat file interface to XML – requires a toolset that reduces the impact of the change on the existing integration. Such a toolset could use instance data to identify deviations from the original specification and assist the user in rapidly updating their integration project, concentrating only on the differences. Once the changes to the data format have been updated, the mappings that have been affected require updating. Intelligent mapping technologies that use heuristics to identify possible candidates between the source and target data dramatically reduce the time necessary to update the integration, increase the accuracy, and assist in conforming to accepted internal standards for data placement. Continue reading
As data exchange grows at an explosive rate, moving data between formats and systems occurs in many ways. Common data transformations involve data format conversions between EDI, XML, flat files, databases and more recently spreadsheets. In an application-to-application (A2A) environment, data typically is converted between interface files and back-end databases such as ERP systems. In the EXTOL Business Integrator, we call the objects that facilitate these movements Rulesets. Continue reading
In my last blog I discussed the final rule adopting X12 Version 5010 for HIPAA transactions. There are key differences that should be noted besides the many changes to segments and elements. Three of the important changes for version 005010 are Version/industry group ID (GS08), ST03 element, and the 999 Implementation Acknowledgment. The three sections to follow will address each of these areas. Continue reading