opinion: What Is Mainframe Modernisation, And Should We Care?

I often chat with clients and other consultants about mainframe modernisation. These discussions go in many different ways, and discuss different things. One persom may talk about new features like Zowe; another focused on rehosting on a non-mainframe server. Others may talk up Java or RESTful APIs, while vendors get excited about new products and services. But what do we really mean when we talk about mainframe modernisation? Let's take a closer look.

Modernisation In a Nutshell

Let's start with some definitions from a Google search:

...updating all or some of your IT stack to better support your business goals and processes

... takes that legacy system and converts, rewrites, and ports the existing applications to a new language that utilizes different libraries, hosting platforms, and protocols.

So, it seems that mainframe modernisation is the replacement of mainframes or existing mainframe software with something else.

... the process of migrating or improving an enterprise's existing legacy mainframe footprint in the areas of interface, code, cost, performance and maintainability.

This seems more general, and adds improvement to replacement in the list of possible options.

The reality is that there are many points of view, and indeed definitions of mainframe modernisation.. So, let's add our own to the debate:

Mainframe modernisation is the use of new technologies, assets and resources to solve problems with legacy mainframe applications and systems.

If you accept this definition, then mainframe modernisation isn't anything new. For example, in 1983 MVS/XA introduced 31-bit addressing so programs could use more memory. Sites then changed their code to use this 31-bit addressing. Modernisation.

But many exclude mainframe innovations from their definition of mainframe modernisation. Instead, it's a replacement of that old (obsolete) technology with something new and fresh. Like replacing that old 1970s kitchen with a brand new one.

Let's take a step back. Why would we want to modernise our mainframe?

Reasons to Modernise

Let's summarise the main reasons for mainframe modernisation:

• Cost - mainframes are expensive. Micro Focus advertise potential cost savings of 80-90% from rehosting. That has to get your attention.
• Staff - the issue of finding staff who can continue to support legacy applications and systems is not new. In a 2020 survey by Deloitte, 71% believed their mainframe team to be understaffed.
• Innovation - in a 2019 survey by LzLabs, 69% said that the inflexibility of the mainframe limited their ability to innovate. Many see mainframe changes as too difficult, slow or expensive.

What's interesting is that there are some things that are not on the list. For example, performance, capacity, security or reliability. So, the mainframe isn't that bad.

Should We Care?

But how important is mainframe modernisation? Is it a fad, or an essential step for organisations with legacy systems?

A TCS/AWS survey in 2021 reported that 70% of CxOs saw mainframe or legacy modernisation as a strategic business priority for the next three years. Similar results were reported by the Advanced 2020 Mainframe Modernisation Business Barometer report: 60% of businesses planned to start a modernisation project in the next year.

So, mainframe modernisation is very much on everyone's mind. And it makes sense. Mainframes, together with their code and data are a critical resource worth a lot of money. You can understand why everyone wants to keep it relevant.

Easy Modernisation Options

We don't have to boil the ocean to modernise the mainframe. Let's look at some options that aren't too difficult.

• IDE. Integrated Testing Environments (IDEs) and other software development tools can reduce development time. Features include code editors that highlight errors as you code, code analysis, and easier code compilation and deployment. Some examples include Compuware ISPW, IBM Developer for System z (IDz) and Zowe Explorer. However, many mainframe programmers today still use nothing more than ISPF.
• z/OSMF - IBM have identified z/OS Management Facility (z/OSMF) as a key tool in z/OS systems administration. The idea is that new administrators won't need the same depth of knowledge to support z/OS.
• Web enablement - 3270 'screen scrapers' have been used for years to convert traditional 3270 screens to web pages: leveraging legacy applications for web solutions. More recent features include z/OS Connect, and JSON functionality for Enterprise COBOL. Using these features can help expose legacy applications and data as web solutions.
• Zowe CLI - The open source Zowe projects offers various features, including a command line interface (CLI) that can be used from Windows, Linux and MacOS. This CLI opens to the door to using more 'comfortable' tools with mainframe resources. For example, GitHub for source code and Jenkins for automation. Some vendors are using Zowe CLI as an easy-to-use gateway to their z/OS based products.
• Zowe Desktop - Zowe also offers a desktop environment that is similar to Windows. This can be used to create z/OS-resident 'Windows' applications and RESTful APIs.
• zCX - z/OS Container Extensions allows Docker-packaged Linux applications to run on z/OS.
• Python and Node.JS - programming languages familiar to many non-mainframe developers, they're now available on z/OS.

Bigger Options

The above solutions aren't seen by many as 'real' mainframe modernisation. They're thinking bigger. So, what's bigger?

• Code Replacement: many sites are considering rewriting legacy code, but leaving it on the mainframe. They see COBOL as too hard, and redeveloping in Java gives them access to a larger talent pool. And they have a point. Development in Java has the option of creating platform agnostic code that could be ported to other environments. We talk more about this in our partner article.
• Application Replacement: another option is to go a step further, and simply replace the application with something off the mainframe. This may be an existing software product, a totally new application, or a combination of these.
• Application Rehosting: vendors such as LzLabs and Micro Focus offer solutions to move existing mainframe applications to a non-mainframe environment with few, if any, changes.

The Mainframe Modernisation Decision

There are no shortage of software and solutions to 'modernise' your mainframe. However, the fact is that the mainframe is doing a job, and in most cases, doing it well. Modernisation should not be done just because it's essential. Limitations with the existing mainframe applications and systems need to be identified first. Or in other words, don't find a solution, and then search the mainframe for a matching problem.

Once problems are identified, solutions can be reviewed to find the best one. This could be anything from rehosting, to simply doing nothing and living with the problem.

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.