Keeping Air Force Flying High

Now is the time when the U.S. Air Force should be ready to fly at a moments notice—not mired in outdated legacy code.

Unfortunately, like many government agencies, the Air Force has found itself hampered by 30-year-old legacy systems that make it difficult and time-consuming for its people to track down important supplies such as airplane parts. So the Air Force is in the middle of an ambitious, four-year project to re-engineer its clunky, mainframe-based supply management system by, among other things, allowing 20,000 users in more than 300 locations around the world to order critical supplies over the Web.

Keeping the Air Force in a holding pattern has been what the agency calls its SBSS (Standard Base Supply System), which officials all over the world use to order everything from pencils to airplane parts. The aging system—which interfaces with almost 50 other applications and 1.5 million lines of code residing in more than 600 programs—runs on a Unisys Corp. 2200 Clearpath mainframe and uses a proprietary DMS-100 database management system. But SBSS reliance on proprietary hardware is only a small part of the problem. The bigger issue is that the applications SBSS must interface with dont talk to each other. They cant easily exchange files. Each has its own catalog. That means each of the 50 catalogs must be maintained and synchronized separately, and if they arent kept up-to-date, data errors are generated and must be reconciled.

It also means that something like an aircraft part can take officials up to eight days just to locate and order, said Lt. Col. Jon Dittmer, chief of the Supply Systems Division, based in Maxwell Air Force Base Gunter Annex, in Alabama.

The situation plainly mars combat readiness. "Without modern systems, it makes the job all that much harder," said Lt. Col. Rick Jones, a logistician at the Pentagon, in Washington.

Thankfully, after one costly false start and a few years of untangling aging COBOL code, the Air Force is now well on the way to pulling its core logistics and supply systems into the Internet age. The plan is to modernize—rather than replace—existing code, adding Internet access via a Java-based front end and integrating previously separate applications so users can see and access shared supply information from a single interface. The applications will be upgraded from the COBOL 85 in which they are now written to a more up-to-date version of COBOL from Micro Focus International Ltd. and moved to an open hardware platform on Sun Microsystems Inc. E10000 and E6500 servers running Oracle Corp.s 9i database management system.

The first step in the SBSS modernization project—which launched in 1999—was simply to make sense of 30 years of largely undocumented COBOL code. The Air Force is using Relativity Technologies Inc.s RescueWare software, which automates much of the process of analyzing, documenting and translating legacy code into Java. At the end of next year, the migration of code, which Dittmer is now overseeing, will be complete. By then, the supply system is slated to be free of the Unisys environment. Moreover, the supply systems will be integrated and accessible via browser. By the end of the project, the eight days it once took to locate and order supplies will have shrunk to virtually real-time response.

Why not just replace the entire SBSS, either by rewriting it from scratch or by installing a piece of off-the-shelf commercial code? Air Force officials considered both options but rejected them as either impractical or too expensive. An off-the-shelf product would never meet all the Air Forces requirements or its open systems specifications. Besides, the Air Force had tried and failed once before to go the packaged-software route. In 1996, the Air Force bought a commercial off-the-shelf product, Western Pacific Systems Government Online Data System, to replace the supply system and provide the core of the integrated logistics system of which SBSS is a part.

The outcome wasnt good. After three painstaking years and a substantial investment—Dittmer declined to quote a cost—a mere 27 percent of the original codes functionality had been reproduced. Originally, Dittmer said, they had expected to retrieve 60 percent of functionality. Eventually, the Air Force killed the project.

Rewriting the systems from scratch would have eaten up an impermissibly large chunk of the Air Forces budget. "We dont have the money to go out and say, OK, lets wholesale replace everything," Jones said.

Many organizations—particularly government agencies—will make the same decision in the coming years to revamp rather than replace legacy systems. When tackling such a large project, however, experts say enterprises shouldnt expect a tool such as RescueWare to perform magic. After all, even a partial move from a third-generation language such as COBOL to an object-oriented language such as Java is a "huge paradigm shift," said Phil Murphy, an analyst at Giga Information Group Inc., in Cambridge, Mass. Murphy recommends that before committing to using such a code analysis and conversion tool, enterprises test the outcome of its operations to determine if the original code can be faithfully translated to a language such as Java.

Another thing to keep in mind is that even if a code conversion tool does work, these tools only help with about 20 percent to 25 percent of a project. The remaining 80 percent to 75 percent of system development comes down to other tasks, such as testing, which these tools dont help with, according to Murphy.

Of course, when youre looking at re-engineering 1.5 million lines of code, shaving even 20 percent of the work off the job can be more than worth it. "It only makes sense that if theres a technology ... that can make COBOL or FORTRAN or whatever dated language translate into JavaScript, [Extensible Markup Language] or any modern language—now, thats valuable," Jones said.