Interview: DevOps in financial services with Rouke de Jong

Heidi (00:04):

Hi, there. It's Heidi Aho here. I write for Eficode and host the podcast that you, my friend, are now listening to. Welcome to DevOps Sauna, Europe's DevOps podcast. And guess what? This is the last episode of the season. It's episode six, and for this one, we are heading to the place where it all began, or at least where Wi-Fi was invented, that's a new one, the Netherlands.

Heidi (00:30):

I visited our Amsterdam office to meet with Rouke de Jong, one of our Senior DevOps consultants there. May you be lured in by his dulcet tones just as I was, as he talks about the difference between DevOps in practice in the finance industry and in retail, and his vision of why successful DevOps adoption takes a mixture of psychology, sociology, and technology. Take it away, Rouke.

Rouke (00:55):

Good day, you all. I'm Rouke de Jong, a Senior DevOps Consultant at Eficode since April this year. Previously my career started as a part-time network administrator in the eastern part of the country. Got pulled in just by my interest in computers. And at the time I was studying mechanical engineering, and discovered that the difference between mechanical engineering and IT engineering, is that in mechanical engineering, 30% of your context is defined by material that you use and there's only so much you can do with steel. Whilst compared to IT, almost 100% is in your hands. It's flexible. You can use it. So, that pulled me in.

Rouke (01:45):

And well, it went from bad to worse. And after three years of running as a Network Admin and setting up a European network, I was kind of done and got pulled into the leading online retailer in the Netherlands, called bol.com, for an operational role. In the first week the release manager had me deploy applications manually, which, I don't know, kind of irritated me. So in the first weekend I threw together some quick scripting, made a deployment platform because at that time there wasn't really a product on the market. So after the first weekend, the release manager could just deploy everything by himself and only needed us when things went wrong.

Rouke (02:38):

After about three years of automating myself away that way, I got pulled into the development side of things and teamed up with a specific developer called, Chris, who was setting up CI services using Jenkins at that time, a whole new world for me. And together we built up and set up CI pipelines, CD pipelines, using my still active operational credentials to propagate releases, et cetera.

Rouke (03:11):

After doing that for a year and a half and on the development side of things, I took my experience and went over to a company called Spil Games and I started experimenting with that to see what the different adoption strategies would be, Big Bang or evolutionary, do you capture the current process first, or do you want to introduce some new steps or a new approach. And eventually set up a development environment where basically you could go from incidence on production to building batches, checking everything, releasing it to production in a cycle of about three minutes and that was fun to do.

Rouke (03:56):

Using that knowledge I had a bit of a product that day and first went with my own company, doing consultancy services, discovered that acquisition is seriously not my thing and administration is not my passion either. So I moved over to a medic services company and tried to build up a product line there. Got about half way and then got interested funnily enough in Eficode, because they already had something like that. That shows to me a significant matureness in seeing how the market is moving you as a company influence your own demographics and got pulled in into this Finnish company.

Rouke (04:50):

From Eficode out I got landed at ABB, ABN and AMRO, the Dutch company, the Dutch Bank. And I've been working there now for about three months and helping them along to do a DevOps transformation, specifically in a grid, which is loosely based on the Spotify model. And the grid means there's about five teams. Well, they wanted to adjust their way of working, their approach towards software delivery, software development in such a way that they can actually speed it up, get more transparency, and again, all the benefits from working in a DevOps way.

Rouke (05:38):

As it is a bank, some basic patterns in DevOps are not really handy to apply. Regulatory restrictions are there. For example, the European Bank kind of explicitly describes that you have to use GitHub. And GitHub in itself is, or in my opinion at least an antipattern compared to DevOps' way of working. Those restrictions push people in a sort of mindset. And that mindset, well, in a way I approached DevOps is basically it's psychology, how do people themselves see their current reality, the way of working, their approach towards software development and operations, sociology, how do they work together towards that particular common goal, and technology, how can we capture that corporative style, that collaborative style in technology, make it transparent, make it clear at what people are doing and why?

Rouke (06:48):

I mean, the human side of things should be augmented. Don't use people as process. Use people as the person, as the individual that's there. If you're going to apply a human being in a certain role and for a certain change, I want to see something shiny, because that's why you get a person in there, that additional unique value. If you use the unique skills and capabilities for an expected outcome, I don't know, it grinds against the grain. It's wrong in my opinion. If I use a master craftsman and I ask him to make me 250 Ikea tables a day, he's just kind of point me towards Ikea. But if I asked him to make a one-off unique cupboard or cabinet or something like that, yes, then I get the unique skill applied for unique results, something unique, perfect, shiny, et cetera. And that's what I want to achieve, to augment in the human side that special capability of a person to augment that and actually make it shine, make it transparent, make it usable in that way and not use people as processes.

Rouke (08:10):

In a bank you do have, as I said, the different restrictions. That means that you have to have all the training. It's common sense you would say. Well, as the Agile Manifesto says people, documentation, et cetera, there is a very strict baseline in what you have to log, what you have to be able to share to the auditors, what kind of processes you have to follow. It is a way of working that implies several anti-patterns like they want to centralize responsibilities, they want to centralize tooling distributions and stuff like that, which kills the distributed. The level optimization effect that you can have if you actually do that in a transparent way kind of prevents holistic awareness in teams and people and a collaborative framework between different teams, et cetera.

Rouke (09:22):

And in that way you got work with the limits that are there. GitHub workflow for example, it forces people to work in several sprints at the same time. Your current one is in development, the previous one is in testing phase. The one before that is in acceptance. And the one before that is in production. And it can all have feedback that you have to pay attention to.

Rouke (09:53):

So it's not just your current sprint, the current feature development that you're working on. You got to keep those auto runs in mind too. I would love to be able to, I don't know, at least get rid of one environment and then in that way reduce the workload, increase the amount of focus you can have on your current sprint. That's part of the culture shift that we're try to do enable and get going in these kinds of institutions.

Rouke (10:23):

But as I said, there's several other factors in play like the European Bank, the Dutch National Bank. They all have expectations in how you as a bank handle your chain flow, how you handle your operational flow. So this creates a specific culture that compared to, for example, online retail is in my experience amazing. The way working, it enables you to do, well, it forces you to find elegant solutions within the sometimes severe restrictions that are applied. And getting that mindset going, the antipattern, I don't know, centralizing responsibilities instead of distributing them, the need for transparency and still secrecy that is prevalent in the banking culture, it is a very challenging and very interesting environment to work with.

Rouke (11:29):

The mindset of culture it comes again back to the psychology, sociology, and technology troika that you have to use to come to a workable solution that works for the person, for the individual, that works for the group or also for the bank, and uses approved technology, that uses baseline and audits of all steps in your software publication flows.

Rouke (11:56):

They use, and they are still seeking for the perfect solution sometimes. You have issue tracking services in JIRA. You have issue tracking services as your DevOps. You have a service and a green environment is doing your operational stuff and getting, for example, that admin layer connected into a virtual one and everybody can use it's a challenge in itself.

Rouke (12:21):

Everybody has their own needs. The one environment is admins that serve them. Green, for example, is used for stuff. Whilst the developers say like, "Ah, I love the issue tracking capabilities of as your DevOps with my CI systems, with my CD in there." In the meantime, the business says, "No, I've used to JIRA. So I'm going to make all my user stories in JIRA. And you as a development team have to use JIRA." And that way it forces me to do, to take a step back, see, and what's needed in the essence, not what kind of process do we follow right now, but in the end what's needed.

Rouke (13:03):

Where should retention be? Shall I book task results to certain agreeing or is then off if it still lives in the user DevOps environment, and just link it for example. Those are questions that from a logical standpoint can easily be solved. But still the expectation's from the people and the institution itself.

Rouke (13:27):

It is an interactive learning process that we'll both go through. In the end, the challenge is already mindset and culture. I mean, you have teams that get great responsibilities, especially in the movement towards more DevOps way of working. Okay, you're responsible for your feature creation, for checking it, testing it, getting acceptance testing done, deploying it in production, running it in production, et cetera.

Rouke (13:59):

But the other side of the coin, the great powers that come with it, that's a different process because then regulatory factors come into play. External institutions like the European Bank are steering you towards solutions sometimes that can be counterproductive, don't fit the needed solution or ... There's a constant discussion going on there.

