opinion: Commitment Issues, And How They Risk Your Legacy Applications

In many sites, I've seen legacy mainframe applications that in a state of limbo. They're important, they're running well. But the future is uncertain: will they continue to run, or will they be retired or replaced? I believe that this uncertainty is one of the biggest risks to these applications.

Legacy Applications

Mainframe sites have legacy applications: applications that have been around for ages. They're important, they're needed, and they run fine. Some of these are critical applications: required for the organization to continue operating. Often, they're a central point working with many other applications: on and off the mainframe. But it's no surprise that these applications are in danger. They're on the mainframe, so are seen to be obsolete, difficult to change or enhance, and expensive. And maybe they are. But as they're identified as such, they're a target to be retired or replaced.

The Applications We Want to Keep

Here's a basic fact: application software doesn't support itself. Any application needs someone to look after it. There will always be problems, issues, or changes just to keep it operational. For example, programs may not work with the latest version of z/OS or CICS. Or there's an abend in the program that must be fixed. Or perhaps the program is running too slow.

If we're keeping this application for some time, then it will likely need to keep up with the times. More Java, JSON and other potential clients may need to use their features or data. We'll need new reporting, probably in an easy-to-read online format. Their performance will need to be up to scratch, and there's a good chance that the amount of work that they do will increase over time.

Business changes will also be needed. As our organization moves into China, we may need to store Chinese character sets in our databases. Or we may need to move to a 24/7 operating environment as clients around the world need to use it.

We need someone to keep our legacy applications operating, relevant, and reliable. And not just day-to-day. Smart sites will be looking at code complexity and maintainability, and looking for ways to make supporting hundreds of thousands of lines of legacy code easier.

As current mainframe staff retire, we need someone to replace them. To do this, we need to lure quality talent into this space.

Sunset Support

If the sun is setting on our application, the problems don't go away. We still need to keep the application running until the very last day.

If you're an application programmer working on an application that is likely to be retired, then you'd be smart to start looking for a new job before the axe drops. So, our support staff are in danger. I've seen sites that have applications with almost no support staff, as they've all left or retired. It will be hard to find new staff to work on a retiring application, assuming you can find budget and headcount.

Any changes to the retiring application will be resisted: why change the application if it's ending soon? So, if it doesn't work with the latest version of CICS, then we'll keep an older version of CICS running for this one application. Or if a new application needs to work with it, we'll tell that new application that it must wait for whatever is replacing it. Or if there are a couple of abends a day, we'll live with them, hoping that they're not doing too much damage.

Even changes that could save money or provide a business advantage will be resisted. Got a change to reduce CPU? Can't do it. Need the application to run later in the evening for extended opening hours? Can't do it. Need the application to run faster as workloads are increasing? Can't do it.

The moment we decide that an application is ending, even if that end-date is a couple of years away, we're really accepting that new development will stop, and support may very well dwindle away.

The Cost of Inaction

I've seen many sites where there's been talk of retiring the application, but no specific plans. In many ways this is a dangerous as announcing the retirement of an application. People will start assuming that the application will be retired 'sometime soon', and the sunset issues start.

I've seen sites where discussions on the retirement of an application have been ongoing for 15 years. In fact, as a consultant I've heard of many plans to move applications off the mainframe, only to be stalled, paused or canned.

I believe that all sites should have a statement of direction for all mainframe applications. For example: "Application X will remain on the mainframe for the next 10 years." Or "Application Y will move off the mainframe in 2 years."

Once made, we need management support and action to support these statements. If announcing that an application will be moved off the mainframe in two years, then there should already be a project with budget to do this. There should be a supporting study justifying the timeline, and it should be done.

Similarly, if the application should remain for 10 years, then it should do exactly that. This needs to be accompanied by a suitable budget that not only supports current functionality, but allows for development of new features or functions.

Conclusion

Anyone maintaining legacy applications will need to have short-term and long-term plans. Short-term plans to keep it operational in, well, the short term. And long-term plans to keep it relevant in, you guessed it, the long-term.

Sites reluctant to commit to the long-term will pay the price. Reduced support resilience, usability and more.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.