In the almost vanished days of silo-ed applications, data was moved between systems through laborious processes of extracts and reloads. Changes to individual applications were largely contained -- changes that broke the extract or reload process were fairly conspicuous and were frequently addressed as part of the overall change.

Enterprise integrated applications, using java adapters to read and write the older data formats, make it appear that the old vulnerabilities were a thing of the past. Application transactions can now span multiple silos quickly and easily -- facilitating new levels of business performance and capability.

But this is an illusion -- if anything, the new integrated enterprise is more brittle than ever before <see footnote>. The hand-crafted application adapters embed transformation rules to map the old data into new formats. But changes to the underlying database, say as the result of an application 'upgrade',  would not automatically propagate into the adapter code. Flawed data would most likely be read or written and cheerfully passed on. The external symptoms are likely to be varied -- depending upon what has been changed. The adapters need to be recoded to accommodate the changed formats.

Closely related to this is the increased difficulty in handling transaction failures. In the old stovepipe, transaction commitment rules allowed the developer to delimit the boundaries of a potentially fault-prone transaction. With distributed, long running transactions, this has become more difficult -- multiphase commits across time is far more challenging and has much larger requirements for persistent intermediate storage.

Until enterprise integration tools become sufficiently sophisticated to recognize when a legacy child client has changed and automatically reconfigure itself, the best strategy is a tightly managed impact assessment and change management program. Application managers would ensure that before changing any production application, an impact assessment would be performed that would identify and validate all dependency relationships in both directions. This requires complete documentation of the process and data flows in the environment.

Complete process and data flow documentation would also help during the design phase while the new enterprise-spanning transactions were being architected. A complete view of the data relationships and timings involved in a prospective business transaction would help ensure that an appropriate hierarchy of recovery steps were built in to accommodate the inevitable failures.

Enterprise integration has enabled firms to derive new value from their existing business and technical processes, but it needs to be clearly recognized that this new technology does not supplant the traditional requirements to know, understand and manage change for the benefit of the firm.

---------------------------------------------------------------------------------------------------------------------

footnote -  It needs to be recognized that it is a human trait with any new idea to emphasize the benefits and downplay the problems and costs of any new innovation. If the idea is sound, over time, we learn to live with the costs or discover new ways to correct the problems. Information Technology, which frequently renames ideas to sustain a sense of continued, volatile change, has been rife with this effect. One of my favorite side effects has been the loss of synchronous error reporting with the introduction of pipelining in RISC processor architectures -- an error might well be reported, but not necessarily aligned with the instruction that caused it. After bubbling up through a dozen layers of dynamic run-time libraries and interpreters the original problem may be totally unrecognizable --  a stream of meaningless error messages or java vomit. A further and more insidious side effect is that as computers become ubiquitous in modern life, brokenness  is increasingly accepted -- and may be more subtle and difficult to correct.