IBA Group Modernizes Mainframe Application for German Bank

A leading German bank had a problem.

They provided a wide range of financial services to individual, corporate, and institutional clients, as well as to the public sector. They specialized in a wide range of fields, and had grown over the decades to become a leader in their country and field.

Unfortunately, their legacy IT infrastructure’s limitations were catching up to them.

One of their key Mainframe applications was behind the times and nearly impossible to update quickly or easily. They were losing customers and market share, and they needed a solution — fast.

In this two part case study, we will delve into their challenges and explore how collaborating with IBA Group’s mainframe teams helped solve them, resulting in significant benefits.

In part one, we will explore:

• What improvements their key Mainframe application required and why
• What bottlenecks they encountered when they tried to work on this application
• Why their overburdened internal IT teams could not fix these problems alone
• What they looked for in a partner and why they chose IBA Group

A Leading German Bank Struggled to Update Their Key Application

The bank’s Credit Department operated a legacy OS/2 banking application on their Mainframe. They used this application to capture and store information about clients, loans, loan guarantees, credit scores, mortgages, and other mission critical data.

This application was central to the bank’s operational activities, and their Credit Department was looking to extend it. They wanted to improve its functionality and add new features to expand their client base, provide a wider range of loans, and accelerate and digitize new loan evaluations and approvals.

Yet when they tried to develop their application further, they ran into significant barriers. They quickly realized that their application:

• Could not adapt to their rapidly changing business environment. It was inflexible, and took a long time to implement new features, change business rules in the system, or even deploy minor changes to its operations.

• Could not integrate fully into the rest of their business environment due to the complexity of their Mainframe, putting the application data and functionality into a silo.

• Took too long to perform basic functions. Customers who made a loan inquiry had to wait two or three days to get any response from the bank, leading to increasing customer dissatisfaction and loss.

• Created a significant burden on internal IT. None of the application’s processes were fully automated, which meant IT had to perform a lot of manual work to get anything done — causing delays, errors, and development bottlenecks.

The bank’s Credit Department and IT teams knew they needed to solve these issues before they could expand their application’s functionality and improve its performance. However, once they began to attempt to untangle these knots, they realized their issues were more fundamental than they thought — and that they could not resolve them on their own.

The Problems Were Too Big for the Bank’s Internal IT Teams

The bank’s internal IT teams were talented, hardworking, and they wanted to help the Credit Department fix and extend their Mainframe application. Yet, they were not able to complete this project on their own due to a few bigger problems in their business, their infrastructure, and their legacy processes.

Specifically, the bank’s internal IT teams encountered four fundamental issues that prevented them from fixing this application on their own.

First, they were already overwhelmed with routine requests.

They promised the Credit Department — in good faith — that they would fix the application’s problems within one year and deliver the requested features. Yet they had limited capacity and often found themselves in conflicts of interest. They were constantly flooded by other change requests from across the bank’s org chart. These change requests were often prioritized — at the corporate level — above the application’s.

Second, they lacked the necessary skills.

The bank’s IT teams consisted of experienced, proven professionals who were good at their jobs. However, fixing and extending this application required rare skills that were not popular in the world of IT, such as the COBOL programming language. In addition, their skilled developers, who could contribute to this project, were already busy with their daily tasks and had no time for new development, in-depth analysis of the application’s issues, and exploration of new problem solving strategies.

Third, they were stuck in old approaches.

Like many internal IT teams — and especially Mainframe teams — they were locked into old school ways of doing things, in particular the legacy Waterfall approach to application development. This approach became a bottleneck for innovation and prevented them from evolving the application fast enough to meet the changing demands of their constantly shifting business requirements.

Finally, their Mainframe itself was a complex patchwork.

Like many banks, they had developed the Mainframe, its architecture, and its applications in an ad hoc manner over many years. As a result, in order to make any changes to their application they had to navigate a complex patchwork of different solutions. These included:

• Standard IBM technology stack

• Multiple programming languages including PL/I and COBOL

• VSAM and recently added DB2 databases

• IBM MQ as a primary messaging exchanger

• TWS (formerly OPC) as a scheduler

• CICS for transactioning

• And complex custom workflows (i.e. business applications built on CICS and PL/I, including conversational transactions written in a specially developed procedure language that automatically generated source code in COBOL)

In sum: IT was overloaded and understaffed, and their Mainframe was both complicated from an engineering perspective and had multiple technical blockages that prevented it from meeting a full range of business requirements.

Some members of the bank’s internal IT only saw one solution to this problem. They wanted to get rid of their Mainframe entirely and reengineer their systems from scratch using modern technologies.

The Credit Department’s business leaders vetoed this proposal. They had used their Mainframe for decades and appreciated its performance and security.

The business leaders won this debate. The bank decided to keep their Mainframe, but knew they needed to take a new, modernized approach to managing it and developing its applications faster and more efficiently.

They knew they could not do it alone.

Searching for a Solution: How the Bank Partnered with IBA

The clock was ticking. The longer the bank left their Mainframe application as is the more regular customers they lost to competitors, the harder it became to attract new customers, and the lower their market share dropped.

They began to look for an external partner that could reengineer their Credit Department’s application to improve its performance and extend its feature set, modernize their Mainframe as a whole, and relieve the burden on internal IT teams.

To start, they documented what any potential partner needed to help them deliver.

In the short term, they needed to serve their business better, develop quick solutions to complex problems, deliver rapid ROI, offer seamless service improvement to their internal users and customers, and minimize risks during the transition.

In the long term, over the next few years, they needed to reengineer their existing applications, maintain their existing business logic, and integrate their host applications with their remote applications.

The whole time they needed ongoing support from teams that could take care of their business’ daily requests and support tickets, as well as to modify their Mainframe applications and build APIs so users could access them via web UI.

With these requirements defined, the bank began their search, and quickly found IBA Group, a large IT service provider with a specialty in modernizing Mainframes.

The bank was drawn to IBA Group for their Mainframe open source initiatives, which involved the development of DevOps tools in partnership with Zowe, and their showcase of diverse Mainframe modernization solutions at the annual SHARE conference. In addition, the bank was impressed by IBA’s proprietary Appulse platform, which offered automated support for business applications operating on z/OS.

To get to know IBA Group, the bank had a series of screen, compliance, and discovery sessions with the future partner.

During these sessions, IBA Group helped the bank identify their core problems and proposed an optimal solution. IBA’s 30+ years of broad experience in Mainframe, along with their specific emphasis on system and application development, as well as expertise in modifying and migrating Mainframe systems to modern platforms, quickly became apparent to the bank.

The bank selected IBA as their partner, and got to work.

What Happened Next

By partnering with IBA, the bank was able to modernize their application and their entire Mainframe system, develop new features and capabilities, unload the support burden off their internal IT teams, and deliver measurable ROI including:

• Increasing the number of loans issued each day by 140%

• Accelerating loan approvals from 3-4 banking days to just a few seconds

• Reducing the time to onboard a new employee by 3 times

For more details on how the bank and IBA achieved these outcomes, check out part two of our case study.

If you are interested in learning more about how IBA can help you address your Mainframe challenges and attain similar outcomes, reach out to us now for a free consultation.

During our chat, our experts will discuss the current state of your Mainframe, brainstorm opportunities to improve its performance, and walk you through what a partnership between your organization and our teams might look like.