Quiz: What is "legacy" software?
a. Cobol/mainframe code
b. Software written before 1990
c. Applications that have become obsolete
d. Poorly documented systems that no one wants to touch
e. Secure, reliable and effective stuff that just keeps running, year after year
Interviews with a number of IT managers turned up all of those definitions, and more.
"Legacy is a word I despise," says Frank da Cruz, an IT manager at Columbia University in New York. "People say 'legacy' and it's like, 'Oh my god, how could you possibly use that old garbage?' But what it really means is that it was written by smart people a long time ago and it really works, instead of being the latest bug-ridden, bloated piece of garbage from some company that has only teenagers working for it."
However you define legacy software, IT people say they know it when they see it, and they know it didn't all go away during Y2k remediation. It's the stuff with poor documentation, spaghetti code stirred by too many cooks, and processing cycles more appropriate for 1970s ways of doing business. And it's definitely not the stuff you tell college recruits about when they come looking for Java, Web services and grid computing.
|Frank da Cruz, an IT manager at Columbia University|
Image Credit: Manuello Paganelli
Yet, like da Cruz, a number of IT folks swear by it, not at it, saying they wouldn't dream of switching that trusty old accounting system they custom-coded in the 1980s for some newfangled commercial package with a seven- or eight-figure price tag.
But even the most enthusiastic of the legacy loyalists acknowledge that old software often presents special challenges. They employ a number of tricks -- both managerial and technical -- to keep the bits flowing in those old pipes.
Not Older; Better
For Paul Grant, director of retail systems application development at Tower Records in West Sacramento, Calif., "'Legacy' is when the technology can no longer fit the business needs." By that definition, Tower's retail point-of-sale software, some 1 million lines of Cobol code dating to the mid-1980s, isn't legacy software.
Although Tower is modernizing it in various ways - by adding Web services interfaces to other systems, for example -- the underlying Cobol application is likely to serve the company for years to come, Grant says. "A lot of people get caught up in the wow and sexy stuff, but I've been a proponent of keeping what we have rather than starting all over, because I don't see the benefit," he says.
But it would be a mistake to think that Tower Records got its million lines of Cobol to its current useful and reliable state without a great deal of effort. Tower bought the software in the early 1990s from a small vendor that supplied point-of-sale systems to mom-and-pop video-rental stores. "The source code was terrible," Grant recalls, "and we had no documentation."
Tower wrote its own user manuals, which it eventually gave the vendor as partial payment for the source code. As for the software, "it was spaghetti code, with a few meatballs thrown in," Grant says. "Every time we asked for a change, we'd get other retailers' changes along with it. So the code got very bloated very quickly."
Tower gradually rewrote much of the code, making functional enhancements and breaking it into more manageable modules. For example, one 750,000-line program was broken into four programs, and the custom code written for other retailers was thrown away. It took three to four years of "blood, sweat and tears" to do that, Grant says. "Anytime we opened the code to make changes, we'd do as much maintenance as possible."
But, Grant notes, "we ran into situations where we just couldn't untangle the mess, so we left it. We didn't want to break it."
More recently, Tower has been able to avoid much of the previous angst by using the AcuBench Cobol development tool from Acucorp Inc. in San Diego. It replaces, among other things, a Unix-based VI Editor that Grant describes as "terse and slow" as well as manually written editing and searching scripts. AcuBench greatly speeds maintenance and debugging work, and it helped Tower "untangle the spaghetti code," he says.
Business Trumps Tech
|Jan G. Rideout, vice president and CIO at Northrop Grumman Corp.|
The Ship Systems unit of Northrop Grumman Corp. in Pascagoula, Miss., has about 7 million lines of mainframe-based Cobol and Fortran code. Dating from the late 1970s and early 1980s, it supports finance, human resources, payroll, materials management and some engineering applications.
Jan G. Rideout, a vice president and CIO, says there isn't much of a technical case to be made for replacing the old code with something more modern. "Maintaining those systems is pretty easy for us," she says. "The mainframe environment is very secure, configuration management is excellent, and we have excellent tools."
But can she find people to maintain those dusty old systems? "We have a very low attrition rate," she says. "We do hire programmers out of college, and we do teach them Cobol."
Nevertheless, for business reasons, Ship Systems decided two years ago to scrap most of the legacy code in favor of packaged software from SAP AG.
The legacy software is no longer flexible enough to meet the needs of the business units, Rideout says. "It limits the types of really large process improvements they could make," she says. "While they can make incremental, small changes, this basically dictates the way they run their business."
For example, Rideout says, using wireless I/O devices at the company's shipyards would be very attractive, but it would require building a whole new set of applications on top of the legacy systems.
Still, Rideout cautions managers not to expect big maintenance cost savings after SAP has gone live. "That's overhyped by the suppliers who want to encourage you to replace your mainframe systems," she says.
But during the long SAP phase-in, Rideout says, she'll continue to pay close attention to the personnel issues presented by a 250-person IT organization going through a major transition. Knowledge of older systems in the heads of older workers must be shared with younger workers, who in turn must be given a chance to work on more modern technologies, she says.
"Once people get over the it's-my-father's-Cobol thing, the young kids can be a little open-minded and get into these older systems and see that there are some interesting aspects to them," Rideout says.
Bill DeRosa, vice president of IT management at DaimlerChrysler Services Americas in Farmington Hills, Mich., says he has three major systems that are more than 15 years old, including a wholesale system that tracks vehicle inventories on dealer lots. "We have looked at them from time to time and haven't come up with a real good reason to replace them," he says.
In fact, those mainframe Cobol systems provide a model for modern distributed systems when it comes to security, maintainability and change management, he says. "We are reinventing the wheel in the client/server world in terms of putting the disciplines in place that we already know how to do on the mainframe, " DeRosa says.
But he acknowledges that maintaining old Cobol systems isn't what his developers want to do. "So we see this as a great opportunity to go offshore," says DeRosa. "The main driver for the legacy systems is people, and India gives us a way to prolong the life of these systems."
Indeed, another automaker has also found that the way to deal with legacy headaches is to outsource them to someone else. General Motors Corp. has turned over most of its late 1970s and early 1980s code to Electronic Data Systems Corp. Still, GM holds an annual review of those systems to determine whether any of them ought to be modernized or replaced.
And, says Fred Killeen, acting chief technology officer, GM enthusiastically entertains suggestions from EDS as to how the systems might be improved. "It's the kind of thing we want suppliers to bring to us," he says.