Feds confront their legacy applications
CIO Audrey Y. Davis has helped cut DFAS' 324 legacy systems down to size.
Many ask, 'How do we get there from here?'
'The one thing we totally underestimated was the resources it takes to truly understand how legacy systems work.'
'Air Force Lt. Col. Jon Dittmer
Congress and the public are calling on federal agencies to fling open their back-office doors and let electronic data and services flow onto the Web.
But many of those back-office applications rely on poorly documented and complex legacy code, often in proprietary environments. Getting the data from those systems to support secure transactions is, to say the least, a challenge.
Congress threw down the gauntlet with the Government Paperwork Elimination Act of 1998, which gives agencies until next year to meet the challenge 'wherever practicable.' Agencies that fail might find the congressional purse harder to open.
Ultimately, however, pressure to modernize comes from citizens grown accustomed to easy access to e-commerce and the worlds of data, goods and services that are just a few keystrokes away.
'E-commerce is definitely setting the bar for e-government,' said Dale Vecchio, an analyst at Gartner Inc. in Stamford, Conn.
'Creating a Web site, making services available via your Web site, doesn't make your life easier; it makes it harder,' Vecchio said, because 'expectations of end users are being set by Lands' End or MySimon.com
But first agencies must decide how to extend the functionality of their legacy systems and vault a few hurdles:
- The pool of programmers with the skills to migrate legacy applications to the Web is small and shrinking, and feds must compete for them with industry.
- Migrating from a legacy environment to Web-based one is a complicated process, made more complex by the demands of privacy and security.
- Standards are still evolving.
- The tools for legacy programming languages are less robust and flexible than those for newer languages.
- Funding is hard to come by.
With some success, federal IT departments are picking their way through this thorny path.
The Air Force is taking a two-step approach to upgrading its supply systems, extending its Standard Base Supply System while developing a modular system that will run partly in parallel.
At the moment, the service is 'about neck-deep' in the extension half, said Lt. Col. Jon Dittmer, program manager for the project to develop the Integrated Logistics System-Supply (ILS-S).
The service is writing extensions to its SBSS application code and moving the system to an open environment. It also is maintaining legacy Cobol code to ensure the delivery of supplies to warfighters and military bases around the globe, Dittmer said.
'The fielded systems have to keep current; we're still implementing changes that have to be made as a result of Sept. 11,' he said.
Meanwhile, the Army is developing the modular system in parallel. ILS-S is a combination of commercial software and Java applications for specific military tasks. Project managers expect it to unify the efforts of nearly 60 separate Air Force supply systems.
Although it's a fresh beginning for SBSS, ILS-S won't show even modest returns on investment for 10 years, Dittmer said. 'We were lucky that our customer, the Pentagon, has been supportive of us and willing to make the strategic investment,' he said.
For most agencies and systems, such a clean sweep is not an option. But that might not be entirely a bad thing, analysts say. Alternatives to outright replacement often are better choices.
'A lot of what old legacy systems do, they do well,' said Jonathan Eunice, president of IT consultant Illuminata Inc. in Nashua, N.H.
'And although they may be restrictive, they tend to have good security,' he said. With standards for authentication still in flux, security is nothing to sneeze at, he said.
And then there is the sheer size of some of the old systems. A legacy system might have 20 million lines of what is likely largely undocumented code, Eunice pointed out. 'You can't replace that overnight.'
The National Endowment for the Arts, for example, last year upgraded a Wang Cobol system of about 650,000 lines to C++ and rehosted it in a distributed environment. The process went smoothly'surprisingly so, said NEA CIO Mike Burke'and took seven months.
Industry can justify the high costs of replacing systems by showing anticipated increases in earnings, Vecchio said. Agencies, by contrast, would need to show lower maintenance costs, which can be difficult.
The Defense Finance and Accounting Service has, since its creation in 1991, been steadily consolidating the 324 systems it inherited from Defense Department agencies and the military services. Although many of the systems had to be replaced'as DFAS edges toward its goal of getting down to 30 systems'rehosting systems has proved cost-effective in some cases, CIO Audrey Y. Davis said.
In making a funding case for a legacy upgrade, systems executives said, it is important to develop a return-on-investment proposal that establishes where reduced maintenance costs come from. And in making that proposal, it's crucial to enlist the help of users in a business process re-engineering effort first, said Rick Heroux, program manager for the Electronic Data Gathering, Analysis and Retrieval system at the Securities and Exchange Commission. SEC last month completed the final phase of its three-year, $22.5 million EDGAR modernization.
'Have the users eliminate ancient or duplicate processes,' Heroux said. 'Help them look for the inefficiencies, so you're only automating the efficient processes.'Necessary feedback
Heroux kept users involved with EDGAR throughout its development. 'We sat down with them and determined what the system had to do and what it should be. We argued it out. Then we put the request for proposals on the street,' he said.
For many agencies, extensions'code that creates a bridge between new and legacy applications'helps boost an ROI statement's bottom line.
'There have been some big wins in Java and Extensible Markup Language wrappers in how well you can wrap a back-end Cobol application or an IBM CICS in Java 2 Enterprise Edition and extend the application to an intranet or to the Web,' Eunice said.
Although Illuminata's Eunice thinks outsourcing the running of legacy systems is inappropriate for agencies because of the level of customization, he said outsourcing the writing of extensions is wise.
Companies such as Relativity Technologies Inc. in Cary, N.C., which has worked with the Air Force on the SBSS and ILS-S projects, can help identify the business logic and rules embedded in Cobol systems and port them to Java gateway code.
That takes a joint effort of skilled personnel, the Air Force's Dittmer said. 'The one thing we totally underestimated in SBSS was the resources it takes to truly understand how legacy systems work,' he said.
That's one area where the EDGAR modernization had a big advantage, SEC's Heroux said. 'The contractor that built the new system is the one that was operating the old one, so they could more easily extract the business logic than if they were seeing it for the first time,' he said.
Programmers can also use commercial tools to generate proxy code that can extend the life and functionality of legacy systems, Eunice said.
A presentation-level extension code set, such as writing a new interface to a terminal-based legacy system, can increase functionality, he said. 'Some of these old user interfaces are so crusty, only a well-trained clerk is able to get through,' Eunice said. A new, simple-to-use interface can make the system accessible to more people.
Although extensions mean running the old code plus the added overhead of the extension's proxy or gateway code, that avoids the risk of breaking old code.
It also helps users work with a familiar system while getting used to a new one. SEC ran EDGAR in parallel with the legacy system for several months'giving filers the option of using either system'and gave plenty of notice when the old version was going offline.
'The users really needed to compare the data to feel sure about the results they were getting,' Heroux said. 'So we'd populate both applications with the data so they could see the results from the old application and the new one, side by side. Only when they were sure did we switch off the old system.'Off the rack
Replacing legacy systems with commercial software also is possible.
At DFAS, Davis said, the service has made only limited use of commercial software but is open to the idea if a package doesn't require much modification.
For some applications, the choices are limited. Vecchio recommended 'some level of extension, or making the application callable from other applications, creating composite apps.'
An agency also could analyze its portfolio of applications and find that a system works but needs better reporting and analysis, said Art Tumolo, a legacy systems expert for Oracle Corp.
'That's more of a data issue than an application issue,' he said.
A new application could be used concurrently with the legacy app. Both would have access to the data, which would be migrated to a modern relational database management system.
It's an approach unlikely to have wide usefulness, Vecchio said, because moving data from a nonrelational to a relational DBMS can cause problems.
But whatever option an agency chooses to update its legacy systems, the approach should be one that looks ahead to the planned governmentwide enterprise infrastructure.
Debra Stouffer, the Office of Management and Budget's federal enterprise architecture program manager, last month recommended J2EE and Microsoft .Net as underlying technologies for e-government projects, with J2EE holding an edge in Web services capabilities in a ranking done by an OMB team .
Stouffer said architectures based on either of the two products can result in reusable, stable, interoperable, portable and secure systems'all of which are requirements for the 24 e-government projects OMB is supporting.