Does your organization depend on a decades-old IT infrastructure? Here are some strategies for breaking out of outdated systems that are too risky to leave in place.
Organizations whose responsibilities haven't fundamentally changed over time -- think federal agencies -- depend on systems built years ago, even as far back as the Carter administration. Considered state of the art when they were acquired, these legacy systems have become the IT equivalent of rotary phones: functional, but lacking new features and increasingly difficult to maintain.
Yet these systems run critical processes. In fact, the age of such legacy systems almost guarantees their importance because as a rule, core processes were automated first. We call this the "prisoner of love" dilemma. Organizations are prisoners of their older systems, but they're also reliant on -- or in love with -- their functionality, low cost, and heritage capability.
There are plenty of issues with managing systems of this age. Organizations might have difficulty scaling, or they might struggle to support the complexity of current needs. The old systems might need to be "wrapped" in data management tools to provide modern-day users access to information. Or they might need augmentation for Internet or mobile use. Over time these problems become more significant as such capabilities become expected. The limitations hinder organizations from fulfilling their mission, meeting required workloads, or automating self-servicing.
To further complicate matters, organizations cannot easily replace legacy systems that form the bedrock of operations. The systems are complex and nearly impossible to document due to years of customization tweaks and updates. The actual functionality is embedded in the technology and requires an archaeological review to fully understand.
What took thousands of man-years to build is difficult to replace in a few calendar years. What can you do to break out of this technological "prisoner of love" situation? How can you orchestrate the prison break?
It requires planning. Replacing a system like this requires a fundamental examination of your organization's mission, goals, and IT needs. You'll also need to develop a long-term IT strategy and sufficient resources. In the end, if your system is too big to replace, you'll need to modularize your approach and replace portions over time.
Here are the three options you'll need to consider for your long-term IT strategy:
1. Replace the system. Switching out a system is risky and requires a large-scale commitment of resources. Replacement requires gearing up program and project management, technical resources, communications and change management, sponsorship, and committed funding. But certain situations compel facing the risks. One organization had systems built on hardware from a manufacturer that went out of business long ago. It maintained the systems by purchasing old computers for spare parts, supported by a dwindling staff familiar with the environment. There is little choice in a situation like this: when the system can barely be maintained it's time to cut the cord.
Because replacing mission-critical capabilities can cause significant disruption, however, organizations should choose this option only when the following exist:
The legacy technology does not meet functional needs;
The cost structure for the system is out of alignment; and
Staffing or hardware to maintain are becoming unavailable.
All three conditions should be in place to merit the effort required to fully replace capabilities.
2. Switch to an external provider or package. You might use a vendor to decrease your IT department's involvement in developing software, to create the foundation of an overhaul, or when you need significant functionality right away. This does not mean the changes are smaller or less complex, though. Functional gaps need to be addressed and in all likelihood a slew of new needs will emerge. Moving to a provider will require finding a vendor who is capable, who understands the capabilities and limitations of their offering, and who can integrate them with remaining applications.
This assumes there is an appropriate vendor. Given the specific nature of government operations, there might be few choices to meet highly specialized needs at very large scale. Similarly, many hesitate to use vendors for mission-critical systems. Assessing the full ability and long-term viability of the provider is also critical.
A variant on finding a "software provider" is actual outsourcing. This is an increasingly common tactic but requires similar cautions about highly specialized functions and intense review of potential vendors. In our experience, organizations doing the outsourcing can lose their IT and processing "muscles" and become increasingly dependent on vendors over time. Be prepared -- it is often a one-way street.
3. Continue enhancement. The remaining choice is to continue systems enhancement but upgrade so that, over time, there are continual improvements in the system's architecture and infrastructure. This needs to be done strategically, major module by major module, so that you gradually phase in the technical improvements. Some external development centers focus on re-engineering legacy systems for maintainability. Once done with the initial re-engineering, they often can be hired to take on the maintenance itself.
Organizations trapped in legacy system "prison" usually maintain their systems enough to keep them running. But they need to realize that that approach prevents them from investing in the types of upgraded infrastructure or support systems necessary to meet emerging needs.
This lack of capabilities, along with the retirement of staff who developed, implemented, and maintained the legacy system, might force CIOs to make hard choices. Let this be a lesson -- the dollars you save today might come back to haunt in the future. Don't repeat the past. Investing in an aging system by keeping components up-to-date could improve your position tomorrow. And when you do invest in future technology, be careful not to make decisions that could lead to imprisoning your company in the future.
Adam Schneider is principal at Deloitte Financial Services consulting practice and chief advisor of the Deloitte Center for Financial Services in New York. He previously served as CIO/COO of Chancellor Capital Management and as a systems development manager for Goldman Sachs.
InformationWeek 500 companies take a practical view of even trendy tech such as cloud, big data analytics and mobile. Read all about what they're doing in our special issue. Also in the InformationWeek 500 issue: A ranking of our top 250 winners; profiles of the top five companies; and 20 great ideas that you can steal. (Free registration required.)
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.