Danske Bank’s aims for ‘first-mover advantage’ in QA strategy

Henrik Hartvig Jensen, principal software engineer at Danske Bank in Copenhagen, Denmark
Henrik Hartvig Jensen, principal software engineer at Danske Bank in Copenhagen, Denmark

For close to 153 years, Danske Bank has been a key player in Scandinavia’s financial services space.

Headquartered in Copenhagen, it is the largest bank in Denmark and a major retail bank across a host of northern European markets with roughly 5 million retail customers.

Just like any other bank in Europe and most other key banking markets across the world, Danske Bank is rapidly embracing digital innovation, and 2024 was a key year for the financial institution in terms of maturing its software ecosystem.

As the application and systems landscape at Copenhagen-based Danske Bank is “highly dynamic”, as the bank put it, the competitive market drives a need to continually launch new services.

As a result, Danske Bank realised that, in order to shorten the development cycle and bring IT closer to the business, the bank adopted agile development processes, and turned to IBM in 2024 for a range of software testing tools.

Opening up about last year’s extensive digital undertaking, Henrik Hartvig Jensen, lead software engineer and technical architect at Danske Bank, said that: “we aim to achieve first-mover advantage, where this maximises our opportunity to gain market share.”

He added: “Some time ago, we launched the first mobile payment app in Denmark, and IBM testing tools helped us to achieve that. Quality remains important; in combination with time-to-market, a solid mainframe development environment with code coverage, unit testing, and test coverage is a critical element in software production at Danske Bank.”

Danske Bank currently runs its core banking and customer information systems on the IBM Z platform, using two IBM z16 mainframes, disclosed Hartvig Jensen’s colleague Henrik Sloth Schade, product owner for mainframe continuous integration/continuous delivery (CI/CD) and repositories at Danske Bank.

He noted: “IBM Z remains an extremely important platform for Danske Bank. As the world changes, we are always exploring new possibilities, but it’s an evolutionary process.”


“Code coverage, unit testing, and test coverage are critical elements in our software production.”

– Henrik Hartvig Jensen

Sloth Schade stressed that Danske Bank sought to make it easier for developers to create and test new software, and to automate unit testing both for IBM Z and for its other platforms.

Hartvig Jensen added that “our focus is on implementing additional guardrails to what we’ve already been doing, achieving the capability for end-to-end automation in our entire mainframe development pipeline.”

In its drive towards modernization, he stressed that Danske Bank has been working to bring the IBM Z development environment in line with Eclipse and .NET development environments running on other platforms.

The bank sought to encourage greater use of automation and better control across the full software lifecycle, he continued.

“Finally, Danske Bank needed to have better and faster insight into the performance and availability of its development environments, facilitating internal developers in working quickly, efficiently and productively,” Hartvig Jensen explained.

The project has produced some direct results, he continued, claiming that Danske Bank can now bring offerings to market in half the time it used to take.

“What’s great about ADFz and IBM Developer for z/OS is that almost everything we need to deliver software rapidly is in one interface,” Hartvig Jensen said.

Danske Bank’s HQ in Copenhagen, Denmark (Source: DB)

To better support Danske Bank’s relatively large community of internal developers – around 2700 at present – and to ensure a stable and reliable IBM Z development platform, Danske Bank turned to IBM Application Delivery Foundation solution.

“What’s great about these IBM solutions is that almost everything we need to deliver software rapidly is in one interface,” said Hartvig Jensen.

“We can handle the whole software lifecycle in a user-friendly environment that is quickly accessible to developers new to the platform.”

He stressed that “this promotes greater speed and efficiency, and helps bridge the gap between development for z/OS and for other platforms.”

Own internal testing tool

Danske Bank developed its own unit test tool, integrated into its IBM Developer environment, enabling a flow from development through test cases, unit testing, the addition of business logic, and finally the transition into production, Hartvig Jensen said.

“The whole analysis and debugging process is faster and more intuitive, with easy access to new tools that we developed,” he explained.

“Our internal ‘Application Diagnostic Systems’ tool uses the Fault Analyzer API to extract system dumps from the mainframe and open them directly in the IDE to see the current state and history of the program in production, check criticality and whether you can make changes, and add comments to flag any issues,” Hartvig Jensen elaborated.

Sloth Schade added in agreement that “we continue to work closely with the IBM labs, inspiring them to incorporate our homegrown functionality into their tools. It’s a great two-way relationship, and we appreciate the cooperation.”


“Testing in a separate environment before deployment helps our environment become more stable.”

– Henrik Sloth Schade

While core transactions and customer information reside on the IBM Z platform, front-end services often sit on other platforms, however.

By offering similar graphical environments to manage development and testing on both sides, Danske Bank is helping to reduce potential obstacles to collaboration, Sloth Schade pointed out.

“We have also migrated our COBOL and PL/1 code from old repositories,” he said. “This makes it easier to attract a new generation of developers to work with tried-and-trusted functionality without the culture shock of working on green screens! It’s all intuitive to use.”

Sloth Schade said the bank mainly uses the IBM tools to monitor the performance and availability of everything from the back-end CICS systems through to the development landscapes.

“Discovering dependencies makes it easier to stay compliant. Looking at the distributed space, we have many different CI/CD tools and over a thousand different pipelines and setups that may need to change in order to stay compliant, he said.

“Adopting one way of working may be restrictive in some ways, but it offers advantages in terms of compliance and control.”

Also, “we have very few outages in our development environment,” Jensen said.

“Performance and maturity have also improved. Some years ago, we set the target of moving from testing to production in under 25 minutes, and we have proved that we can do it in under 15! Developers need to be ready and know what to do,” he said.

Sloth Schade could not agree more. “Testing in a separate environment before deployment helps our environment become more stable going forward.”

He concluded by stressing that “we aim to ensure rapid ongoing delivery of high-quality applications and new functionality to meet emerging business needs.”


NEXT MONTH


DO NOT MISS


QA FINANCIAL FORUM LONDON 2024: RECAP

In September, QA Financial held the London conference of the QA Financial Forum, a global series of conference and networking meetings for software risk managers.

The agenda was designed to meet the needs of software testers working for banks and other financial firms working in regulated, complex markets.

Please check our special post-conference flipbook by clicking here.


READ MORE


Why not become a QA Financial subscriber? It’s entirely FREE

* Receive our weekly newsletter * Priority invitations to our Forum events *

REGISTER HERE TODAY