Building a Cutting-Edge Banking IT Function

ING Bank is aggressively overhauling its IT function, aiming to deliver step changes in the function’s efficiency, quality of output, and attractiveness as an employer. The company’s CIO, Ron van Kemenade, recently spoke with BCG senior partner Hanno Ketterer about the effort’s genesis, the technologies and methodologies employed, and the challenges to date. Edited excerpts of the discussion follow.

ING Bank is undertaking a massive technology transformation, which you’ve termed “Power IT.” What spurred you to initiate that transformation?

In 2013, we came to the conclusion that any separate initiatives we might undertake to improve our quality, cost, and engineering capabilities might indeed lead to substantial impact. But more likely, they would suffer from lack of consistency, funding, support, and commitment. We also determined that we needed to take significant steps to support the bank’s “Think Forward” strategy. This is why we created the Power IT program.

We launched the program with three overarching aims. First, we wanted to create a best-in-class IT organization relative to our peers, one that would make us the preferred employer of IT talent in the Netherlands. Second, we wanted to substantially improve our quality. Third, we wanted to drive down our costs. At the time of the launch, we were far from where we wanted to be on those fronts. We were not the most preferred IT employer in the market, so we basically struggled to hire highly skilled engineers. Our quality, measured in time to market, also fell short—we were not agile enough. And our costs were well above our benchmarks.

Many European banks have launched initiatives designed to reduce costs. How did you convince ING’s board to support such a comprehensive program, one that also entails investing in talent and new technologies?

The “how” question is not easy to answer. But let me explain a bit of the reasoning behind the program’s design. There are costs associated with everything you do, whether that’s buying an expensive machine, hiring an internal engineer, or doing things a particular way. There are also associated benefits. Our goal was not simply to drive down costs but rather to ensure that the money we do spend delivers maximum value. We could always reduce costs by, say, sourcing more work to India. But that would not address the fact that our engineers are not as productive as we need them to be. We could also cut costs by outsourcing our data centers or squeezing out the very last dollar from our suppliers. But these steps would not address the underlying causes of our inefficiency. They also wouldn’t make us a better place to work. Neither would they reduce the complexity of our landscape or improve our processes.

Ultimately, we determined that the root causes of our costs were the complexity of our technology stack, the degree of automation of our processes, and the productivity (read: knowledge and skills) of our engineers. We knew, though, that addressing these root causes would also deliver substantial related benefits. Our quality would improve, as would our attractiveness as an employer. If you have a simplified technology stack, fully automated processes, and an agile way of working—and if new hires get to work with highly skilled peers—your company becomes an attractive place to work.

So we actually took the root causes of cost and made them the purpose of our program, since they go hand in hand. If you increase quality, you reduce cost. If you automate and make your processes more agile, you avoid waste and become more efficient. If you hire highly skilled engineers, you become more productive.

ING’s transformation has involved the use of cutting-edge technologies and approaches, such as using private clouds, switching to APIs, and implementing  ¹ 1 “API” stands for application program interface. “DevOps” is the practice of having development and operations engineers work together throughout the entire life cycle of an application. Notes: 1 “API” stands for application program interface. “DevOps” is the practice of having development and operations engineers work together throughout the entire life cycle of an application. Can you elaborate on some of these and explain why you think that they can take ING’s IT to the next level?

We’ve made some bold choices. We could have decided to consolidate on just one platform and make sure that it’s virtualized, which would have given us the benefit of optimized hardware. Or we could have stayed with our SOA-based architecture but not immediately expose functionality through the use of APIs.² 2 “SOA” stands for service-oriented architecture. Notes: 2 “SOA” stands for service-oriented architecture. Or we could have maintained our current architecture for the various channels and not build for Web scale. But we decided that since we were investing a lot in the simplification of our landscape and the consolidation of data centers, platforms, operating systems, and middleware—and since we were looking at a three- or four-year journey anyway—we should do all of the above: build a new digital platform that was cloud-based and API-based, and Web scale at the same time. Obviously, this added complexity, as well as risk, to the program. But we believed that we could handle it and wanted to deliver to the business the benefits of a modern Web-scale stack as soon as we could.

Have there been specific tools, approaches, or methodologies that have helped you to achieve that end state, and which you would recommend to other CIOs undertaking similar journeys?

