Mainframes: powerful, reliable, but soon to be obsolete
Insurance companies have relied on mainframes for decades. These large-scale computers are regarded as reliable and powerful. Nevertheless, more and more insurers are considering replacing them. Why is that, exactly? Why is modernisation such a complex undertaking? And could artificial intelligence help with this? Dr Artur Strasser, Vice President of Insurance at Materna, has been addressing the technological challenges facing the insurance industry for more than ten years. In this interview, he explains why mainframe modernisation is now becoming urgent and how insurers can renew their legacy IT landscapes.
‘Mainframe’ sounds a bit like computers from a bygone era. What exactly is it?
Dr Artur Strasser: Mainframes are particularly powerful and reliable large-scale computers that have been supporting core business processes at many insurers for decades, such as policy administration, portfolio management, and claims processing. The applications running on them often incorporate business logic that has evolved over decades. This business logic maps out specialist rules, such as how premiums are calculated, policies are processed or claims are assessed. Mainframes therefore remain an important part of the IT landscape for many insurers to this day. It is not necessarily the technology itself that is outdated. The challenge often lies instead in the applications that have evolved over decades.
If the systems work so reliably, why do insurers want to replace them at all?
Strasser: Because running them is becoming increasingly expensive and specialist knowledge is being lost. The managing director of an insurance company recently told me that, in more than 20 years at the helm of the company, he had never signed a contract as expensive as the one for his mainframe applications. Many of these applications are programmed in COBOL. The specialists who developed and maintained them are retiring, and there is a shortage of young talent. At the same time, the documentation is often incomplete. As a result, making changes and integrating new technologies is becoming increasingly complex, even though the systems continue to function reliably.
But surely it should come as no surprise that developers will eventually retire and the technology will become outdated. Why haven’t insurers taken action sooner?
Strasser: Insurers have been grappling with mainframe modernisation for a long time. However, from a financial perspective, replacing the systems has often been difficult to justify. Imagine an insurer replacing a functioning COBOL system with a new Java application at a cost of many millions of euros. Initially, this would do exactly the same as the old system. That capital would then not be available for investments that enable growth or improve the customer experience.
As long as the systems ran reliably and the costs were manageable, continuing to operate them was therefore a sensible decision. Today, the picture is different: rising operating costs, dwindling specialist knowledge and new technical requirements are increasing the pressure to modernise.
And what happens to the actual computer? Does modernisation always require new hardware?
Strasser: Modernisation does not automatically mean replacing the hardware. Our focus is on the software: we modernise applications, update interfaces and ensure that existing mainframe systems integrate more effectively with modern IT environments. In the case of a complete mainframe replacement, we migrate applications and data to other platforms and resolve any remaining technical dependencies.
You’ve mentioned COBOL several times now. Couldn’t these old programmes simply be automatically translated into a modern programming language? That would solve the problem, wouldn’t it?
Strasser: Automatic translation is possible, but it doesn’t solve all the problems. COBOL programmes can be translated into modern programming languages using specialised tools and, increasingly, AI. However, these programmes have evolved over decades. They contain numerous rules and exceptions, the original purpose of which is often no longer known to anyone today. With a simple translation, we largely retain this complex logic. If, on the other hand, we want to simplify the application and make it easier to maintain, we must first understand why it works the way it does.
Changing the programming language alone does not solve the problems. What matters most is the structure of the application, its dependencies and its long-term maintainability.
It’s as if someone were always driving from Dortmund to Duisburg via Herne because they once negotiated a fuel discount there. If a successor or an AI knows nothing about this discount, it will choose the shorter route via Bochum. Is that a fair comparison?
Strasser: The successor recognises the detour but does not know its purpose. It’s similar with legacy applications: some parts of the programme map out special provisions for older insurance policies that are still required. In a pure translation, this logic must be preserved. We have to test whether the new application delivers the same business results. If, on the other hand, we simplify the application, we could inadvertently remove important rules. That is why we need to understand the business rationale behind the programme code. And perhaps the petrol station discount no longer exists. In that case, the detour is indeed superfluous. But we need to find that out first.
That sounds like a massive detective job. Do you have to go through every old programme line by line to do this?
Strasser: For large insurers, that would hardly be practical. This is where AI-supported analysis tools can help to examine existing programmes, identify dependencies and reveal previously undocumented business rules. AI can help us understand the processes and rules reflected in the code. We need to clarify with the subject matter experts why a rule was introduced and whether it’s still needed. Technical review and quality assurance therefore remain essential, even though AI can significantly speed up modernisation.
Suppose an insurance company wants to modernise its mainframes and approaches Materna for help. What happens next?
Strasser: We begin by taking stock: what applications are in place, how are they linked, and what business rules and data flows underpin them? At the same time, we clarify the insurer’s objectives and identify where the greatest risks lie. Based on this, we jointly develop a target vision for the future IT architecture and determine which applications to modernise and in what order.
In doing so, we draw on our experience with complex IT landscapes, AI-supported analyses and specialist technology partners. If preliminary studies or a target vision already exist, we assess them for feasibility and build on them. It is crucial to have a strategy that aligns with the insurer’s business requirements and financial capabilities.
At some point, however, the old system will have to be taken offline and the new one brought online. Isn’t that rather risky?
Strasser: That’s why we usually take a step-by-step approach. For example, we start with an application that has few interfaces and can be migrated with manageable risk. Together with a technology partner, we transfer the business logic to a new system and check whether it reliably performs the same tasks. To do this, both applications can run in parallel for a time. Only once the business results are correct, the data and interfaces have been checked, and reliable operation is ensured do we switch off the old application.
With every successful migration, confidence in the next one grows. Sometimes, however, it also makes sense to prioritise particularly critical applications. The key is a bespoke strategy that limits risks and safeguards ongoing insurance operations.
This is likely to take years. How much longer will insurers have to deal with their old mainframes?
Strasser: Many insurers I speak to are now pursuing a clear Agenda 2030. Similar modernisation plans did exist in the past. My discussions also reveal that some earlier projects remained unfinished. Today, the economic pressure is significantly greater. At the same time, AI-supported tools make it easier to analyse existing applications and their business logic. The use of AI can provide further impetus to make data and applications more accessible. However, replacing the mainframe is not strictly necessary for this.
I am therefore optimistic that many insurers will be able to make significant progress with modernisation by 2030. Clear priorities, a good understanding of system dependencies and a step-by-step approach are crucial. Not everything needs to be updated all at once. What is important is that the individual steps lead to a viable overall picture.
Download: White paper on mainframe modernisation
We have summarised the key information on the topic of mainframe modernisation in a white paper.
Click here to download …
