How to modernize the mainframe in a fast-changing banking industry
At Fiducia & Gad IT AG, our job is to keep IT systems up to date for all 1,100 cooperative banks in Germany. It’s a bit of a straddling act—between old and new, established and innovative, the past and the future.
On one hand, our customers face changing regulations and competition from new types of banks entering the market. Keeping up means we are constantly moving forward—deploying new applications, improving the customer experience and rapidly extending new functionality to online and mobile channels.
On the other hand, we must maintain our customers’ core banking systems with around-the-clock availability and impeccable security. These COBOL-based systems have been around for decades and are still essential to bank operations.
The gap between these two worlds is widening as COBOL programmers are retiring, replaced by a new generation of developers. Thus, we decided to build a bridge—one that will keep the two worlds in synch, even as the banks evolve.
Simplifying layers of complexity
We’ve always maintained a multi-tier hybrid architecture to connect front-end, distributed systems with backend IBM z/OS platforms, using IBM’s Information Management System (IMS) software. This allows us to build new Java-based applications that can access data and transactions from core banking systems.
However, this architecture can get pretty complex, with a whole layer of compensation logic needed to mediate transactions. This complexity slows us down as we deploy new applications and services to market.
Our challenge was to simplify the architecture. We needed modern, reusable software components with portability across both distributed and z/OS environments, but we also wanted to protect our investment in existing business logic.
A groundbreaking approach to mainframe modernization
The solution was to bring Java into the IMS production environments. We worked with IBM to create a common runtime environment within IMS, making Java and COBOL interoperable. In fact, we were the first company in the world doing this and we produce about 180,000,000 IMS transactions a day. Now this technology is available to everyone.
We now have a simpler architecture, with tighter integration between core banking systems and new, distributed applications. This gives us more flexibility and makes development easier, so we can help our customers take innovative services to market faster, from the web and mobile apps to ATMs and beyond.
At some point, our front-end developers won’t even know if they are calling Java services or IMS transactions because everything will be accessed in one consistent way. Today, more than 80 percent of our total workload is Java-enabled. A Java-enabled IMS transaction may call Java programs running in the IMS Java JVM. This way IMS transactions can use the huge number of Java standard libraries and third-party software products. It also allows us to code new business logic used in the IMS transaction in Java instead of Cobol and to migrate Cobol programs to Java.
It’s a gradual process, and we’ll ultimately reach 95 percent of the total workload being Java-enabled.
This mix of Java and COBOL in the IMS environment is a good way to modernize the core applications on the mainframe step by step. We’re bridging the gap between old and new, helping our customers use their existing investments to enable what’s next in banking.