Software Quarterly

Legacy Applications: Do They
Really Need a Fountain of Youth?





You have to face facts.

Just about everybody wants to be hip. Just about everybody wants to be part of the "in" crowd.

And, in information technology (IT), just about everybody wants to be on the leading edge.

But sometimes, even a sure thing can go the way of the 5.25-inch floppy. And, since technology is only going to increase its already rapid pace, IT professionals are left frantically trying to decide which comet's tail to grab.

The possibilities are clear: get ahead ... or get left behind. Unfortunately, knowing how to achieve the former while avoiding the latter is anything but clear.

Nowhere is this dilemma more apparent than in the world of mainframe computing.

End users want the hottest applications. The chief executive wants to save money. The chief information officer wants the latest systems.

And IT management is supposed to deliver all of the above. But how?

If you look at the news coverage and commentary in most computer industry publications -- where the latest trends and hottest technologies are always touted as the best solution -- the answer is simple: Toss out all the old code and build new systems, preferably based on the client/server model.




It's Never That Simple

According to the Gartner Group of Stamford, CT, it's not that simple. In a study titled "Building the Next Generation of Legacy Systems," Gartner explores the possibility of completely replacing the corporate world's inventory of legacy applications. Its strategic planning assumptions include 1.5 million developers -- dedicated, full time -- to replacing the estimated 150 billion lines of COBOL source code estimated to be in use worldwide.

The results were astounding. "Assuming the conservative 60 percent maintenance rule," the Gartner report says, "the expected application replacement target becomes 62.5 years."

Clearly, tossing out the old code and replacing it with all new code is not only impractical, it's impossible.

"What people need to realize is that new doesn't have to mean different," says Ron Langer, a COBOL technical specialist with IBM. "In many cases, you can do more to improve the computing environment by leveraging existing applications, rather than starting from scratch. The key is properly assessing the situation."

There are two important measures, or yardsticks, to apply when evaluating an application's overall value. They are the relative competitive advantage and the relative quality of the application, compared with alternatives. While there is much room for variation within these measures, there are essentially four ways to view a legacy application. Also, there are four ways of dealing with an application based on the results of this evaluation.



Legacy Applications Quality/Competitive Advantage Matrix


In many instances, where both measurements are low, as in quadrant A, the application has outlived its usefulness and probably should be discarded or replaced. On the other hand, in cases where both measurements are high, as in quadrant C, the clear message is that the application should be left alone -- it's doing its job. While you'll want to continue to update and improve an application that falls into this area, it pays to remember the adage: If it's not broken, don't fix it.

Decisions about what action to take can become far more difficult when one of the elements is low while the other is high, as in quadrants B and D. These "gray" areas force IT professionals to weigh the benefits of a potential replacement against the time, effort, and cost required. Rather than a complete overhaul, it may be that applications that fall into these areas can be improved, if modified or migrated to a client/server environment.

Perhaps the best way to illustrate these alternatives is to describe them in terms of specific user examples -- involving real companies that have implemented real solutions.




Out With the Old...

In many cases, the applications with the greatest impact on both quality and competitive advantage are those that have the greatest impact on personal productivity. And no one feels the pressure to improve productivity more than application developers. IT professionals are working against an application development backlog of months, or even several years. All too often, by the time an application is finally delivered, its usefulness and its purpose are completely outdated.

Labruyere Distribution in Macon, France, was trying to do something about that.

Labruyere was the region's first independent distributor of petroleum products, selling to large industries, gas stations, and nearly 50,000 residential and commercial customers. In such a competitive field, the company knew that improved service would be enough to survive -- but reduced costs would be the key to success.

As part of its strategy, Labruyere decided to reengineer more than 300 CICS applications. The challenge was to find an application development environment that could perform the task quickly and efficiently. Labruyere officials decided to move the development department away from the mainframe altogether and use production workstations running VisualGen as the development platform of choice.

"Our programmers can now work on developing applications entirely on individual workstations with testing and debugging facilities," says Pierre Valette, Labruyere's data processing director. "They generate and compile code that runs on the server system and the mainframe, so developers don't support bad host response time during peak periods, and they don't increase load charge when they are developing and testing."

