Mainframe Application Modernization

by Trevor Eddolls
February 22, 2010

There’s an old joke about a man in a car who is lost in the countryside. After driving around for a while, the man sees a local, standing at the edge of a field. The man drives over, opens his car window and asks the local the best way to get to some nearby large town. At this point, the local shakes his head and says, “If you’re going to (and here he names the town, which is completely unimportant to the point of the story), I wouldn’t start from here!!”

Unfortunately, many organizations find themselves in that situation when it comes to modernizing mainframe applications. They know where they want to go, but not how to get there. And all the advice they’re getting is to not start from their current position!

Why Modernize?

Some of these applications have been performing core business work since perhaps the 1970s. If these COBOL programs (or whatever) have stood the test of time, why change them? What benefit will an organization get? In this difficult economy, conservative accountants will require a compelling business case to spend money on this kind of change.

Two major external pressures are driving the need to modernize a mainframe application:

1. Market pressures: Businesses need to be able to rapidly respond to any changes in the business environment or risk losing customers. Older applications may need updating to support that need.

2. Regulatory pressures: A need to comply with the Health Insurance Portability and Accountability Act (HIPAA) and Sarbanes-Oxley Act (SOX), among other regulations, is causing companies to consider software changes.

The first big problem is that legacy code has typically evolved a great deal over the decades. Legacy applications often have been “fixed” whenever things have gone wrong or hardware has been replaced. Minor upgrades have been “bolted on” to the original code. The result is probably a poorly documented piece of code that makes maintenance quite difficult.

A second problem can be the use of older technology with a particular application. As technology has advanced, numerous devices and standards have come and gone. New devices don’t always easily support old technology (consider Microsoft’s difficulties with Vista, for example); it can become error-prone, or too expensive to continue using. There may be some ancient device used only by this single application.

There’s also the problem of complex interrelationships and cross-application dependencies between one application and perhaps many others, which may not be obvious or properly documented.

Another problem is that many older applications are batch jobs originally designed to run in their own time and eventually produce results when they finished. This is no longer possible in a situation where application users require near-real-time responses. Another problem occurs if the application can’t run continuously. Typically, it was never designed for that and must stop while, perhaps, another application runs against the database. Users expect to be able to work anytime.