Legacy Applications: Do They
Really Need a Fountain of Youth?
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.
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.
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.
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.
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.
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.
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...