Mainframe Application Modernization
by Trevor Eddolls
February 22, 2010
** Read this article online at http://www.mainframezone.com/mainframe-soa-spotlight/mainframe-application-modernization1
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.
Also problematic is finding talented COBOL or Assembler programmers to maintain legacy applications.
For example, a Computerworld survey in 2006 found that 45 percent of respondents using COBOL said their ability to hire COBOL programmers was worse or much worse than their ability to hire programmers in Java, C++, or Visual Basic.
Similarly, in 2007 a survey by Micro Focus of its customers found that more than 75 percent of CIOs said they would need more COBOL programmers over the next five years, and 73 percent were already having a hard time finding trained COBOL professionals.
Back in 2004, Gartner estimated there were about 2 million COBOL programmers worldwide and that the number was declining at 5 percent annually. Dale Vecchio, research vice president of application development at Gartner, Inc., is quoted as saying, “COBOL will head downhill quickly over the next 10 years… as baby boomers retire and there is insufficient recharging of the population.”
Lack of support for Web interaction is perhaps the biggest reason for needing to modernize an application. Again, users expect to be able to sit at a laptop anywhere and access applications on the mainframe. If an application can’t support that, it’s too old-fashioned.
It’s also expensive to maintain old applications, no matter how strategic, if they’re not flexible. Each time maintenance occurs, the expense increases. Compounding the expense is the opportunity cost of not using limited resources to write or purchase new applications. Eventually, so much money will be spent on maintenance that a business decision will have to adopt new ways of working. Otherwise, the applications will continue to age, continue to suck in more maintenance money, and continue to increase the gap between the technology the application was designed for and current standards. Gartner estimates that between 60 and 80 percent of an average company’s IT budget is spent on maintaining existing mainframe systems and applications.
Modernization presents the chance to decide on an enterprise architecture that will help an organization make the best use of flexible, robust applications that users, customers, and business partners can access across the Internet.
Modernization Choices
The four choices for mainframe application modernization are upgrade, migrate, rewrite, and replace. Let’s take a look at each of these.
Upgrade is by far the simplest option and involves little in the way of change to the mainframe application. All that changes is that new technologies are integrated with the existing mainframe application. The benefits of this approach are that the application carries on performing its mission-critical work. There is little risk involved in this choice.
Migration usually involves moving a program’s source code or binary code from the mainframe to some other platform. New technologies are added using tools on the new platform. With this approach, application data could stay on the mainframe, or move to the new platform. There are several tools from different vendors that facilitate this sort of migration; there are tools designed to handle the conversion of COBOL and FORTRAN programs, and DB2-based applications. Unfortunately, migrations often yield poor-performing code on the new platforms or require extensive rewrites of the mainframe code. A migration project that results in application performance being slower isn’t going to attract much funding. If rewrites are required, this can introduce errors that didn’t exist in the original code. Another problem often associated with migration is scaling. Once the application has been migrated, it can often require detailed work to enable the application to scale on its new platform.
The rewrite option is often the hardest because the original application must be fully understood so a design plan can be created. In effect, the old application is reverse engineered (taken apart). Once the original application is fully understood, a new application can be written and produced using a modern programming language. New technologies can then be embedded in the new application or added to it once it has proved effective. The new application could run on the mainframe or a different platform. If it runs on a different platform, as with migration, the data may need to be moved to the new platform, too.
Moving data introduces its own difficulties. While the new application may be able to access data faster, any other mainframe-based applications will need to be modified to be able to access the data on its new platform.
The first alternative would be to leave the data on the mainframe and just move the application. The downside of this option is that it slows down the new application because it has to access data on the mainframe rather than locally—adding an extra step.
A second alternative is to have two copies of the data—one on the mainframe and one on the new platform. However, this solution comes with its own problems of maintaining synchronized data stores. The big question is, what happens if it fails? Should the project fail, the amount of money spent could seriously affect the company’s business success.
Replacing a strategic application is perhaps the riskiest strategy. It assumes nothing about platforms and business structures. It does allow competitors’ structures to be evaluated. It lets an organization start from the beginning in deciding what it wants an application to do and where it wants that application to run. A completely new application could be bought and made to do the job of the old application, or a new application could be written. Either way, the new application is built so it incorporates the new technologies, as well as performs the role(s) of the old application. The new application could run on the mainframe or on an alternative platform. This is the riskiest strategy because it can involve the application losing features that users have grown accustomed to, or ones that could impact the business’ success. Users are often resistant to change.
Making a Choice
So which option should you choose? Well, as always, it depends. A hidden advantage of migrating some applications off the mainframe is that more mainframe MIPS are then available for the remaining applications. This could lead to delaying a mainframe upgrade, and all the costs associated with it, for a year or more. It also lowers costs for per-usage licenses. IBM does offer sub-capacity, usage-based pricing.
Similarly, designing any new code to use specialty processors such as System z Application Assist Processor (zAAP), System z Integrated Information Processor (zIIP), or the Integrated Facility for Linux (IFL) can help reduce costs. Keeping applications off the mainframe central processors keeps CPU-based licensing for third-party applications from rising.
Questions remain concerning the Total Cost of Ownership (TCO) of mainframes, UNIX platforms, and Windows. Virtualization further muddies the water. So the final costs of migrating part or all of an application off the mainframe are far from clear.
The smart money seems to be on keeping the core of the applications on the mainframe and using Service- Oriented Architecture (SOA) to Web-enable those applications. Figures are quoted that more than 30 billion COBOL transactions occur each day (usually attributed to IBM), which is more than the generally accepted total number of Web page hits for the same period. Such figures seem accurate, but they are quoted repeatedly until someone challenges them, and then are revised, depending on the circumstances. Let’s just assume there’s a huge number of COBOL transactions each day and the bulk of them occur on a mainframe. These are the ones that can be modernized by being Web-enabled or rendered as Web services.
Web services are a way for the IT department to make existing mainframe- based applications available to anyone having access to the Internet and also to any other applications. This allows extra features to be added that can address security, regulatory compliance, personalization, and more.
One reason that’s often given for Web service-enabling mainframe applications is that organizations want to implement Enterprise Application Integration (EAI). Simply put, this is a way of allowing applications running on distributed platforms to access mainframe applications. The Web Services Description Language (WSDL), an XML-based protocol used to describe Web services and how to locate them, associated with the mainframe application, can easily be located by Java or .NET programs.
Both CICS and IMS—the giants of transaction processing systems on mainframes—can provide inbound and outbound support for Web services. The fact that mainframe transactions and data can be modernized using Web services makes a compelling case, both in terms of cost and effort, for not migrating the existing application to a different platform.
Project Stages
Any modernization project should go through five distinct stages. The first is to clearly define the project (i.e., what needs to be done). Step two is to define success. This means that everyone knows when the project is complete because goals have been clearly defined at the outset. Once you know what you’re trying to do and how you know when you’ve achieved it, you can move on to the third step, which is planning the project. This is a fairly standard project management task. Step four sounds so much simpler than it actually is—to carry out the project. The fifth and final step is to return to step one and start on the next project.
When working on a project like this, begin by considering the procedures people use. Next, look at the people who actually use the applications. Then look at the applications that run on the infrastructure. Finally, look at the infrastructure. After this kind of examination, it’s possible to produce a decision table showing the changes that are possible in terms of costs and risks. This makes it easier for decision-makers to choose what projects to pursue, including which applications to modernize.
There are numerous tools that can help with the modernization of mainframe applications and these are available from many different vendors.
Conclusion
Mainframe application modernization isn’t an easy project, but with pressure being put on organizations to comply with regulations and build flexible applications, it’s one that IT departments must accept. There are other choices, but Web-enabling applications and adopting SOA are a compelling strategy. Maybe starting from here isn’t so bad after all!
