Legacy apps: to the scrap heap or to a new platform?

Moving legacy applications from traditional mainframe platforms to open systems demands that IS organizations answer some questions up front. Should the applications be scrapped and completely rewritten? Or should they be reengineered to better utilize the new platform? The options are many, the repercussions long-lived.

Naturally, time and monetary constraints weigh heavily in the decision-making process. When a firm is ready to cart an old platform out the door, MIS wants to convert the systems to the new equipment as quickly as possible. What might seem like the best migration solution may require too much time and money to implement. In that case, many enterprises prefer some less costly plan.

When migrating legacy applications, IS typically addresses several issues. In deciding whether to rewrite or reengineer, the organization usually examines the condition of the applications, the availability of appropriate reengineering or development tools, and the availability of experienced developers.

Dick Rislove, practice director for system refurbishment at Horizons Consulting Inc., a Minneapolis-based subsidiary of Computer Horizons, headquartered in Mountain Lakes, N.J., has found that most users do not understand in detail what their systems are doing. Without this knowledge, Rislove said, users cannot make an informed decision about whether to rewrite their old applications or reengineer them. "Rewriting makes sense when the application is either functionally or operationally inadequate," he noted. "Reengineering is recommended when the system operates adequately and satisfies functional requirements, but is expensive or risky to maintain."

A decision to rewrite or reengineer an application should be driven by business or functional issues, not by technical advancements, suggested Benny Popek, the Boston-based national outsourcing director for the consulting firm Coopers & Lybrand.

"If the business processes are still satisfactory and the core applications are alright, customers usually choose to reengineer to the new platform, perhaps performing a code clean up along the way," Popek said. "If the business processes are going to be done a new way with a new technology, then customers rewrite or replace the applications."

Rislove of Horizons Consulting said most of the projects he sees involve reimplementing older applications; only 20% or so of the development efforts provide new functionality. Therefore, code reusability should be an important goal for any IS group, he said. Rislove also cited a second goal for IS -- to reduce the maintenance effort spent on keeping legacy applications running and redirect that energy to new projects.

For consulting projects, Rislove said he often uses Intersolv Maintenance Workbench from Intersolv Inc., Rockville, Md. He said the tool can help extract business knowledge from existing systems for reuse in new development, and improve the maintainability of existing systems.

Frank Hanou, Intersolv's director, product management, maintenance solutions, described the Maintenance Workbench as a desktop maintenance environment that can integrate with third-party, PC-based tools. It can also perform maintenance functions on local-area network (LAN)-based client/server platforms using Intersolv's PVCS Production Gateway, which synchronizes the mainframe and LAN libraries, Hanou said.

CLEARING THE PATH TO CLIENT/SERVER

    BUILD             PREPARE SYSTEMS      MIGRATE APPLICATIONS

 CLIENT/SERVER        FOR CLIENT/SERVER      TO CLIENT/SERVER
MIGRATION PLAN            MIGRATION           ARCHITECTURE
Develop assessment      Stabilize source      Finalize integrated
     proposal         language baseline        data architecture

Assess IS application      Stabilize            Develop target
   infrastructure       application code       process models
Perform feasibility  Standardize system-       Complete target
      analysis       wide data definitions  client/server design

Build application       Remodularize            Finalize data
   migration plan   selected source code     integration phase

SOURCE: WILLIAM ULRICH/JAMES MARTIN & CO.

BPR Sheds Some Light

The decision to rewrite a legacy application can be a painful one, noted Coopers & Lybrand's Popek. But, this decision may be the right one if the application is not adequately handling business processes. These inadequacies often come to light when business process reengineering changes the way an enterprise works, Popek said.

[CHART OMITTED]

For example, when Florida Power Corp. (FPC) in St. Petersburg began to reengineer its business processes in anticipation of power company deregulation, it realized that its application software needed new functionality. In a joint project with Andersen Consulting, Chicago, FPC is replacing its 20-year-old customer service system with an up-to-date system that can be remarketed to other power companies. Michael Gresh, FPC's capacity planner, said the old system, which services more than 1.3 million customers, was written in Cobol for the mainframe and used the IDMS, CICS and Vsam DBMSs.

