Most of us have had exposure to the remains of some system replacement that didn’t quite finish decommissioning the legacy system.  Perhaps it still performs some current functions, or is simply used to access historic or run off data.

We often feel this is problematic and the result of a lack of commitment, but is it really inevitable, and perhaps even logical?

the analogy

A good friend of mine told me a story, or perhaps a legend, told to him at the shipping company he was working for.  It just completely captures the essence of the decommissioning problem.

Like all good technology analogies it starts with a consignment of frozen Mackerel.

As the story goes there was a shipping container full of frozen Mackerel (Fish) that was being shipped from Ghana, West Africa, to a customer in Europe, passing through some very hot areas including Dubai on the way.  At the Port of Jebel Ali, Dubai, someone notice a rather unpleasant smell, and upon inspection found that the refrigerator had been turned off.  This was potentially a major headache deal with, so they simply turned it back on and sent it on its way to Europe.

Arriving at the Port of Amsterdam where it was scheduled to transfer to a truck, it first needed inspection.  Customs crack the container to check it prior to it being cleared for entry into the Netherlands.  The container was one massive block of frozen rotten fish.  A blend of water from what was the packing ice, Mackerel, and mangled cardboard.  The door was quickly closed again so it could be returned to sender, as the regulations for disposing of such cargo meant it would be an expensive, and very messy, task for the port.

During the elapsed time of this journey the fishery company in Ghana that had sent the container of Mackerel  had gone bankrupt, and so the port could neither send the rotten frozen fish back to West Africa, nor let it into the country to send it forward to its intended recipient.  This was a massive headache for the manager responsible for dealing with it; whose targets didn’t accommodate the time and cost of this cleanup.  Then one of the team pointed out that they could put it out back in an unused corner of the port and just leave it plugged in.  No cost, and no real downside.  Job done.  A couple of years later the manager had moved on, and then one hot summers day a couple of year after that a worker noticed a rather foul smell coming out of the container.  The refrigerator motor had seized.  Nobody knew what the container was even there for at first, but one of the cynical old boys did remember it.

Opening the container only to be hit with a wall of foul smell, the new manager quickly closed the door and it took them less than a minute to determine it was much quicker and cheaper to just fix the refrigerator motor.  The same exact thing happened 5 years later to a different manager, with the same outcome, just fix the motor and leave it alone, but with one difference.  He was a more diligent manager and wanted to do the right thing, so he organised for regular maintenance of the refrigeration unit.

“Never put off until tomorrow what you can avoid altogether” – Mark Twain

According to the legend the container is still humming away some 25 years later.  True or not does anybody doubt that this is a perfect analogy for the non-decommissioned legacy system?

picking the eyes out

This strange expression is quite common in New Zealand and Australia, but apparently not so common elsewhere.  It basically means picking out the good bit and leaving a carcass of little use.

The analogy about the rotten Mackerel in the container needs no further explanation in regards to how it applies to the psychology of what people do in such situations.  It is all quite logical with rotten fish and hanger-on legacy systems.  If we can kick the can down the road then why wouldn’t we.  But how do these systems get like that.

Well typically it is all about bring the value forward during system replacement programs.  It makes good sense.  Aim for the high value first, and pick the eyes out.  What you are left with is a few functions that typically don’t have a very strong ROV (Return of Value) for a replacement business case.  With a lot of old mainframe systems it is common to move them to a low cost Windows platform, which make sense.  But this further reduces the business case for completely decommissioning it.  Few of us are able to get a case for a 20 year ROV horizon approved.

As architects, we get frustrated with these old systems hanging around, particularly from a systems thinking viewpoint when we can see the accumulative impact on the overall enterprise.  But assuming people act logically given their current conditions then it largely makes sense, and is almost inevitable when you add it all up.  So what is the answer?  What are we to do?

The best way to deal with this situation would be to ensure the original program has a governance gate for success that includes the full decommission of the legacy system.  But to be honest in the heat of battle when sponsors are under pressure this is likely to get traded away with perhaps a risk assessment and the good old sponsor risk acceptance trick.

Alternatively if you have lots of these old containers full of rotten Mackerel out back you can push to get a strategy endorsed at a high enough level that individual business cases to decommission are not needed.  So typically making it a strategic business priority if you can.

I don’t know the answer, but perhaps the logical thing to do is to find a cool dark corner out back, plug in the refrigerator, and let it be.  Just don’t forget a bit of maintenance if you do want to stink the place up.  Sorry, but in the end, given the condition we operate in, it often makes sense.