Tuesday, February 18, 2014

Operating Legacy Software and the Portrait of Dorian Gray

Believe or not, software is subject to the laws of entropy.  Software also ages. Software that is maintained carefully ages more gracefully and might even get to perform Mick Jagger-like antics, but in the end, all software must be refactored, converted, migrated or disposed of, according to your needs.

The idea that it is possible to reliably operate old software ad-infinitum simply by maintaining high-level operational standards is somewhat deceptive.  If software is there to support business processes (and it truly is), then software cannot be frozen in time any more than business can be frozen. Software must be maintained continually and adjusted so that it can keep up with the perennial business demands.

Even if your software was originally written under best industry practices, best industry practices tend to change. Each time your programmers apply changes to the software to accommodate a new business function or new features, there is risk that the software will depart from its original 100% tested purity. Even if your team is mindful of every change, and follows rigorous regression testing, the fact is that the environment in which your software operates is also changing. Vendors introduce new library versions, new compilers, new operating software releases, each of which is bound to affect the way your software works. Even the way modern systems are engineered (increased virtualization, data sharing, and network bandwidths) can impact the operation of formerly “stable” software.  For example, portions of software that have worked well previously may now fail when it is suddenly revealed that the legacy data handler had been expecting full ownership of the data, or the latency of an old subroutine may now exhibit concurrency problems due to faster data access.  And software with improperly designed components might even break when presented with a simple change of data schemas.

Granted, if you were able to keep your software up to date by applying the type of practices the aviation industry follows to keep airplanes forever new, you could then argue that your legacy software could continue to be operated with the highest reliability and availability levels required by your business.

Let’s be honest.  If you are like 99% of companies out there, chances are your legacy software more closely resembles a 300,000 mile reworked Chevy truck than a refurnished Boeing 727. And even if it doesn’t, your software will eventually follow the path of Dorian Gray’s portrait, staying young only until the day the mirror reveals its true age when compared to the latest and greatest standards available today.

What to do then?

There is a tendency to want to try to keep the legacy software running longer by reactively over-investing in additional infrastructure and by tightening the change control processes.  Nothing wrong with tight change control but, if the plan calls for continued changes to the existing software, then you will only be prolonging the inevitable end.  You can only react to problems for so long before the law of diminishing returns comes to bite you.  Doubling-down on your legacy software may work only until the next outage happens. And beware, during the next crisis you might no longer be retaining the people who had knowledge of the technology used in the original software (how many Pascal or Cobol programmers are still out there?).  The loss of ‘institutional knowledge’  of your legacy system is often irreparable.

Now, don’t get me wrong.  Your business lives and dies by the performance of your legacy software, and I am not suggesting you simply toss it away as though it were one of Elizabeth Taylor’s ex-husbands. No. What I am suggesting is that you need to put a proactive change strategy in place, and that you will need to execute on a well thought out transformation plan.

You will need to answer questions such as the following:
  • What is the predicted life expectancy of the current legacy software? This is an excellent time to revalidate the current and predicted business requirements. Build a roadmap.
  • What is the target software environment that will be able to carry the business requirements for the next five to ten years? You will need a solid and practical system architecture framework.
  • How will you maintain the current legacy software to keep it sufficiently functional while managing costs?  You will need a tactical operability plan.
  • While migrating to the new system, what will be your level of investment for maintaining the legacy software? You will need to decide on the appropriate tenets to introduce new functionality.
  • How and when will you execute the migration of customers/users from the current software to the new environment? What are the data migration challenges and tools needed? What are the customer re-training needs?  A comprehensive migration plan is in order.

Throughout my IT Transformation blog, I have written extensively about the many areas of consideration when dealing with legacy environments and on the techniques and practices needed to assure success. Below is a list of some of my previous blogs that are most relevant to this discussion: