Sunday, May 20th, 2007

SOA - Wrap and Replace “the Squeaky Wheel”

Many SOA advocates refer to the implementation of SOA as “wrap and replace” rather than “Rip and Replace.” createTank has determined through experience that a more refined description might sometimes be helpful — that of “wrap and replace ‘the squeaky wheel.’” This description is usually more acceptable to developers and management alike, as it highlights the possibility that a great deal of legacy code may not need to be rewritten at all (or at least not immediately).

As with any SOA implementation or legacy integration, the team wraps the legacy implementation(s) with the chosen SOA technology or framework, adding necessary new functionality alongside. At some point in time after the wrapping takes place, legacy implementations of services/operations deemed to perform insufficiently may be completely replaced by new implementations just as with the regularly described “wrap and replace” method. However, the “wrap and replace” description leaves out the very real possibility of the retention of legacy services/operations which continue to perform and deliver value. These implementations may remain in place working transparently alongside new implementations.

In the illustration, we see two legacy systems (Legacy_A and Legacy_B) and new functionality integrated into a SOA Framework. Within the systems, multiple services or operations are marked in red as candidates for replacement. These are the “squeaky wheels.” Notice that a good portion of the legacy implementations could remain in service indefinitely. This shows the agility that SOA provides, in that the team is not forced to replace the legacy code until they have a “real” reason to do so.

The fact that the legacy implementation can remain around indefinitely brings us to one final point of any good SOA integration, that the system need not be completely replaced or rewritten every major industry cycle. For example, if Legacy_A was written in COBOL in the 70’s, Legacy_B was written in JMS in the late 90’s, and the latest system is written with SOAP over HTTP interfaces, a future implementation in the fictional “Protocol-X” could still retain some or all of the existing implementations without rewrite. This is an important point, because new languages and technologies will continually overcome what we are now implementing.