Businesses want to keep legacy software working as long as it’s useful, but at some point the software has to go. Who decides when that should happen, and under what circumstances the death knoll tolls can matter greatly. With a little extra thinking, a needed change may result in surprisingly great ROI and better workflow.
Sooner or later, software created at any point in time has to go. When is the question.
Businesses need solutions that can help them stay competitive, but they also can’t afford to spend money on software upgrades unnecessarily. When the old systems can’t keep up, it may be necessary to modify or replace them.
But it is not always clear which option – modification or replacement – is best, especially in the absence of due diligence.
“Legacy software is anything the new kids don’t want to play with. That’s the best technical definition, because eventually it defines sustainability, maintainability, and how much technical enthusiasm will be present in the application development process,” said Gary Baney, chief development officer at IT service provider Advanced Server Management Group (ASMGi). “There’s a symbiotic relationship between business and technology development. The biggest downside of legacy is that the symbiotic relationship has disappeared.”
Why Retire Software in the First Place
Mainframe software became synonymous with “legacy software” when PCs started taking over the enterprise. Today, IT is pressured to extend desktop business applications out to mobile apps.
Practically speaking, labels do not make businesses competitive; sound business solutions do.
“What language the code is written in or how old the software package is matters less than whether we can sustain it, support it and maintain it,” said Peter Anderson, CTO at Computer Systems Center (CCSI). “What comes into play is manufacturer end-of-life and how much risk we are willing to take.”
Imagine running an 8-bit computer in the field today that was built in 1969. It may sound silly, but the U.S. Marine Corp. is still using such systems for environmental control in 125° desert heat. Finding programmers is as difficult as finding technicians who can build the vacuum tubes needed to run the system. When the system was built, a replacement board cost $400. Today it costs $70,000, said Anderson.
“The people who are making technology decisions are not directly impacted by those decisions,” said Anderson. “They’re looking at things in terms of out-of-pocket cost rather than total cost of ownership. Meanwhile, I’m thinking about how much it costs to build a vacuum tube and test everything. Maintaining the old system is probably more costly than buying a new system.”
While the cost of maintaining an old system may indicate that a change is needed, it is also possible to spend more than necessary on a new solution.
One of Baney’s clients was prepared to spend $500,000 over 18 months to replace a 10-year-old enterprise resource management (ERP) system. The same functionality could be delivered at less than one-fifth the cost and completed in less than one third the time.
“The client wanted to add eight new types of functionality. All we really needed to do was tie handheld devices into the existing ERP database,” Baney said. Baney’s company had to upgrade the database and production server, add faster storage to improve the old system’s processing capacity, and put a mobile front end on it. “They’re still running the legacy app and they got everything they needed for $85,000,” he said.
Who Decides When to Pull the Plug
Poor legacy software replacement decisions happen when technology decisions are not aligned with business requirements. What’s chosen and how it’s applied can mean the difference between leading or lagging behind competitors in any given industry.
As acting CTO of CSCI, Anderson is charged with making recommendations to the CFO and CEO. Before he does that, he holds regular meetings with the systems operation lead and the systems development lead. They collectively determine whether the hardware has become outdated and if the current base of developers is capable of accessing or modifying the code.
“If we get to the point where I can’t find hardware or we no longer have the development expertise, we get an uncomfortable feeling that we’re accepting more risk than we should,” said Anderson. “My CEO doesn’t like to accept risk at a time when economic factors are affecting small businesses.”
Norm Ringgold, former Head of IT Operations and Infrastructure for Stanford Linear Accelerator Center (SLAC) manages legacy software transitions in a formalized IT Infrastructure Library (ITIL) Application Lifecycle (ALC) manner that is becoming more common in medium to large enterprises. The idea is that a governing body should make “informed” IT business decisions, based upon the business value proposition.
It’s expensive to develop new business solutions, he pointed out.If an existing application continues to accommodate business requirements, and the complete platform, licensing, service, and support model presents a continued value proposition, why change? “I usually don’t suggest an application solution change unless a value-based business driver or a technology emergency warrants it,” said Ringgold. “In many cases, an application lifecycle is determined by some sort of significant event such as a merger or acquisition. When Oracle acquired Sun Microsystems and declared it was going to kill the Sun Solaris platform, it created a technology emergency requiring global application change. It also opened the door to third-party solution opportunities.”
At the time, the US Postal Service, where Ringgold worked, had 2,000 servers running Solaris applications. Although events like the Sun acquisition cannot be fully anticipated by customers, it is possible to manage that and other risks in a way that minimizes fallout.
When a change is indicated – whether by circumstances or astronomic maintenance fees – Ringgold preliminarily investigates whether better ROI could be achieved another way. If better ROI seems likely, he presents a suggestion to a review board that includes the cost of doing a more detailed investigation of the current business processes, how the application is performing at that particular point in time, and the options for replacement (including hardware, software, virtual machines, applications, end user training, and usage costs). He may present a trio of solutions from a trio of vendors upon which a business-based decision can be made.
“The business has to have enough information to choose the platform, the application, the vendor solution, and total maintenance cost,” said Ringgold. “There’s still a place for an SDLC but we’re talking about a more sophisticated way of dealing with it.” Today’s IT leaders’ application management strategy style includes an informed governance entity (with key business and technology representation) involved in every major decision technology decision made. “The partnership ensures the delivery of valuable solutions, as well as timely replacement of less valuable legacy solutions,” said Ringgold.
While highly sophisticated organizations are actively working to improve communication between business and IT professionals, challenges remain. A lot of technicians won’t give the business unit the time of day because they don’t think the business unit respects them enough. And there are business units that don’t respect technicians because they don’t think they listen enough. “If a corporate culture is going to thrive and remain perpetually competitive, there has to be a strong sense of partnership between the business unit and the technology group,” said ASMGi’s Baney.
Easing Legacy Transitions
Legacy transitions often have several points of friction involving people and technology. While having a formal governance body is increasingly viewed as essential in large organizations, smaller businesses fear such a formality negatively affects their agility.
Smaller companies push back on the idea of having a governance body, sometimes. “I remind them that it’s not necessary to have 20 people on it when three will work,” said Ringgold. Companies die trying to manage application change. “The best way to prepare for it is to put in place a software development lifecycle, application lifecycle management, and a governance body that is capable of accommodating agile change, connected to business requirements.”
As for technology, Baney suggests a four-step approach to avoid missteps.
First, make sure the documentation is complete. Issues arise when software and systems are not well documented or the documentation has not been kept up to date. Ideally, the documentation should make it possible to ascertain the real state of the code base, the architecture, integration, and APIs.
Second, determine how stable the application is. Baney checks error logs to determine where defects are and the ripple effect those errors may be causing in the enterprise. It may be that service levels are deteriorating and the root cause is a particular application.
Third, understand the integration points. This helps you determine which applications are monitoring others, communicating with others. and what interfaces you would have to rebuild if something changes.
“You have to have a few meetings in which you say, ‘Look, you have to do a rewrite here but we don’t want to create a ripple effect that affects you,’” said Baney. “You have to study interfaces and APIs intensely and understand them very well.”
Finally, sit with the business unit with the goal of understanding the application’s workflow. It may be that the current workflow is the result of a manager’s personal preference or because it was specifically designed to improve business process efficiency. Walk them through the business workflow. Make sure you’re doing things the right way or see whether there are 18 opportunities for improvement. “If there are opportunities for improvement, tie it to ROI,” said Baney. “If I can cut a claim agent’s claim processing time from 20 minutes to 11 minutes, I just impacted customer experience. Efficiencies, customer satisfaction, and accuracy all feed into ROI.”
Since change is inevitable, the management of that change can make the difference between staying competitive or falling behind the competition. Regardless of the organization’s size, there should be a process for ascertaining what change needs to happen and when it needs to happen. Establish a group of decision makers who have the dual goals of acting in the company’s best interest and minimizing risks.
While some changes can be anticipated – such as an operating system’s or application’s end-of-life date – others cannot. Savvy organizations make change management a priority so planned and unplanned events can be managed in a way that minimizes unnecessary risks and costs.