High-value, high-risk systems present the CIO with special problems assessing business value and risk together gives advanced warning of looming problems in time to avoid them.
As one of the contributors to recent Gartner EXP research on legacy systems said: “A legacy system is a hindrance that fills a business need, so you can’t just get rid of it.”
The sad truth is that most of today’s applications will end up as tomorrow’s legacy systems. The good news is that not all legacy systems are equal in terms of the difficult choices they represent to the business. Systems with low risk and low value can easily be tolerated, or eliminated when they can’t. High-risk, low-value systems too can easily be eliminated. Low-risk, high-value systems are what every CIO and business executive wants in the application portfolio. It’s the high-risk, high-value ones that are the problem.
To start the process of addressing your legacy systems, you have to know as much about them as possible. The most valuable tool to aid in this process is the IT asset management (ITAM) repository, which tracks and cross-references procurement, contract, inventory, maintenance, entitlement management and retirement information for the software and hardware that a company owns.
Once you have them listed, now deduce today’s business risks: the likelihood and potential business impact of a specific application failure, from the inability to support business requirements to a catastrophic shutdown of the business process.
The other half of the story involves determining business value. The best way to do this is to take a process-by-process approach that looks at the business value delivered by each of a business’s key processes and then apportions this value to the application, or applications, that support it. Overlaying the value and risk of a given application ultimately helps show when and why the business must migrate from its legacy systems, and how much time remains to do so or reduce the risk to acceptable levels. But the business case can’t be completed until the CIO knows how to migrate a particular system.
CIOs have multiple options for migration. From live with it, to using newer tools and technologies to add missing functionality while leaving the core in place, to a complete replacement, or some combination of all three.
The key goal is to avoid digging a new legacy-systems hole in an attempt to fix the old one. In other words, migration should enhance business value while reducing risk. To this end, aligning plans and designs with architecture standards helps to future-proof the new environment. Which brings us to the final step for the CIO: put in place mechanisms to reduce the chances that high-risk systems will return to the portfolio.
Stop risk creeping back in by following a couple of simple steps.
Conduct annual reviews of your application portfolio – and do them following business strategy discussions and architecture planning, and before budgeting and project planning. This allows the CIO to track changes in value and risk over time, build consensus for change gradually, and spot trends in value and risk early enough to avoid sudden surprises and disruptions to the business.
Look at total cost of ownership over the lifetime of a system, not just the up-front cost. The best time to discuss TCO is when the business case for a system is proposed. That’s also when executives should consider a timeline for acquisition, operation and eventual retirement of the system.
Focus on high-value, high-risk systems, assessing the application portfolio regularly and migrating selectively to reduce risk and enhance value.
By looking forward via architecture and ongoing reinvestment, CIOs can significantly reduce the burden of legacy systems.
The payoff from this active management of legacy systems is twofold: a business that is less constrained by accidents and history, and a more satisfying role for the CIO and the IS team.