Why Throw Away Your Legacy?

Today's computer world is full of "paradigm shifts." Client/Server computing, object-oriented analysis, object-oriented programming and intranets just to name a few. From the technologist's perspective, these represent a big change in how systems are designed and implemented. The user, however, mostly sees additional training and support burdens from these paradigm shifts. This paper addresses one issue created by all these paradigm shifts: How can corporations best take advantage of the investment in existing systems?

While answering this question, the author will present a methodology for projecting these so called legacy systems into these new paradigms. The issues addressed include: When and how to use legacy systems on modern, GUI desktops; What can be accomplished through a legacy integration approach; When it makes sense to scrap legacy systems and rebuild from user requirements' definitions?

The Webster's Internet Dictionary defines legacy as: "A gift by will especially of money or other personal property." The Princeton Internet Computer Dictionary defines legacy as: "Old software still in use but which could benefit from re-engineering using more modern methods." It seems that the computer industry does not see how systems built with older technologies have value in today's world.

In what sense are many of today's systems legacies? If the system's architecture is not current by trade press standards, it not always a legacy by Computer Dictionary standards. It may in fact be a very effective system, a real legacy. Is it sensible to scrap a perfectly useful system just to change the look and feel? Is it reasonable to spend tens or hundreds of millions of dollars to recreate a perfectly functional system just because it does not fit into today's whim?

We can easily trace how valuable application software became today's computer industry legacy. Cost saving was the original justification for client/server computing. After the pioneering client/server applications entered service, several analyses showed that per seat costs were twice as high as the per seat costs for the applications they replaced. This was the result of higher support costs for distributed computing environments coupled with the complexity of client/server application environments. The client/server industry quickly looked around and latched on to "business process re-engineering" to justify these new, higher costs.

At the same time, mainframe computing prices continued to fall. Newer generations of mainframes provided much more power at lower cost. The tightly controlled environmental conditioning mainframes require is now more relaxed with newer, power-efficient technologies. Also, large computer suppliers aggressively added connectivity features that integrate mainframes into the distributed computing world. The result is a resurgence in mainframe sales.

Meanwhile, after a decade of client/server computing, several questions now have generally agreed upon answers. Early client/server applications used character based interfaces. These provided marginal usage advantages over mainframe terminal screens. The explosion of graphical user interfaces (GUIs) onto desktops changed the user interface standard for computing. GUIs provide several features that make them easier to use: better and more manageable presentation; context sensitive help; easy-to-edit input fields; and "pick lists" of valid values. At the same time, these environments provide constantly improving inter-application communications and data transfer abilities. It is now possible to move not just a piece of data between applications but to embed an active piece of one application in another, i.e. a spreadsheet in a word processor document.

The original proponents of client/server computing also believed that the processing database would be the users' inquiry database. Experience shows this is not a good idea. A classic client/server relational database, especially one optimized for insert and update, is almost never a good database for query. Efficiently updated relational databases are highly normalized with few indices. Efficiently queried relational databases are partially denormalized to avoid common joins and have many indices. At best, a mirror of the transaction database with additional indices could serve as the query database. More often, the query database uses an on-line analytic processing (OLAP) product and data extractions update a database with a radically different design and structure.

Splitting off OLAP from OLTP presents an architectural quandary for application developers, be they corporate information technology organizations or application package suppliers. If a mainframe, terminal based, application effectively does its job, processing transactions, how do we gain basic client/server benefits such as GUI screens, desktop application integration and OLAP databases most easily and cost effectively with the least risk?

Since our concern is not with OLAP databases, we can leave them to experts who construct data warehouses. While both the terms OLAP and data warehouse are new, extracting data and moving it to multi-dimensional databases is not new. This is a well-understood problem with many packaged and custom solutions.

Our main concern here is examining three alternatives: completely replacing old applications with new ones, using either packages or custom-built software; building new software from the old using "legacy code encapsulation"; or continuing to use the mainframe application but converting terminal screens to real GUI screens. Cost, speed and risk are the main differences between each approach.

