How to Transition to Modern Feature Management in Banking

Developers working in banking and financial institutions often find themselves constrained by legacy systems that prevent them from deploying as frequently as they would like; instead, they are limited to monthly—or even quarterly—releases.

This is less than ideal for a number of reasons, but perhaps the biggest issue is that these deployments can become large and unwieldy, making them more error-prone. This is particularly stressful because banks can’t risk outages or issues with critical features, so the less high-stakes the release, the better. 

By transitioning to a more agile way of working that allows for more flexibility in the release process, developers can push features faster and more confidently. Feature flags are an important part of this toolkit, letting teams decouple deploy and release, remove bottlenecks, and increase release velocity. As banks begin to make the switch to modern feature management, finding tools that are built with data security in mind is essential. Look for tools that can increase agility while meeting your data security needs.

Challenges of legacy feature management processes

Complex coordinated releases 

We built Flagsmith to solve the problems that often come with coordinated releases. For example, a developer is writing code and wants to push their feature but can’t because there’s a dependency on another team or another platform that’s not ready. This blocks the developer, the build, and the release. 

This can create a lot of frustration for the team and add pressure on release days. If the release gets pushed back because of a hard dependency, developers feel the strain. The next release gets bigger, there’s increased potential for issues, and it can end in a Hail Mary release where everyone is sure something is going to break. 

Feature flags and feature management tools let the developer wrap the feature in a flag and just push the code. Then, when the work they’re waiting on is ready, they can go into their feature management tool and enable it. This lowers the number of release issues—like messy branch situations and monster pull requests—that are riddled with collisions.

Limited scalability with legacy systems

Many banks run on legacy systems and release processes. Developers might use feature flags and feature management as part of this, but they’ve likely built homegrown solutions to try and meet their needs. Developers realise early on that they need to disable parts of the code, and will create feature flags in the database or using code configuration. This can work, but there is a breaking point. A few warning signs that you’re reaching this point are: 

• Needing feature flags to propagate across a microservice architecture
• Realising that you’re tired of not knowing who changed what, when 
• Getting tired of product owners or business people asking you to change a flag for them or activate a flag for a user 

Let’s take the final item on that list as an example. Engineers can manually go in and adjust the config file when the product team wants to test a feature, but this is often only sustainable for simple use cases (say, on/off switches for certain features). If the legacy system is deployed quarterly, these requests can mount, and it can become untenable to keep manually fulfilling these. The problem grows in tandem with team and organisational complexity.

Consider testing, too. The manual nature of legacy systems means that you might have a dedicated team to comb through your code to surface any issues before going live. Manual testing isn’t feasible when you’re releasing code every day. In addition, if there are even a few manual steps in your testing process, human error usually prevails, and it becomes increasingly likely that mistakes will be made.

‍

Why transition to modern feature management using feature flags?

Short answer? To ship better products to customers—faster! Long answer? Read on… 

Release velocity 

Using feature flags, teams can decouple deploy and release, which means they can deploy when they want to and test in production. They’re able to do gradual rollouts, automate releases, and move towards a continuous deployment process (no more stress-inducing monster pull requests). 

As a bank, continuous deployment to production may be out of reach, but you can move towards a more regular release cadence that lowers the pressure on each sprint. For example, Flagsmith’s customer Komerční Banka (KB) deploys every day, but to non-production environments. This has many of the same benefits and ensures developers can push out their code when it’s ready, rather than being forced to wait on a release date.

Developer confidence

Apart from reducing cycle time, the number one benefit of introducing feature flags may be surprising: increased developer confidence and morale. We’ve worked with a lot of banks that have moved from massive quarterly releases to more frequent deployments, and it’s always exciting to see a boost in developer confidence as they’re able to push their code more easily. 

If developers can release their code more frequently, they aren’t as stifled by dependencies, and the pressure on each build decreases. This results in more successful deployments and features getting in front of customers faster.

Security and compliance

Financial institutions are heavily regulated and bound to stringent data security requirements. With robust feature management processes and tools, the banking sector can fast-track product development, while simultaneously meeting rigorous compliance standards.    

In the banking development ecosystem, processes need to be agile but also secure and scalable. Feature management tools, for example, offer detailed access management through RBAC and are built with data sensitivity in mind, offering on-premise and private cloud deployment options, team roles, and remote authentication via SAML, LDAP, and more. 

Built-in safety net

Though it might seem counter-intuitive, releasing code more rapidly using feature flags can create more stability and safety than adding a PR to your main branch when you’re running production code with a high-traffic API.

Feature flags let you push code iteratively and with a safety net, giving you capabilities like:

• Phased rollouts/canary releases: Allowing you to test high-risk features by only showing them to a subset of users—mitigating widespread impact
• Kill switches: So you can quickly and universally disable features in an application

Best practices for modernising release processes

The most important thing to remember when transitioning to a modern release process is to take it one step at a time. If you're working on a large, high-impact product in a bank, completely transitioning to decoupled releases can take years. So start small, and get things right before trying to overhaul your whole release process.

Team training and documentation

Set up technical talks about things like best practices, what can go wrong if you don’t set default flag values, how to set up A/B tests, how to debug and know which features are enabled for which users, and so on. Educate everyone in the team (not just engineers), and make sure they know how to integrate with the other tools in their stack. Remember to keep everyone looped in on releases, too. It’s important to keep documenting releases as your velocity increases.  

Find a provider who can help with training

Some feature flag providers (like Flagsmith) will help with setup and training your teams on best practices, etc. This helps a lot and takes the onus off of you!

Start small

Consider configuring the tool for a small team or a shovel-ready use case before rolling it out to a wider user base and other teams across the company. This way you can learn and iterate as you go.

Think about best practices for your company specifically

Operating in a regulated, data-sensitive industry means that you will need to be cognisant of privacy and user data. Implementing an on-premise solution, or deploying to your private cloud, will likely be the right choice over a SaaS offering.

For more best practices, check out The Complete Guide to Feature Flag Best Practices.

Where do feature flags fit into the bigger picture?

Teams often adopt feature flag management as part of a wider initiative around modernising the way they develop software. In financial services, this might mean transitioning from monolithic architecture and legacy banking systems to new infrastructure and ways of working (say, adopting things like the Spotify Model). If this is the case, it can be a massive project! It helps to adopt changes in the right order.

For example, I would recommend solidifying your automated testing before you introduce zero downtime deployment into your setup. Otherwise, you might just end up running zero downtime deployments that are rife with bugs. 

Take the below flowchart as an example of how you might structure your changes (and where feature flags fit in). 

Break down the problem into the smallest possible units of work that you can. Then figure out what the correct logical order of those things might be. Some may be possible at the same time, while some may have dependencies. 

You might split the changes into 12 tasks and the first three or four you can do concurrently, but then the fifth task depends on the fourth, which then unblocks the sixth, and so on. Build out a flow or diagram of the dependencies (like the one above) for each task. 

If this feels too manual, feature management and observability tools can also look at your existing processes and help you figure out where to start. 

Conclusion

Legacy systems can put a lot of pressure on developers for each build, especially when it comes to releases with hard dependencies. This slows down development velocity and also means developers can’t release with confidence.  

Feature flags and modern feature management practices let teams decouple deployments from releases and move towards a continuous deployment approach. This reduces the risk of bad builds, helps with developer morale, and gets new features in front of customers faster. Finding the right feature management tool can help with the transition, and also means that you aren’t implementing new processes alone. 

This article is an excerpt from Modern Development Practices in Banking: A Playbook. Download the full eBook for more actionable insights from leaders at Zühlke, Dynatrace, FINOS, and more.

‍