• Armin M. Warda, FSI EMEA Chief Technologist at Red Hat


• 13.04.2022 04:45 pm
#risk #banking

For all the benefits of cloud computing, banking and traditional finance companies still rely heavily on mainframes. But change is coming. It is inevitable. 

Applications running on mainframes are finding it harder and harder to compete in the digital economy. Cloud-native fintechs and neo banks are taking market share, powered by the faster innovation cycles and lower costs that cloud provides. Mainframe makers have seen what’s coming, and are refocusing on cloud platforms. 

But this is a misleading narrative. Application modernisation is not necessarily an issue of mainframes versus cloud. Many banks still value mainframes for their reliability, and intend to keep using them. Rather, this is about the legacy applications running on them, which are characterised by monolithic architectures, proprietary standards and protocols, and older programming languages that are not helping to attract the next generation of talent. In other words, modernising applications does not needto mean migrating from mainframes. So how does a bank decide the best approach for them?

Ambiguity is OK

It can be tempting to analyse this question in binary terms. At one end, the radicalists, who only see the cost and dwindling talent pool associated with their mainframes and want to rip them out as soon as possible. On the other end, the conservatives, who are not ready to potentially compromise the track record for high security, availability and transaction throughput of their mainframes, especially for core applications.  

A more credible characterisation of big banks and financial institutions is of organisations looking for technological efficiencies and wanting to compete for the best talent, but are wary of the risks of moving too far, too fast; while also wanting to run down the full value of their investments in current systems and skills rather than writing them off. 

That presents far more ambiguity; and the bigger the business, the more ambiguity there is. What makes sense for one organisation will not be right for another. Big banks and financial businesses will want to define their own modernisation plans and schedules; and for those to flex to changing situations and unpredictability. In other words, they want technology that caters for ambiguity, rather than punishes it.  

5 ways to modernise an application 

Broadly, there are five ways for an organisation to modernise an application running on a mainframe. These can include maintaining the mainframe, or migrating from it (fully or partially) to either a hybrid or full cloud deployment.

1. Replacement - retire the application, and start from scratch with a new one, requiring implementation, customisation and adoption. (Though transformational at an organisational level, this is not strictly modernisation as you are ‘killing’ the application. That said, there will usually need to be a period of co-existence while data is migrated to the new application and until integrations, customisations and adoption are completed.)
2. Emulation / Rehost - move the application to a less expensive deployment platform, with little or no impact on the application’s performance, typically as a temporary measure before retiring it. (Again, this is not truly ‘modernisation’.)
3. Translation - rewrite the application code, either automatically (fast but with the risk of inaccuracies) or manually (more accurate, but slower.) This option helps remove legacy programming languages that come with expensive compilers and runtime environments and for which it is difficult to find skilled staff. Instead, applications can be translated to modern languages that use common (open source) compilers and runtime environments, and for which skills are in more abundance. For greater future flexibility, rewrite the code for a cloud-native environment so that the app can run anywhere: in a public cloud, in a private cloud, on servers or on the mainframe.
4. Refactor - redesign selected elements of the application to use containers and microservices, while leaving other elements untouched.
5. Rearchitect / Rebuild - redesign the whole application. 

In reality, with banks running hundreds of different applications, a mix of these options is likely to be needed. What’s more, with all these options (but especially 3 and 4), elements of the same application will run concurrently on different mainframes or different environments. And with application modernisation taking time, each will need to be maintained and managed on an ongoing basis. 

Overcoming complexity

All this can bring complexity. When applications are running entirely on a mainframe, there is just one underlying infrastructure to worry about. But as soon as you introduce other deployment models for applications, and start dividing individual applications into constituent parts and running them in different places, chaos can ensue. Any economic or productivity benefits you hope to achieve in the long run will be nullified if you can’t orchestrate this complexity in the short-term. 

For a long time, it has been this challenge, as much as any other, that has held back big banks and institutions from modernising their applications. But that is all changing with enterprise Kubernetes platforms such as Red Hat OpenShift and the partners that wield its capabilities for their banking and FSI clients. This partnership of technology and expertise is giving banks and institutions the control to modernise on their terms, at their pace. 

OpenShift provides the DevOps toolkit to efficiently modernise an application, or build a new one from scratch. It is environment agnostic, meaning applications and their component parts can be distributed across multiple deployment models, and easily moved between them. This not only enables choice today, but future flexibility. Should an application modernisation project be stumbling, it can be paused or pulled back to the mainframe, without that work having been in vain. In the same way, an application can be shifted between clouds — private and public — mitigating the risk of vendor lock in. 

The urgency for banks and financial institutions to modernise their applications has never been higher. The choice of how to do it has never been greater. The risks have never been lower. OpenShift makes it possible that radicalists, conservatives, and everyone in between can win.