The new system will operate in a client/server environment, with FPC's mainframe operating as the largest node on a TCP/IP network. FPC and Andersen are using SES/Workbench from Scientific & Engineering Software (SES) Inc., Austin, Texas, to model the system. Gresh said SES/Workbench can predict the larger architectural performance of the system, and also performs capacity planning functions.

"SES/Workbench pulls every part of the project together with its highlevel architectural view," he said. "It lets you focus on subsystems, defining and then improving performance levels."

A second reason for scrapping old applications and rewriting them is to eliminate software systems that never ran correctly. Applications need to be replaced when programmers do not understand particular packages; when software requires high maintenance; when an application is not used correctly by the business "owner"; when data is frequently lost; or when functionality is poor.

The State of Texas Department of Information Resources in Austin operates as a service bureau for various governmental licensing entities. According to James Kocurek, project manager, one of the agencies he supports has a system that is not meeting current needs. The system comprises more than 800 Cobol programs that run on clusters of VAX/VMS-based VAXes from Digital Equipment Corp. (DEC), Maynard, Mass.

After recently hiring outside consultants to analyze and design the new application, the agency chose a fourth-generation language (4GL) tool from Uniface Corp., Alameda, Calif., a unit of Compuware Corp., Farmington Hills, Mich., which acquired the development tool maker this spring. "We chose Uniface because it works with many different databases," Kocurek said. "It is portable and supports many different platforms." He estimated that the rewrite task will take 15 months.

Though many firms choose to rewrite their legacy applications, most acknowledge that writing an application from scratch is usually a much bigger project than reengineering it. Gathering requirements, designing the application, and generating code are significant tasks. Developers must create, execute and analyze a whole new set of tests for a new system. In addition, an organization must train users, write documentation, and develop and test interfaces to other systems. And it generally costs more to rewrite a system than to reengineer it.

Asarco Inc.'s Commercial Sales System proved to be an exception to that tenet. Asarco, New York City, decided to shift its computing paradigm from mainframe-based to client/server during the consolidation of its East Coast offices. The systems to be shifted consisted of Cobol-based financial, sales and customer service applications.

Rather than port the sales application to a new platform, Asarco decided to rewrite it using the consulting services of Trecom Business Systems Inc. of Edison, N.J.

"Rewriting the Commercial Sales System was less costly than simply porting it to the PC/LAN," contended Richard Demko, director of information systems at Asarco. "Rewriting gave our developers an opportunity to focus on client/server and relational database technologies. Lastly, the new GUIs [graphical user interfaces] provided easier training for our users."

According to Eric Besnecker, Trecom's project manager, the application was co-developed by Trecom and Asarco engineers. Asarco decided to jointly develop the software so it would not have to depend on Trecom to support the application. Besnecker said some outside consultants that specialize in application development remain at user sites indefinitely to maintain and support new applications.

"This project was co-sourced," Besnecker said. "This method of development enables the customer's programmers to maintain the system after installation without the assistance of consultants."

One of the most compelling reasons for rewriting legacy applications was reported by Joseph Boeggeman, chief of process management at the U.S. Strategic Command's C2 Systems Support Division at the Offutt Air Force Base in Offutt, Neb. Five years ago the division was charged with converting a number of support applications from Cobol to Ada. The applications ran on a Sperry 1160 mainframe and the Air Force wanted to move them to PCs running Windows.

"There simply were no tools available five years ago that would convert Cobol code to Ada," said Boeggeman. Also, no programmers were mature enough in the new platform to be useful for the project. The Systems Support Division determined that rewriting the applications was the only safe way to move them to the Ada/Windows platform.

Companies whose legacy applications number in the hundreds sometimes require more than one solution. For example, Texas Instruments (TI) Inc., Dallas, established a special R&D project called Peer 1 whose goals include defining approaches for converting legacy applications to client/server environments. Alex Townes, Peer1 program manager, provided insight into the magnitude of the client/server challenge for TI. "TI has 400 application systems containing 80 million lines of code, only 15% of which are in its Case tool, IEF. These applications are mainly Cobol and use IMS DB/DC for online transaction processing and database management. Over 50% of the processing is performed in batch runs," he said.

