Legacy Systems Don't Have to be Bad

I was reading an article, NASA’s older Mars rover notches another milestone, in USA Today and was reflecting on how we don’t do enough to praise and learn from the engineering required for systems to last well beyond their useful life.

Opportunity, the Mars rover, was scheduled to work for three months and is going on its tenth year.  In the article it points out “It has an arthritic joint in its robotic arm and it drives mostly backward due to a balky front wheel,” but also says these are “more annoyances than show-stoppers.”

We all have stories of systems operational for ten or more years.  Mine was around an HP3000 mini-computer running a trading system for an investment management firm.  It took us around ten years to retire the system because it never caused us a problem, and never became a priority.  The tipping point was the half-million dollars in maintenance we were going to be required to pay for the hardware and software.

• What makes a system last a long time?  Do we ever ask ourselves how it was architected?
• When does a system become “mature?”  What design changes enabled a reduction in support?
• Why do mature systems have fewer outages?  What is the impact of changes on stability?
• Do mature systems have the functionality needed by users or are users just compromising?  Are users capable of compromise?

What I have come to realize is we equate “old” with “bad.”  I am currently doing a consulting engagement as an interim CIO for a mid-size company.  The executive team keeps asking about the strategy around a critical system deployed in 2001.  They think they must deal with the system because it is over 10 years old.  After a few months, I have assessed there are many more systems which are vulnerable, end-of-life, and high risk.

As I examine this 10-year old system I have discovered the following practices keeping it stable and productive:

• A development, test, and production environment all of which have been properly capacitized
• Strict release practices and schedule
• Strong QA practice
• Skilled and disciplined team of developers with strong management
• A well thought-out and designed database, application, and middleware architecture

As I reflect upon my experiences with legacy systems I have come to understand well designed, architected, and supported systems can last a long time.  The more useful life a system achieves the better the return on investment and the better it is for IT.