ING to consolidate payments platforms

Dutch bank moves from waterfall to agile- Tom van Kuipers, development engineer at ING, talks about how the shift improved delivery times and sped up development and testing, and why continuous deployment is still not possible in payments.

ING will be combining its payments systems applications onto one platform. Currently, the bank is running three different versions of the BASE24 (B24) payments application on HP Nonstop servers. B24 is an application for payments that was first developed by ACI Worldwide, a provider of electronic banking solutions, in the seventies. ING will consolidate its different versions of the B24 onto version 2.1 of the application on a Linux system. ACI Worldwide developed this version of B24 in cooperation with ING.

Tom van Kuipers, development engineer at ING’s card processing division, said that at the moment B24 11.1 forms the core of ING’s payments system, and that the bank is also running B24 Classic and B24 6.4, which were introduced to enable EMV (Europay, Mastercard, Visa) payments. He said that ultimately, the bank will consolidate its system so that everything runs on B24 11.1, and to then migrate to B24 2.1, first running on HP Nonstop, and then on a Linux system, in order to cut costs and move faster.

Implementing agile

The consolidations of ING’s payments platforms comes as part of a broader move from waterfall to agile, a process that van Kuipers said began four years ago as part of a small project, but that is now the firmly rooted in the bank’s development culture. The bank is seeing the fruits of what van Kuipers described as an at times “painful” transition. The engineer said that the move to agile shortened delivery times, improved team morale, shortened testing time, and made more efficient use of developer time.

The model used at ING is a modified version of Agile Scrum, called Tribes and Squads, which is similar to the way Google and Amazon work. The bank eliminated the role of scrum master and put all responsibility in the hands of product owners and squads. As part of the organisational change, squad members were given significant autonomy; testers were no longer responsible solely for testing and all personnel was expected to develop and learn new skills according to need. Testers learned to code and developers learned to test.

According to van Kuipers, the next step would be fully continuous deployment. This means that code is simply written, and then it is automatically tested and deployed into production at a push of a button. But the engineer warned that this is still not feasible in the payments: “The potential fall-out if something goes wrong is just too severe. We cannot take that risk.”

Testing payments

But while continuous deployments is still not realistic in payments, replacing legacy systems is a must. Jim Tomaney, managing director of Q-ATM, a payments consultancy said that banks want to change because they are coming under pressure in the payments space from competitors like Apple, who do not have to deal with the antiquated architecture and can move very rapidly.

Tomaney said that old versions of B24 are a significant obstacle to change: “A lot of the technology that underpins these systems is 25 years old, and they are written in a proprietary language on a proprietary platform.” The solution is to migrate to a newer system, like ING is doing, so that you can write, test, and deploy code quickly enough to keep up with the market.

The problem with that is that there is a lack of understanding of how these systems work, and that the existing documentation is fragmented. “After 25 years of incremental evolution, there is no one written definition of what the old platform does. People can explain it in words, but you don’t have a comprehensive description that includes the various fields and messages present in the system,” said Tomaney.

But testing can help. Implementing automated testing can capture the behavior of a system. A QA harness can then validate the behavior of the new system to make sure that it is working like the old one, explained Tomaney. Once that is in place it is possible to make changes quickly and to then automatically test them exhaustively.

The advantages of test automation are two-fold, said Tomaney. First, it allows for faster testing of the legacy system. The director of Q-ATM said that on one project he worked on in a Tier 1 bank, test automation brought a twelve month long development cycle down to three months. The second advantage is that the automated framework can be used to design and validate a replacement for the legacy system.

“Wise organisations automate testing around their existing systems and use that to model a migration strategy. They do not wait for something to go catastrophically wrong,” said Tomaney.

 

Tweet about this on TwitterEmail this to someoneShare on LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*