Where next for the mainframe, part 3 - which way to go?

There are several strategies a company that relies on mainframes today can adopt – from the permissive to the aggressive.

We've looked at the history of the mainframe and its use in modern business, as well as the drivers for change that might cause companies to re-evaluate their use. But what are the alternative strategies for your mainframe, and which is the right one for you?

The answer depends on a myriad of factors. Many organisations are likely to pursue a blend of strategies depending on the characteristics of each mainframe application in question - and bearing in mind that there is still a role for mainframe applications alongside cloud solutions.

Fundamental to this decision is to consider the strategy for your mainframe-based systems, in the context of your business goals and outcomes. Every business is different, and the direction you choose should be based on the right solution for you, as well as the expectations of your customers - not what the software, hardware or service provider tells you other companies are doing.

There are several strategies a company that relies on mainframes today can adopt - from the permissive to the aggressive.

Do nothing…

Taking no action and maintaining the status quo is certainly one option, especially for companies with no immediate requirement for new functionality. There are many banks, insurance companies and airlines that still rely on their mainframes and continue to see them as a strategic part of their IT environment.

Whilst this might sound an attractive and low risk option, for this to be viable it is vital that you fully understand how to extend and increase the value you get from your legacy applications. You must also ensure you put measures in place to ensure your legacy doesn't end up constraining the evolution of your business services in response to customer demand. This technical debt can easily outweigh any cost savings that result from keeping your mainframe.

Business agility is key - the curve of client disappointment is what drives business today. If retention of the mainframe results in a stagnation of business change then your customers will be disappointed and go to the competition. So, the challenge is for businesses to find a way to provide customer agility built on a legacy backend platform in order to be able to be more agile, make and deliver change faster and appear modern - the ‘digital veneer'.

Migrate (or re-host)

This approach involves the redeployment of selected applications to a new hardware environment - including cloud and open environments. The program's source or binary code is moved to another platform with little or no change, other than the infrastructure configuration of the application. New tools and technologies can be deployed in the new environment to improve the application. Technologies are available to help with migration; for example, you can recompile the code to run in a mainframe emulator hosted in a cloud instance.

This option provides many of the benefits of a re-write (see below) but with reduced cost and reduced risk. It can be a sensible first step to a subsequent, less complicated and therefore less risky source code re-write.

Re-generate (or re-factor)

This option involves reverse-engineering and then regenerating the application from the design model on a new platform. It involves modifying the existing code; in some cases, tooling is available to help reverse-engineer well-understood applications for the new platforms.

However, the number of lines of code will be huge and they will have been originally designed to fit a requirement that then evolved over time. The result is no longer strategic, and the code generally incorporates far more functionality than is now necessary. To simplify things, you need to look at what the business needs the code to do today (as opposed to what it does do) and remove everything unnecessary. Whilst reverse-engineering provides a partial solution, the downside is you get what the code does now on a new platform - not necessarily changed to reflect how the business requires it to work today.

Re-write (or replace)

The most aggressive legacy modernisation option is to discard the existing application and embark on the re-development of an entirely new one, replacing mainframe functionality with equivalent features in the new platform. The chosen solution may be a full re-write of a business process in terms of a new application or, more likely, will incorporate software as a service (SaaS) where the applications support enterprise functions (i.e. finance, HR, resource planning). It may also use SaaS where industry-specific applications are available to solve problems that custom mainframe solutions previously addressed.

To be effective this requires a detailed analysis of the current business operations and processes, to ensure the new applications and services are fully aligned to the business's current needs. However, this brings its own risks - developing the business logic increases the opportunity for errors and will require extensive testing to deliver a robust and business-aligned solution.

A full re-write can be prohibitively expensive. If you did choose to go down this route, you would only do it to the applications supporting critical business processes, or perhaps functions that are in a constant state of change, and look to using SaaS as the basis for the new applications and services.

Bi-modal IT

Not really a strategic option or solution, but a tactical approach that is complementary to some of the options described above, bimodal is worth considering as part of the wider assessment of options.

Assuming you decide to migrate from the mainframe today, any migration programme will take time. In the meantime, you need to ensure that the mainframe applications continue to support the business effectively. Therefore, some organisations look at a bimodal IT strategy to solve this problem; some even consider it as part of their long-term strategy. Under a bimodal strategy, the business operates what are effectively two IT organisations: one focused on the legacy way of working and one pursuing the new.

While executing a bimodal strategy may help an organisation manage key systems while developing and adopting new, more efficient systems and techniques, it can be complex and costly. The strategy can result in two IT camps competing for limited resources, yet at the same time needing to collaborate closely.

Bimodal works best as a short-term strategy; it is not something you would want to operate in the longer-term. In any case it is critical to transform the legacy environment (as opposed to adapting your methodologies to it), to ensure your organisation continues to meet the requirements of the business and competitive demands of the market. It also means you still must consider how to exploit the mainframe during the transformation period.

Commercial considerations

You should also consider the commercial aspect of any migration. Even if you retain your mainframe for a period of time, consider how you can reduce the impact of the costs; for example, consider the move to a flexible ‘on-demand' based model, so you can dial-up and dial-down both service and software costs to make it more affordable; look into the availability of third parties who specialise in mainframe services as they may be able to provide support for certain aspects of your mainframe operations more cost-effectively.

The next and final article in this series will examine how to bring it all together: your existing IT environment, your business goals, your desired outcomes and the best way for you to get there.

Created by Elisabeth Ash who is the customer journey manager at New World Tech (NWT)