Legacy Integration Supplement: What Does “Legacy” Mean?

by Michael Thompson
August 1, 2004

Prior to expanding and expounding on legacy integration issues, it is important to understand precisely what is meant by that most misused of words, “legacy.” All too often it is used to denote something past its prime or of no use. This might be the case in certain instances but is by no means the case in all situations. However, there is one aspect of legacy that does bear closer inspection; one that cuts to the heart of integration (and other aspects of legacy use). It boils down to one key word: understanding. Without understanding, there can be no definition of legacy that is useful and legacy that is not.

Attempting to work with legacy systems, code, or data without first gaining a complete understanding of what an organization is currently maintaining is analogous to letting a surgeon perform an operation on you before anyone has diagnosed what is wrong. Just as any sane person would not allow a masked man with a scalpel to cut you open and start tinkering with little or no idea what he was trying to achieve, so no IT professional should allow anyone near their legacy infrastructure without a clear idea of what all the various bits and pieces do.

This may seem like obvious advice, but time after time I’m bombarded with solution providers who tell me they can “integrate” legacy systems (some of whom are calling zSeries legacy— a fact I’m sure IBM would like to dispute), do automatic translation of code (like bad COBOL will suddenly be improved by becoming Java, and not just turn into bad Java), and perform data transformation to the newest relational databases without first understanding data relationships. Let some of these people loose on your systems and a bad situation will become 10 times worse.

I have to admit to a distinct (though not unique) point of view here, which does not necessarily fit neatly into an integration scenario. I’m not against integration per se, but I do believe once an understanding is gained about the assets an organization owns, then there are multiple routes one can take. There is another aspect of understanding to consider. Integration has to serve a purpose. There is a requirement to understand the proposed end result from a business perspective.

Again this may seem obvious, but the numbers of SIs making a living on the back of generalizations such as “silos of information,” “the disconnected enterprise,” or “end-to-end computing,” are too numerous to mention and too rich to annoy.

With that digression over, let’s get back to my point of view. There are two questions to ask. First, how long will integration last? More accurately, how long will integration last before I need to do some more? Second, do I want to integrate or do I want to create interoperability between systems? On this second point, there is a distinct difference, especially when one considers the different elements that integration covers.