Are Legacy Systems Keeping You Prisoner? - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Government // Enterprise Architecture
10:00 AM
Adam Schneider
Adam Schneider
Connect Directly

Are Legacy Systems Keeping You Prisoner?

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.

[For more insights on IT leadership, read What Star Wars Teaches Us About Technology.]

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.)

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Oldest First  |  Newest First  |  Threaded View
User Rank: Author
12/12/2013 | 4:33:32 PM
Sunk costs
One other reason agencies end of being "chained" to their legacy systems is the notion of sunk costs -- that too much has already been invested in the system to walk away. Sometimes that's the arugment of the CFO who doesn't believe in the payoff of the necessary investment; sometimes it's the argument of the IT teams that don't want to surrender the fruits of their work (or fear new investments will mean loss of jobs.) 

That's why its so important that the mission/business/program owners, together with the CFO and CIO really assess the true costs of holding on to legacy systems (and the added costs of missed-opportunities) when weighing the pro's and cons of investing in new systems. 
User Rank: Author
12/14/2013 | 9:40:41 AM
Re: Sunk costs
Picture the scenario Mr. Schneider describes about a system based on hardware from a vendor that went out of business, having to cobble together spare parts and dwindling knowledge base; now insert "cloud vendor who went out of business" for the hardware vendor. You don't get a 5-year ramp down option with a busted cloud vendor. We have a lot of lessons yet to be learned when it comes to how cloud systems play out over time.  
User Rank: Author
12/16/2013 | 11:45:05 AM
Re: Sunk costs
Chris, you raise an important point: As the enterprises move to the cloud, they become increasingly interdependent on an ecosystem of cloud service, software and infrastucture providers --  beyond what any single vendor or customer can cotnrol. So if one member of the ecosystem fails, how will the remaining players fill the sudden vacuum?

InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Becoming a Self-Taught Cybersecurity Pro
Jessica Davis, Senior Editor, Enterprise Apps,  6/9/2021
Ancestry's DevOps Strategy to Control Its CI/CD Pipeline
Joao-Pierre S. Ruth, Senior Writer,  6/4/2021
IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll