A Conversation with Komerční Banka's Chief Software Architect

Komerční Banka (KB), part of Société Générale, is a leading banking institution in the Czech Republic with over 1.6 million customers. KB brought Flagsmith in as part of a broader modernisation project, which we’ve talked about here and here, but we wanted to sit down with Pavol to get an update on how Engineering is working with Flagsmith today. 

Modernising banking: Improving time-to-market with feature flags

‍

Hi, Pavol! I’ll just dive in if that’s OK by you. KB has undertaken a huge modernisation project over the past few years, including moving to an Agile 2.0 model, introducing the Spotify model, and starting to build new products on microservices. Can you tell me how it’s going?

‍

“Sure. Our previous internet banking and mobile bank was basically a huge monolith application. We needed to introduce microservices to provide us with more flexibility to improve our time-to-market. 

With our old architecture, time-to-market could take months, so we needed to speed it up. Of course, we also wanted to offer our customers the best UX and UI and to introduce innovations that our old environment didn’t allow us to make. 

In order to achieve this, we first needed to change the way we developed software. We needed to adopt Agile, we needed to change our organisational structure,  moving towards tribes, guilds, etc. And, to be frank, the transformation was kind of painful for an organisation of our size, but we managed to do it. We also introduced a lot of new technologies within our environment, like Kubernetes, OpenStack, private cloud, and so on. After that, we started to develop, and we saw the need for feature flags.”

‍

Can you talk about the role feature flags are playing in this modernisation?

‍

“In our previous internal banking solution, we were using Git Flow, but we wanted to switch to trunk-based development. With TBD, everything is developed by all the teams on one branch—the master. But the downside of this is that even the code that’s not quite ready is pushed into this master branch and gets delivered to testing and production environments. In short, we needed to hide it from customers because it wasn’t ready. This is where feature flags came in. We started looking for a solution and found Flagsmith.”

‍

We're so glad you did! I want to dig a little more into how your engineers are using feature flags today.

‍

Feature flag impact and usage at KB

‍

As a bank, are your engineers able to test in production using feature flags, or do you need to utilise pre-production environments?

‍

“We use feature flags for piloting new features in production. So each team, for example, the Payments team, comes up with a feature, and after it’s deployed to production, they have one day to pilot the functionality. We create a Segment in Flagsmith, and then we enable the feature flag for the people in that segment, and they test the feature. They have 24 hours for testing and tuning. After it’s ready, we enable it for everyone. We try to do pilots for most of our features.”

‍

Do you see that way of releasing impacting time-to-market? How has your development velocity been impacted by feature flags?

‍

“We improved the time-to-market because we were able to release to production thanks to trunk-based development. Feature flags were a piece of this puzzle, but we also changed the processes we had, the internal technologies. So it was the change at various levels, including feature flags that made this possible.”

‍

Prior to trunk-based development, did you see a lot of merge conflicts happening and consequently a lot of time spent sorting those out?

‍

“Yes, definitely. We had a master branch and development branch and lots of release branches. For example, if there was a March release and an April release, the release branches were created up front, and the developers needed to merge changes back and forth. And it was honestly pretty brutal for them. We were trying to automate some things, but it was still really slow.” 

‍

‍

Advice for other large organisations starting a modernisation motion

‍

Could you speak to some of the challenges you’ve faced along the way and how you solved them? 

‍

“I think the reason why our transformation was successful is that we had buy-in from leadership. We were trying to modernise the old solution as well, but we were hitting a ceiling—in order to be successful, transformation really needs to start from the top. This transformation began to build momentum when, after many conversations with our managers and sponsors, they decided that it would be really beneficial for us to go through the transformation as a company. We brought in external consultants to help with this as well. If the whole bank is undergoing a big change, it’s much easier. This is critical. 

Additionally, another important part of our success was that we created a specialised platform team. 

So now, if I have a team—let’s say a business team—that wants to start a new project, the latform team prepares tools for them like frameworks, microservices, infrastructure as code, and some pipelines. So now, thanks to the platform team, when a product owner comes in with a new team and a request to get going, they can start developing right away, and they know what they're doing, because the platform itself is well documented.

Essentially, we created a factory within the bank for producing pipelines and all the stuff around development. This has kept teams from reinventing the wheel and has made us more streamlined and effective.

‍

I know that you worked hard on creating governance around how to use Flagsmith at KB. 

‍

“Yes. I was responsible for adopting Flagsmith. The tool itself is pretty straightforward, but what was more difficult was coming up with the governance for adopting it: how to use it,  who can access it, how to split it into teams, projects, etc.

In internal banking, every product is basically a platform. We have teams for various products: accounts, loans, insurance, etc. So as teams contribute code to each product and use feature flags to do this, we need to create governance and rules for feature releases: who’s responsible for turning flags on and off—who has that level of access, and so on. This is just as important as introducing a new technology in many ways.”

‍

Were there any unexpected challenges that arose from using feature flags?

‍

“You know, if there is a screen that gets opened via one button, it's quite easy. I put a feature flag on the button and it works. But for more complex cases, we needed to decide and document how we use flags at KB. We needed to solve things like how to do kill switches. What's the difference between a kill switch and a feature flag (for us)? 

For us, feature flags are mainly about hiding unfinished code. Everything that isn’t finished is hidden. As an example of when this can get more complicated, let’s discuss kill switches. We can’t hide code we’ve already introduced to users—if one day functionality suddenly disappears with no explanation, that’s a poor UX. So we needed to create pages for this. For example, a page with the message: “this functionality has been temporarily disabled”, something like that. And we also needed to find a way to disable access from different sources like bookmarks. 

‍

Thank you, Pavol! This was really interesting, and I know other teams will find these insights really useful.

‍

“Happy to share! Flagsmith has played an important role in our banking modernisation project."

‍

‍