Moving toward this state has taken a combination of skills, methodologies, and sometimes technologies. Consider, for example, the decommissioning of the mainframe, which is probably the best example I can think of and a critical enabler of us realizing our ambition. Decommissioning is something that basically everybody in the market would like to do, though I don’t know of many companies, including ING, that have fully realized it to date. To decommission the mainframe, you need a fully functional roadmap. This is not easy to create, and it certainly wasn’t for us, given that we had a significant number of business applications residing on our mainframe. For every single functional component, you need to have an alternative platform: if there is no target, there is no migration strategy. And off-loading a mainframe means migrating all of the functionality and interfaces. So you need to have your best people, those with knowledge of the entire organization, allocated to building these functional roadmaps, creating migration targets, and making sure that those targets are on the roadmaps of the business.

A second necessary element for successful decommissioning is rigorous program management. You need to break down the task into stages, with specific targets assigned to each stage. Everyone needs to know that in, say, stage three, which might take place in the second half of the year, the goal is to functionally migrate a specific number of applications.

A third key element is the use of the right supporting technologies where necessary. In our case, we have chosen to accelerate the decommissioning of our mainframe by using a rehosting environment that allows COBOL code residing on a mainframe to run in a container technology. The use of this technology allowed us to avoid fully refactoring applications when there was no target platform available to migrate to.

We have combined these three elements—roadmapping, rigorous program management, and use of supporting technologies—and hope that they will do the trick. These elements have proved equally valuable to us in realizing other milestones on our journey.

Let’s move from technology to people. Using Spotify as inspiration, ING has also embarked on a large transformation effort to bring an agile way of working to both the IT organization and the business. What was the motivation for that?

The ultimate goal of creating an agile environment is to increase responsiveness to customers. Agile can certainly be useful for cost reduction and for creating a better process, one in which engineers feel more at home. But in the end, you do it for your customers, whether they are external or internal users. Those customers’ needs and desires change regularly and quickly in response to a range of factors, including new trends, new regulatory requirements, and changes in other industries. And customers demand that you respond. Our old way of working did not facilitate the necessary responsiveness. So we began to embrace agile methodologies in 2010, applying “scrum” practices to our development process. Those first baby steps involved just three teams. In 2011, we rolled out agile across all of development. But we found that working in an agile way solely in development didn’t really make much of a difference. IT operations needed to be included as well, since that’s basically where the buck stops before you go into production. So we applied agile to operations, too, and formed our first DevOps teams.

We also involved our business colleagues, since we considered their involvement critical for realizing the full benefits that agile can deliver, given the focus on the customer. The business had the opportunity to lead teams, decide on priorities and backlogs, provide short-cycle feedback, and interact on a frequent basis—often daily—with the engineers.

The business recognized and appreciated the benefits of agile but was not organized optimally to take full advantage of what it could deliver. The business then took it upon itself to reorganize in ways that broke down silos and fostered the necessary end-to-end ownership and accountability. Making this transition—using Spotify and its “squad”-based, feature-team approach as a model—proved highly challenging for our business colleagues, especially culturally. But I tip my hat to them. They had the guts to do it. And the benefit to the company as a whole has been sizable, as the bank is now unique in the Netherlands compared with a lot of other financial-services players.

The Power IT transformation has been underway for roughly 21 months now. Based on what you’ve learned so far, what advice would you give a CIO who plans a similar transformation?

The biggest lesson we’ve learned so far is that getting the necessary alignment within the company can be challenging; in our case, it proved far more difficult than we expected. Teams’ priorities would change in response to the near-term, day-to-day demands of the job, with the result that sometimes projects necessary to push the transformation forward—a decommissioning of something or a platform change—would disappear from, or get pushed lower down on, teams’ backlogs and hence not get done on time. In response to this, we made the switch from having the effort led by a program team, an approach that only facilitated line management, to more centrally driven program management. Now, in the event that there are disputes about teams’ priorities, our group of CIOs, together with our business colleagues, make the final call. We expect that Power IT will unfold on schedule as a result of this adjustment.

But this was a huge lesson for us. We had assumed that alignment would occur naturally because teams would view things from an enterprise-wide perspective rather than solely through the lens of their own team. But we’ve learned that this only happens in a mature organization, which we’re still in the process of becoming.