There is more to a legacy system than meets the eye. When we think about legacy systems we typically think about the old technology it’s built with, and how painful it is to maintain that. On second blush we think about the cost of maintaining it, and perhaps worry about the cost of replacing it. And we ask: Is a replacement worthwhile?

But there’s something else hidden in most legacy systems, too: latent business knowledge. Most legacy systems have evolved over many years, with increasing layers of requirements building up like so many layers of historic civilisatons under a hillside. (Which is why software archeology is an area of active interest.) So all the logic of when to notify this department or that supplier, when to record (or not record) certain facts, how much discount to offer or mark-up to add, and so on… all that knowledge is embedded in the system. You can assume that knowledge is heavily obscured. You can assume most layers were added without a complete knowledge of previous layers. And just as most software has some bugs somewhere, it’s safe to assume that some of that business knowledge is not what anyone intended.

I recently worked with a typical such system. It had been developed over 26 years, and it was making commercial decisions that no-one really understood. And since that was everyday behaviour, people had stopped trying to ask why. This situation is very common.

So what does this tell us about what to do with our legacy system? Well, on the one hand it seems foolhardy to sweep away so much embedded knowledge without understanding what is being swept away. On the other hand, any business which runs on obscured and excessively complex rules is a business that hides waste and error, and is difficult to adapt… so it’s a great opportunity for a reformation to something simpler.

As with all such thinking, what superficially looks like a technical question really cuts to the heart of the business.

Photo by dynamosquito