22 November 2006 - 19:02Issues with legacy systems

It is possible that a legacy system on its way to being decommisioned will try to push legacy behavior to a new system. One example could be a new tax services that has to get input from an old system handling commodity trades. The new tax system has its interface for communicating with the outside world, but the old commodity service is sending tax information using its proprietary format. More than that, the commodity system requires some behavior to be implemented on the system it communicates with: the old “if the 4-th char in the message is a ‘C’ then do this, else do that”. It is pretty clear that this is pretty bad, after all you are trying to scrap the “if the 4-th char …” and replace it with a new set of rules that will be relevant for as long as possible. *

There are a few ways to deal with this type of requests. The first thing to do is to refuse outright trying to deal with this legacy behavior, after all in 5, 10 years the new system will have plenty of legacy behavior on its own. Pushing forward legacy behavior is not a good strategy either, you are basically putting more work at each new wave of system renewal.

Sometimes this is not possible, for example, it is possible that no development is done on the old system within a reasonable time-frame.
One way to interact with this system is to isolate the legacy behavior that will get discarded away from the core of the applications and make it available to this system in some form or another. Abstraction would help very well in this regard, if the business process your application is implementing is well abstracted then you could create a customized implementation that contains the legacy behavior, implementation which could be discarded when the legacy system gets decommissioned for real. If you are working in a flow-based environment you could create a partition of your engine dedicated to legacy workflows and code your legacy behavior in a workflow deployed in this partition. Customized communication channels which talk to the legacy system pushing legacy behavior onto you should help as well for isolating behavior that is prone to become obsolete.

*On a side note: decommissioning a system should actually be the side effect of decommissioning a set of business rules (and not vice-versa).