Of course, the business process re-engineering folks will jump in now and point out that the old applications are often too inflexible. Most of the problems with old applications come from input screens requiring expert data entry people and the inability to integrate data from different applications. This locks business processes into the applications' organizational assumptions. Also, work flow is defined by the ordering of fields on the screens. Once the application is available in a GUI environment, these problems disappear. Another basic problem is incompatible codes or names for important things such as customers, products or accounts. This disappears when management has the will to attack difficult people problems or old habits.

A story illustrates this. A former colleague now consults in data warehousing. His client had a problem with tying sales to specific reporting periods. Over the years, the company culture provided managers with flexibility when specifying sales performance measurement periods. This led to coding dates not as calendar dates but relative to some internal company date structure. Different managers at different times used the period structure that best showed their performance. Senior management knew about this problem but organizational pressure stymied them. The computer people responsible for this area stayed out of the fray by claiming they knew of no technical way to translate the company's date structure to actual calendar dates. Of course, they could be translated and my former colleague developed an algorithm to figure out the Julian date for the transaction. Eliminating this date problem caused the biggest reason for re-engineering the OLTP application to disappear.

Replacing existing, working applications with new applications whether customer built or packaged is hard. Most experts agree that application design expertise is in critically short supply. Most application design and development methodologies fall short in the area of gathering users' requirements. Learning and adopting new technologies is hard. Most of the critical client/server technology components are relatively new and mostly untested for large, mission-critical applications. The published experience confirms how difficult client/server computing really is.

The press is full of stories about this. The canceled air traffic control system; Department of Defense systems that are years behind schedule and two or three times over budget; the new reservation system that put Greyhound back in Chapter 11; and California Department of Motor Vehicles fiasco, to name just four. All of these examples involved outside consultants as well as internal staff. Why risk these results rebuilding a perfectly functioning system that only needs a Windows interface? Packaged solutions such as R/3 have better track records but still are chronically late and over budget. Besides, a large company can spend several hundred million dollars just implementing a package.

Legacy code encapsulation at first glance is better. A tool provides an object packaging layer for the existing code so that the basic processing components are integrated with new data stores and new user interfaces. Seems like a good idea. Unfortunately this technique requires learning, much of it in difficult object-oriented programming and inter-process communications. Someone still needs to write new data access and storage code and design and develop new user interfaces. This is a time consuming and costly path.

The third alternative, replacing the terminal screens with GUI screens, looks attractive at this point. However, there are a few pitfalls to avoid. Many GUI screen packages that work with existing mainframe applications require coding. In the worst of all possible worlds, the GUI package requires changes to the mainframe code. This introduces difficulty, cost and complexity that may make replacing the application seem attractive. The second alternative does not require mainframe code but requires code to build the GUI. This is more attractive than changing the mainframe but as long as application developers and maintainers need to learn a new language and new coding techniques, why not just use legacy code encapsulation?

The standard for a good GUI front end package must be no coding. No coding on the mainframe. No coding on the desktop. Two alternatives exist for building the GUI without code. One method requires the developer to look at the terminal screen, create fields to match those on the terminal and then build a map between the fields. This is a time consuming and difficult task for a large application. Ideally, the GUI screen product will read the mainframe terminal screen information and automatically generate the GUI fields. The developer then only needs to hide those annoying constant display fields, replace entry fields with list boxes where desired, add help, and then the GUI screens are ready. This process should also require minimal training and not require learning or understanding event-driven GUI design and development. These features and compatibility with a wide number of connectivity packages is the ideal in a product for this purpose.

So we now get back to our opening question, Why throw away a legacy? You do not have to. Just as everyone believes in renovating old houses by replacing plumbing, heating systems, kitchens, bathrooms and windows, why not just renovate your valuable legacy applications. No one would destroy a structurally sound building just because new building technologies now exist. Why throw away sound legacy applications just for new Windows?

©2003 ResQNet.com
All rights reserved. Contents herein may not be reproduced in whole or in part without written permission of publisher.
ResQNet.com. 33 Maiden Lane 8th Floor, New York, NY 10038 212-482-8080 Ext. 4816