Blog: Responding to Integration Changes

Please note: This post originally appeared on Extol.com (EXTOL has been acquired by Cleo).

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 onboarding 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.

Reusable components

Responding quickly to changes in how the data is to be moved is another challenge. Reusable adapter configurations and a graphical business process modeler round out the ability to deal with lifecycle changes. Another common example: a new requirement specifying how the data is “moved” either internally or to external parties such as a value-added-network (VAN) or directly to a trading partner. For instance: a company is using a VAN to send EDI to their trading partners. Typically, this transfer is accomplished via FTP but now the company would like to use AS2 and send the data directly to the trading partner. Using an integration suite that incorporates configurable, reusable objects and a graphical business process modeler, it becomes a minimal effort to “redirect” the integration project to send the data via AS2.

Modular processes

A third example of a common change that occurs within integration projects is the augmentation expansion of the business process to accommodate expanded broader business requirements. These requirements could have been generated from within the organization by a business unit or from external trading partners. Consider an EDI integration in the manufacturing company that sends shipment notices out to customers. This is a fairly common integration that has been working great since you built it, but new requirements have just been received that require a copy of the shipment notices to be sent to a third-party logistics company.  With a graphical business process modeler it is easy to see the entire process flow, making this type of a change simple to implement. Once the data is produced, a copy can be sent to an additional process step that will submit the data to the logistics company. This simple extension of the original process can be made rapidly, provided only if your integration toolset allows for such easy changes.

Dramatic change vs. ‘tweaks’

So far we’ve discussed a few scenarios including changes in data formats, communication methods and even how process changes can affect existing integrations. These are fairly straightforward examples and just require “tweaking” of the existing integrations to accommodate new requirements. But, what happens when the requirements are dramatic such as a change in the version of a business document? Even more compelling, what if the type of document is completely changed such as an EDI document that now must be produced in XML? Such a radical change frequently means that the entire transformation must be re-built and grafted into the existing integration; if the tool even allows that to happen. If not, a new integration must be composed.

How much easier would this be if you could “migrate” an existing integration to support that new format? Imagine how the ability to create a set of reference rules between schemas (similar to a transformation map, but used only to connect the data items) could be helpful. This approach would also allow the transformation map to be “migrated” to support the new data format automatically, which would save a significant amount of effort and also introduce an increased level of confidence in the ability to handle such changes effectively.

Impact of an agile lifecycle management strategy

Change is inevitable and in the world of IT projects that depend on agile integrations, it is something we have to plan for. Project managers schooled in the formal management practices would classify change under risk management. How we react and accommodate change is of significant importance to the organization. It has a financial impact both in terms of actual dollars spent to implement the change and risk dollars if the change is not implemented successfully. Beyond the immediate effect is the impact it has on the ability to onboard new business and adapt to customers’ needs. If an organization can make it easier for their customers to do business with them, using a reliable and flexible integration suite, it has a competitive advantage that can be leveraged. The same can be said for integration with vendors. If a customer is “easier” to do business with, that can lead to better terms because each transaction is at a lower cost to the vendor than with other customers.

Integration is both a tactical and strategic weapon in a company’s arsenal. There is an old adage that knowledge is power. Possessing the knowledge is one thing; knowing how to employ it to your benefit is entirely different, and a true advantage.