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:
- Assessing Your Organization’s View of Technology: http://www.soa-transform.com/2009/05/assessing-your-organizations-view-of_23.html
- Creating the Technology Strategy: http://www.soa-transform.com/2009/06/creating-technology-strategy_12.html
- The Architecture Process: http://www.soa-transform.com/2009/06/architecture-process_26.html
- The Systems Management Stack: http://www.soa-transform.com/2010/03/systems-management-stack_26.html
- Migration Tenets & Principles: http://www.soa-transform.com/2010/08/migration-tenets-principles.html
- Migration Strategies: http://www.soa-transform.com/2010/08/migration-strategies.html
- IT Transformation Lifecycle. The Wrap Up: http://www.soa-transform.com/2010_09_01_archive.html
