At ThoughtWorks Quarterly Review, Amir Uttman and Derek Longmuir discuss strategies for effectively managing legacy systems.
Legacy system have the following characteristics: Expensive to maintain, unchangeable, old-fashioned, unreliable, complicated, old, COBOL, mainframe, single point of failure, untested, undocumented, obsolete (no vendor support). However, legacy systems work, are business critical, are the system of record, and are familiar to the employees. Most importantly, legacy systems currently provide business value.
Next Amit and Derek define a legacy system as a system in which the quality has degraded to such an extent that it needs to be replaced. A legacy platform is a software or hardware system that is no longer supported. Thus, with time, the risk of using a legacy system gradually increases.
Amit and Derek then cover some options for replacing legacy systems. These include the build vs. buy option, the hiding the complexity option (usually does not work – nice front with spaghetti code behind), or the big bang replacement option(usually fail due to trying to create a prefect replacement). They give real word examples like Hershey’s ERP system, FBI Virtual Case Files, and Windows Vista.
It is important to remember that the real cost of systems is 10% to build and 90% for maintenance.
Amit and Derek next discuss effective legacy system replacement strategies and techniques:
1. Technology asset portfolio: Figure out where you are right now, what is the current state of the technology system(platform and software), what skills you have to maintain that system (operational, technical, and business skills). Based on that, you can figure out what kind of risks you face. How long is the system going to be around? How old is it? Who are the vendors that can support it?
2. Governance: Continually review your assets
3. Systems Health Check: Use several tools to visualize code complexity and ensure you have the basics of Source Control Management and Automation.
Some problems of migrating legacy systems:
1. Tendency exists to take existing logic and recode it as is on the new platform. No thought is put into new features. Sometimes, same bugs are ported over.
2. Code that no one knows what it does.
3. No benefit in investment until way later in the project.
Some migration techniques are:
1. Use the strangler approach: Start out writing a new application tied to the old system. You put out a new interface and don’t change the legacy application. Eventually you migrate other external systems onto new system. Spending money only on current requirements instead of converting the whole thing. ROI looks different because 1st pieve is delivered immediately and can receive useful feedback.
2. Use the phased approach: update/replacing incrementally and eventually the whole system is updated.
Amit and Derek note that developers tend to get better when they are placed in a support role after delivering an application into production. They tend to see things from a different perspective.
They then summarize by recommending we create a technology asset portfolio, build a platform road map and health check our systems. We should augment source management and automation on all your projects, use the strangler or phased replacement approaches to minimize risk and increase the speed of ROI. Evolve as well as support your systems as continually evolving a system prevents it from becoming legacy.
This presentation is available on InfoQ at http://www.infoq.com/presentations/strategies-for-effectively-managing-legacy-systems