Love that 'legacy'

Comments

Quiz: What is "legacy" software?

Cobol/mainframe code
Software written before 1990
Applications that have become obsolete
Poorly documented systems that no one wants to touch
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 IT manager Frank da Cruz. "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," says Da Cruz of New York's Columbia University.

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. Yet, like da Cruz, a number of IT people 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

Paul Grant, director of retail systems application development at Tower Records in California, says it's 'legacy' when the technology can no longer fit the business needs. By that definition, Tower's retail point-of-sale software, some one 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 mum-and-dad 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. 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

The Ship Systems unit of Northrop Grumman Corp has about seven 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 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 favour of packaged software from SAP.

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, says he has three major systems that are more than 15 years old, including a wholesale system that tracks vehicle inventories in dealers' yards. "We have looked at them from time to time and haven't come up with a really 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 carmaker 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. 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.

Words time forgot

IT manager Frank da Cruz says it's not fashionable to admit to running old systems. "People say they have to have the latest version of Windows and the latest three-letter acronym or buzzword or their stock will go down," he says. "But the people in the back office are running something that's really battle-proven and tested and secure, like VMS, for example."

Da Cruz is the author of an online history of computing. Among the gems to be found in it is his "Glossary of Forgotten Terms". Here's a sampling from the good old days: