Komerční Banka (KB) is a leading Czech Republic banking institution with over 1.6 million customers and nearly 400 branches. The bank was built on legacy systems with huge, distributed monolithic architecture. To stay competitive, KB felt the need to modernise its infrastructure and software development approach. Due to its large-scale operations, there was an urgent need to modernise its infrastructure and software development to stay competitive.
KB had over 400 developers (out of 600) managing its legacy system built on monolithic architecture. The problem? The system consisted of heavily interdependent components that led to longer development cycles, higher bug risks, and a lack of system scalability.
These issues prompted KB’s COE (Center of Expertise) to improve efficiency. As a result, they launched “The New Digital Bank” initiative—a five-year project migrating their infrastructure to a micro services-based architecture.
The goal was to modernise KB’s banking system and adopt an Agile 2.0 development mindset—resulting in better service delivery.
KB developed its development framework using:
• Java SDK to build cloud applications
• Jenkins and Argo CD for CI/CD pipelines
• Kubernetes to deploy and run applications
As the infrastructure was built on monolithic architecture, every feature release, update, or product launch moved at a snail’s pace.
For example, it took the team days to get the system back up and running whenever there was a new Kubernetes update. There was no scope for automation of updates or independent development cycles.
Plus, the current system was a massive drain on the budget. They were already maintaining systems on-premise while subscribing to expensive tools like IBM. To overcome this issue, they were looking for open-source technologies as they’re free and have minimal upkeep costs.
The use of feature flags is common in the banking industry. Many companies, including KB, developed their own systems to manage them. KB’s homegrown tool handled simple tasks like managing the configuration files because the legacy system was deployed only three times a year.
However, KB was taking an Agile approach to development. So, they needed a tool that supported the approach and fit into the new micro services architecture.
When evaluating a feature flag solution for their modernisation effort, KB tried three options: continuing with their own system, adopting Flagsmith, and adopting LaunchDarkly.
Ultimately, they chose to go with Flagsmith’s solution because of its:
• System’s flexibility
• Excellent documentation
• Support capabilities
Before adopting Flagsmith, KB’s engineers had to wait months to ship new features or product releases. Their legacy system was deployed only three times per year. But now, they deploy daily to two non-production environments. One environment is used for testing during the build and the other is used for staging.
The goal was to get to production as fast as possible by keeping these environments close to each other. By doing so they can ship as fast as they need to—inching closer to completing the New Digital Bank initiative.
From the time they’ve implemented Flagsmith, over 85 engineers have begun working with it in production. That’s over half of the team dedicated to the program.
Flagsmith passed all their internal security checks with flying colours. When you consider how sensitive the banking industry is to such requirements, having a SOC 2-certified tool on their side only smoothed the transition.
Going forward, they can deploy features and products with confidence in a controlled environment without impacting the rest of the system.
In the future, KB plans on expanding Flagsmith’s usage within the company. They will start by integrating the API with JIRA to align QA teams with product owners. It’ll help them move flagging processes upstream, improving efficiency in the long run.
For more, check out the full interview with Jindrich Kubat, Head of Development & COE at KB.
.webp)