Customer Story: Vontobel

We sat down to talk to Fabian Gübeli about how Vontobel uses feature flags. Vontobel is a globally active investment firm with Swiss roots, specialized in wealth management, active asset management and investment solutions.

They use feature flags to release with more confidence. Vontobel host Flagsmith securely on their in-house infrastructure, and they just feel good about releases. They know that when they ship to production it's going to be safe and won’t need a thousand tests. Plus, product owners can make changes simply and without relying on engineering team support, which frees up time for everyone.

Could you tell us a bit about what your role is in Vontobel?

I'm a full-stack engineer and the application owner of Flagmith. That means that I'm the single point of contact in Vontobel for Flagsmith. I'm responsible for keeping Flagsmith up-to-date and taking care of any release errors, if they arise. 

What made Vontobel realize you wanted something like Flagsmith in your stack?

We had a homegrown solution for feature flags before, but it didn’t have the tools we need. We needed something that’s accessible for the product owners. Those product owners wanted to toggle features as well as the engineering teams, but that wasn’t easy with our in-house solution. 

We also had some Postman calls that we lost observability with. This meant that we didn’t have insights into who did what and when, and what the current state was in each stage. Visibility was one of the main drivers for choosing Flagsmith in the end. We needed more visibility into flag changes. 

We could have extended our system to gain more visibility, but then we would need people to maintain it and take care of it, and it gets complex fast. Plus we wanted the support that comes with an enterprise license.

You mentioned the product owners; how does your product team work with feature flags?

We have different staging levels during development, and each ticket is tested by the product owner in a staging environment before production. With our previous system, tickets would need to include a lot of information about what needed to be enabled, and what had to happen at each stage, and so on, which got complicated to manage. Now we can just say “Turn this flag on” or “Turn this flag off.” It’s much simpler for the product team.

Our application also has a debug page and application owner so that people can control flags directly. Product owners can now access flags easily, and without the engineers having to support them for each test case. It saves a lot of time for us. It saves time for them. It’s a win-win situation.

That’s great! How do your teams use flags now?

We mainly use flags to hide features on the back end. We also have a hybrid app on the front end that we are building with Ionic.

We’ll use flags when we develop new features with breaking changes or external dependencies. In those cases, we use feature toggles to hide the features and make sure they’re developed and ready in production. 

Then, when all of the external dependencies are also ready in production, we can simply toggle the feature on. We don't have to do huge overnight deployments with lots of people taking care of them. 

Sometimes we also have PoC’s (proofs of concept) and we hide those behind feature flags. That way we can enable the PoC on acceptance, but keep it disabled in production. This means that we don't have to maintain two code bases. Instead, we have one code base that contains both the current code and the PoC. One stream is behind the feature flag and one is the one on production. 

Another main use case is using feature flags for maintenance. In this case, we have a payload in the feature flag with maintenance information about things like what we’re doing and how long it will take. Then we can enable it and the customer will receive a pop-up when the feature flag is activated. That keeps them informed about the maintenance.

Do you ever use flags for segmenting or targeting? 

We do use flags for segmenting, but in a slightly hacky way. We‘ll segment when we’re testing in acceptance (the stage before production for us) and we want to test a case which will not be enabled in production and will only be at the staging level. 

Here, we have a debug menu where we enable the flag. And behind the scenes we will segment users and decide which users do and don’t have the features enabled. We don't have pilot or beta users at the moment, though, which would be a different way to use segments. 

What has changed the most since you've been using Flagsmith and feature flag software?  

Our development speed and velocity have increased. Mainly, though, I just feel good about releases. I know when I ship something to production it's going to be safe and I won't have to do a thousand tests to make sure I don't miss something. When things are behind a feature flag, I know what is and isn’t enabled in production and I have the visibility I need.

How often do you release? 

We have two-week sprint cycles and after each, we deploy to production.

Classically, bringing on new tools in banking is considered slower tends to be a slower process with longer cycles. How do you look at like changing or bringing on new tools as a banking institution? 

We have guilds at Vontobel. We have a DevOps Guild and an Architecture Guild, and since we have a lot of development teams, we’ll make sure that at least one person from each team is part of each guild. These guilds are responsible for analysing and suggesting new technologies. They also have a board that will discuss and evaluate the tools. 

This means that everyone can bring in new tooling ideas if they feel they would be helpful for their work and team. Then it will be discussed in groups to make sure that everyone is aligned and teams don’t run in different directions. 

What are the main factors that get considered when you're talking about new technologies and processes? 

Efficiency is a major factor. The other factor is identifying things that are missing in our existing development processes. This is how we brought Flagsmith on.

Before Flagsmith we didn’t have a solution for feature flagging, so the need grew and grew. We ran into more things we wanted to wrap in flags. This meant that we had to evaluate whether to build something ourselves and invest the resources into that, or to invest in a solution that could help us (and is the established practice in the development community).

How about open-source tools? How does the open-source piece factor in banking? 

Banking is surrounded by GDPR and compliance protocols, so it’s naturally hard to use cloud services. This means that evaluating and onboarding SaaS products can get really difficult. We would have to create contracts around the security and compliance pieces. It’s much easier when we can host the tool ourselves. So while the open-source piece is good, and it lets people test the tools and have transparency, the main thing we look for is support and using tools that we can rely on. 

We have systems that need to run stable, and we want guarantees that they will work—and that we will have fast responses for any issues that do arise. We need tools that are compliant, that work, and that check the boxes for making our teams work better.

That makes sense! And how about onboarding new tools? How did you deploy Flagsmith and did you do anything custom?

We use Openshift in-house and we deploy to that.

We use Ionic with Angular and consume a rest API to load the feature toggles from our backend services. We use Java/Kotlin in the backend, and this is where we did some custom work.

We wrote a small wrapper around Flagsmith for Java/Kotlin usage so that we can support multiple projects in one SDK. Classically the SDK can support one project and we have some use cases where we need to support multiple projects in Flagsmith.

We also have some CI/CD pipelines we use for building and deploying Flagsmith, and we use the Docker images you provide for those. We’re moving towards Dynatrace, though, and when we do we will use the integration to use the tools together. 

If you were to bring someone new onto your team, how would you explain feature flags and Flagsmith to them?

I would say that Flagsmith supports feature flag management and featured toggles for us. It gives us easy ways to do this so that we always know what is happening in each state. And it helps our development team know what is happening in each stage and lets us increase development velocity. 

Is there anything that I haven't touched on? 

The support is amazing. When I have issues or questions regarding upgrades, I can open a ticket and I always get an answer in less than a day. The support is great.

How much does support factor into decisions when you're looking at the tools that you use?

It’s big for me. I hate it when you write to a team and you don’t hear back for a week or two. And then you have to ping them to get an apology back that they missed your message. And then another week goes by with no word. So I really appreciate when support can respond within a few hours.

‍

This has been incredibly helpful. Thanks so much, Fabian!

Read the Vontobel case study here.

‍