By moving application development activities to a platform that best supports them, Labruyere was able to quickly and successfully re-engineer its applications. As a result, the company realized substantial savings in central processing unit (CPU) usage and temporary file storage. VisualGen generates COBOL programs, and, after the programs were compiled and running under CICS, CPU consumption was reduced by 47 percent, input/output by 68 percent, and end-user response time improved by 50 percent. Labruyere is now planning to develop new client/server applications with VisualGen.




Tried and True

One of the hardest things for any organizations to do is accept the need for change. But change is essential. At least, that's what they think at U S WEST, one of the largest regional "Baby Bell" telecommunications companies in the United States.

U S WEST handles phone calls in a 14-state area in the northwestern part of the United States. Their mission is supported by an IT organization running over 40 million lines of COBOL on each of 60 MVS images. The dilemma was how to get their system to accept dates beyond January 1, 2000.

On that date, most "legacy" applications will suddenly think the new year will be "older" than the previous year. Why? Because in many applications the date field corresponds to the surface this issue doesn't seem like a big deal, the implications are enormous. For example, on January 1, 2000, payments due on bills from the previous month (December, 1999) could suddenly appear to be 1000 years overdue!

For many IT professionals, the only solution seemed to be a rewrite of every affected application routine calculating dates, sorting data, and managing data to accept four-digit years, as well as a complete rebuild of their databases with four-digit years. Needless to say, such an effort would be a tremendous undertaking for most organizations making the attempt.

U S WEST, however, has migrated from VS COBOL II to IBM COBOL 370. As part of the upgrade, the company received Language Environment (LE/370) callable services, including a date/time service routine that interprets a two-digit year into a four-digit year -- designed specifically to accommodate the year 2000.

Using the functionality provided by LE/370, U S WEST programmers estimate they will save about 2,000 programming hours compared to the rewrites they initially expected to do without callable date services.




If You Can't Beat 'Em

Sometimes, even the best intentions aren't enough. As functional as mainframe applications may be, if they can't maintain a competitive edge, they aren't doing the job. Barnett Banks, the largest bank in Florida, knew that holding on to market share meant meeting market demands -- for the best service anytime and anywhere someone wanted to bank. And that meant making changes.

While Barnett needed to maintain control of operations from a central location, branch operations needed a way to gain independence. That independence would eliminate the need to rely on host connections during the business day, a situation that delayed transaction times as well as customer service -- especially if the connection went down.

Using OS/2 LAN Server to migrate its systems to a client/server environment, the bank found the solution it was looking for. The re-engineering effort established a distributed systems management environment that gives the central office remote control over changes, configurations, performance, and problem management.

At the same time, branch offices gain enough autonomy to maintain control of, and availability of, their own data. At Barnett Banks, faster, more reliable access to information has led to improved productivity, better customer service, and an ever larger market share.




What Does it All Mean?

Perhaps the most important thing to note is that of all four options -- replace, leave alone, modify, or migrate -- none of them completely separates itself from the host. Even when Labruyere moved application development completely off the mainframe, developers were still directing efforts to manipulate existing data -- but they were just doing it in new ways.

Essentially, what users are witnessing is an evolution of the corporate information model. The result is a new breed of applications -- a hybrid combination of the legacy and contemporary application worlds. These hybrids, in turn, are fueling a much-needed move toward industry standards, providing faster and more efficient ways to move information throughout the enterprise.

The bottom line is that investments made in what are today "legacy" environments were valid when they were made and, in many cases, those investments are still paying off. The key is to implement a strategy that supports more flexible, rapidly changing business processes in a way that leverages an organization's environment to the fullest. And that strategy most likely will include a combination of all four options.


See also:
Breaking Up is Hard to Do
Tomorrow's Just a Day Away...


[SQ][tell SQ] [get SQ] ["software"]

[ IBM home page | Order | Search | Contact IBM | Help | (C) | (TM) ]