How to Increase the Reliability of Your IT Infrastructure Using Predictive Analytics REGISTER >
Analysis: What's the Secret to Keeping Your Legacy Systems?
Judging by this month's survey, legacy systems don't tie agile companies down. And that's not because agile firms don't have them. True, agile companies have fewer legacy systems, and they spend less on them. But agile firms find their legacy systems to be far more useful than at companies that, according to our respondents, cannot respond as quickly to market changes. What's the secret? It isn't the technology, experts and CIOs told us, or the age of these systems. It's the people behind them.
Problems arise when the people who create and update legacy systems move on, and the system becomes a mystery. "Many of these systems are rooted in the 1970s and 1980s, and people retire," says William Ulrich, president of Tactical Strategy Group in Soquel, Calif., and author of Legacy Systems: Transformation Strategies. "In some cases, the people who maintain them today aren't even as old as the systems themselves. Less agile companies probably don't understand their legacy systems. The people maintaining them may not know where certain functions are being performed or howwhich systems use which data, how data is defined or exactly what the business rules are."
Smart companies make sure they have people on staff who understand the ins and outs of their old systems. At Springfield Remanufacturing Corp. in Springfield, Mo., CIO Lloyd Ellis and two programmers maintain a 25-year-old database that tracks tens of thousands of parts used to remanufacture car, truck and tractor components. Begun in 1983 as a single operation, Springfield today is a collection of 12 wholly owned operating companies, with as many other partnerships. As the company expanded into new markets when opportunities arose, the database kept up. Ellis says he's kept it because new off-the-shelf packages won't integrate well with his legacy data. Still, he has managed to modernize, deploying newer, Web-based technologies on top of the database.
"I have to make sure I have people trained to work on the database," Ellis says. "My programmers and I are constantly modifying the system as we add new businesses and as the businesses change their strategies. If one of my programmers leaves, it would probably take a year to bring someone in and get them trained. I have to be aware of the age of my employees and their plans for the future."
Ulrich says CIOs can inadvertently get into trouble. "I see people try to save money by cutting 10 percent of their personnel, and they let go the people who understand these systems. Then the CIO says, 'I can't change the system.'"
CIOs must also deftly manage another group of people: the end users in the business units. "Often when business managers change, the new one wants to change the system," Ellis says. "I stay closely involved with what they're really asking for. I may be able to get the result they want without rewriting the code."
Since even knowledgeable maintenance technicians don't have all the answers, it's critical that vendors keep people who understand their old products. "We're fortunate that the company we purchased the system from is still in business, and the guy we dealt with is still there," Ellis says. "If I've got a problem I can't resolve, I call him."
Effective vendor management and good contracts are key to controlling legacy system costs, and controlling these costs is one mark of an agile company, says Mark Vanston, a senior research analyst with Meta Group. "If you have a mainframe and add on a new application, a secondary vendor might say you've increased the utilization rate and try to charge you more. Successful companies have good processes around legacy asset management and cost management."
Successful companies also manage the problem of systems outlasting people by documenting the changes they make, leaving a trail for others in the future. "We have requirements and standards so that changes are documented," Ellis says. "Then within the program itself we note what changes were made so people coming behind will have an idea."
Says Ulrich: "A large insurance company might have 200 million lines of code, and an average programmer can understand only a few dozen lines a day." Careful documentation of the inner workings of the system, on the other hand, can reveal "where the business rules are located in the code, how they relate to other business rules, and how they tie back to the data and to the business processes. This isn't difficult to do if it's done over a period of time. An agile company will be able to understand its system and continually document its changes."
"Agile companies recognize the value of their legacy systems," Meta's Vanston notes. But they also recognize the value of the people who keep these systems viable, and ensure that they, or at least their knowledge, remain with the firm. Says Ulrich: "The difference between successful and unsuccessful companies is how they let that baseline evolve and whether they attempted to retain the intelligence about the systems they are running every day."Terry A. Kirkpatrick