Rouke (14:26):

The technological design, like I said, the centralization of responsibilities and technology. We have third party teams providing technological services, which turn out to be very inflexible. The teams wanted to adjust their tech stack, for example, make it event driven. Suddenly they discovered that their outside world is still running a batch based process. So they want to shift to eventing. It makes no sense because their sources are still running batches. So why would you do event-based business logic processing, for example? It makes no sense.

Rouke (15:15):

And in that way, sometimes teams within the bank are running ahead of current regulatory items, sometimes they lag behind and calling on to it. And sometimes there's a healthy discussion with the regulatory institutions to make sure that you still have the baseline of security aspects, quality aspects availability while still maintaining that audit check box. You have to be able to audit everything. The history needs to be there. It all comes back to developers. Like don't squash your commits on a pull request. It's simple things like that.

Rouke (15:59):

And in that way, it gives you a very perhaps contradictory dynamic environment where you can actually apply very elegant solutions. You wouldn't expect that in a bank, but in the end it is possible. In a bank compared to retail it is a little more waterfally as you got more of a yearly planning, it's a bit more strict. It is not as day to day madness as online retail can be. For example, when Michael Jackson died, it went mental. I mean, all ... everybody in the company was focused on fulfilling the demands, getting as much merchandise out as possible.

Rouke (16:43):

What's in the bank? You don't have that. You don't have that kind of interactivity. You do have products that are highly available in the market. You've got products, payment services that need to be available 24/7. So you've got a different demand there, which results in, I don't know. In a way they want the dynamics of an online retailer basically with the predictability of the slow propagation process of a bank. Those two are hard to match with each other.

Rouke (17:24):

The volatile world of online retailing pushes you to getting short iterations, be flexible, be responsive, et cetera, et cetera, whilst the bank is more oriented towards keep it running, make sure it's predictable, make sure the audit trail is 100% covered. Make sure that you're really, really, really, secure. You have strict regulatory constraints that you have to adhere to, and you need to be able to show to the regulator that you're adhering to them.

Rouke (18:02):

An online retailer in the end, the user experience, that's your regulator. The customer that buys stuff and comes back, that's your regulator. You've got a few legal boundaries, et cetera, obviously as a campaign, but not as much as a bank does. It has a fundamental different perspective, but you do see similarities in needs and ways of working popping up.

Rouke (18:33):

I mean, there's still a dynamic interaction with different customers, with different institutions, from a bank perspective that needs that flexibility. You still need to apply changes. You still need to provide new features. While in online retail, you got a yearly planning, you have a growth plan. You want to get new categories exposed on the marked. You want to acquire more consumers for different products. In the meantime you got, well, the madness of the day to day operational stuff. Like if a big artist dies, for example, compared to a bank, well, there could be some bad news if you've got a security leak or something like that. And that then necessitates a higher level of trustworthy change flows basically.

Rouke (19:28):

And in that particular way, you can apply DevOps principles in a bank, but you have to apply them in a different way. You have to use them for a slightly different goal compared to the volatility of an online retail world. It's a unique combination of flexibility, speed, security, predictability, and what feels safe basically. I mean, failure in the banking world has a different impact than in online retial for example. If I, as a consumer, cannot buy something, I can't put it in my basket and online I'm going to shop.

Rouke (20:18):

For three days, yeah, I might not be able to buy that present for that person who's having his birthday or something like that. But as a bank, if people can't pay, get money or something like that for three days, well, you've got a different impact. You've got a different business case that you have to take care of. You can still apply DevOps's principles. You have to approach the results in a different way with different constraints and different expectations.

Heidi (20:50):

Thank you Rouke and thank you listeners. If you're curious about our work in Benelux, do check out a special edition of Let's Talk Business by the Dutch radio station, New Business Radio, featuring Jari Litmanen, the Finnish football legend, Heikki Hämäläinen, Eficode's Head of Growth, and Andre Sibov, the Area Manager of Eficode Benelux.

Heidi (21:12):

The recordings will give you the full download on where Eficode is going in the Netherlands, or should I say Benelux. You can find them at www.eficode.com/new-business-radio. Thanks for tuning into DevOps Sauna, Eficode's and Praqma's podcast about all things DevOps. Bye.