Taming The Beast

The slow, invisible process of making one small change, then another, to software packages results in the IT staff ending up with maintenance responsibility for them. While one part of the staff is "trying to clean out the IT garage," Vecchio says, elsewhere in the company people are adding to it. At best, no real reduction in maintenance burden occurs; at worst, "it becomes a death spiral."

Chris Capdevila, a former systems integrator for Oracle applications, noticed how frequently buyers were frustrated by the limitations of software packages. As a result, "they did the wrong thing. They went in and customized them," he says. Capdevila founded a company, Logical Apps Inc., to supply a way for dealing with the resulting problems by building a software layer over the Oracle applications in which business rules could be changed without changing the underlying apps.

So far, few companies have implemented the Logical Apps approach or alternatives. Many still run version 10.7 of Oracle's applications, even though the company launched version 11i three years ago. Oracle plans to drop technical support for 10.7 applications at the end of this month. That means users "will have to maintain them themselves," Capdevila says--and add yet another layer to the buildup of legacy systems.

Vecchio and other industry experts say the same incremental buildup of legacy systems is happening throughout companies. For example, Redshaw says one unit of Motorola has 10 Oracle database systems, each needing its own hardware and support staff. To keep his legacy-system burden from growing, Redshaw says he wants to collapse them down to three.

In the same vein, Household's Gil says companies install different brands of databases on their mainframes, multiplying the number of license fees they have to pay. As a software engineer for EDS, he saw IBM DB2, Oracle, and Sybase databases running on the same machines. "If you have three database systems, you need three database administrators at $80,000 to $100,000 each," he says. So one of the first ways he tries to cut legacy-system costs is through database consolidation.

Too many legacy-strapped companies look for an easy out, Gil says, but there's no way of avoiding the pain and expense of carefully reengineering a set of aging applications into a more consolidated, componentized system. Tools exist to help do this: Java integrated development environments, application servers, Microsoft .Net's workbench of languages, and component and integration brokers. But before invoking such tools, the legacy-system user must first thoroughly document and understand all the logic branching and data paths of the system about to be reengineered. Such an "impact analysis" cries out for the use of automated tools, but most legacy-system projects get under way without them, Gil says. "You can take apart a car with pliers and screwdriver...but it will take a long time. It's better to have the right tools," he warns.

Experts in the field add that only when new development projects are designed with an eye toward the future, toward keeping applications relevant and easily upgradable, will new systems avoid becoming legacy systems. That means building applications that have discrete parts for data handling, business logic, and the user interface, which will allow any one part to undergo changes without disrupting the others, Vecchio notes.

Gil has tried to implement these principles at Household as it struggles to keep its legacy-system problem under control. Most large businesses are "concerned about the software-development life cycle," he says. "Little is said about the maintenance life cycle."

Maybe more needs to be said. Certainly, more needs to be done.