Townes said Peer1 recommends reusing software whenever possible. The next best choice is for TI to purchase software. "The project's cycle time to install a package is quicker than it is with a redevelopment project," he noted. "After all, there is no strategic benefit to using home-grown systems to handle standard applications like billing, payroll and other general accounting tasks." Only if no packages are available does Peer1 recommend rewriting.

The rich functionality inherent in many legacy applications is often the best reason to retain as much of their code as possible, some observers say.

In 1991 the Orange County Property Appraiser's Office in Orlando, Fla., decided to convert its mainframe system to a Windows-based client/server platform. Eric Singleton, director of information technology, was faced with the decision to rewrite or reengineer a massive property appraisal and distribution system that managed more than 340,000 properties and supported more than 600 in-house users.

Singleton said the Cobol application was still functionally satisfactory, but had components that "needed help." The code had been written in the late 1960s and patched during the '70s. The agency chose to reengineer the system because "writing the application was costly and it would take many years to recover the investment," Singleton said.

The agency selected the CA-Realia II Workbench product from Computer Associates (CA) International Inc., Islandia, N.Y., to perform the modifications required for the new platform.

The conversion was not a quick one, said Singleton. "Planning through implementation took 14 months. However, we have found an additional benefit in our ability to redeploy the data entry personnel."

Outdated hardware was the driving force behind a reengineering effort at Houston's Harris County Appraisal District (Hcad). Yogi Parikh, MIS director, said the agency was using Uniscope terminals, which the manufacturer, Unisys Corp., Blue Bell, Pa., no longer made. "With active accounts of $1.5 million and still growing, we found that the system wasn't keeping up," said Parikh. Hcad's solution was to upgrade from a Unisys 1160 to a Unisys 2200 for more capacity and to introduce document imaging and geographic information systems.

Providing interoperability between the reengineered legacy applications and the agency's Sun Solaris Unix-based imaging systems was a crucial part of Hcad's solution.

"A third-party service converted the design aspects of the application to the [Unisys] Linc [4GL] environment and created Linc models or specifications, which are used as input to Linc's code generator," said Parikh. "Things have gotten simpler with Linc and the imaging systems."

For some companies, deciding whether to rewrite or reengineer legacy applications is not a black and white issue. Faced with the challenge of migrating more than 14 mainframe-based programming languages to a Unix environment, Household Financial Corp. (HFC), Prospect Heights, Ill., decided it needed to start with a completely new development architecture.

According to Bob Elston, assistant vice president of applications systems and reengineering at HFC, IS groups develop systems the same way they did 25 years ago. In the development process, IS typically treats only the symptoms of the problem rather than getting to its roots, he said. Therefore, HFC chose to implement a new architecture that would ease migration efforts.

"We began by developing an Application Development Architecture [ADA] that transcended the operating system," said Elston. "Within the architecture we simplified the complexity of our applications by creating the Application Complement Engineering [ACE] model." He said the goal was to develop reusable pieces of code, which could be dynamically called via standard application programming interfaces (APIs).

"We use Compuware's Retrofit and Pathvu to restructure and to analyze the individual systems. We can then determine which parts of the system should be rewritten and which should be reengineered in order to embed the new technology," said Elston. HFC uses the VIA/Renaissance product from Viasoft Inc., Phoenix, Ariz., to identify functionality in large programs and pull it out to form a smaller, logical unit. "Using Renaissance this way is like unbaking the cake," said Elston.

He added that HFC reengineers an application only if it is needed and if it provides value to the user. HFC treats reengineering as an evolutionary process, which helps its programmers avoid the culture shock that typically accompanies new development approaches, he said.

Ensuring that developers can keep up with the new technology is critical to moving legacy applications over to a distributed platform. The first requirement is to satisfy the enterprise's business needs. Generally, the company's short-term needs are met when the system is installed on the new platform.

The long-term goal of supporting the newly distributed system is not so easily satisfied. Programmer support for the new technology is not automatic. Therefore, on the road to client/server processing, the mature organization will include in its travel plans the programmer that can support the new system.

COPYRIGHT 1994 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group