Why is it so hard for FS companies to get tech right?

 Nick Stemp photo
Nick Stemp
4min read

Getting tech right in banks is hard.

At 11:FS we get this because our experts have worked in some of the biggest financial services institutions and experienced how things can be done differently. In this article we’ll share some of our insights that we’ve learnt along the way.

Source: 11:FS

Source: 11:FS

Getting it right involves the beautiful combination of people, ways of working and technology. But we all know that this is a complex equation. Modernise your ways of working too quickly and you run the risk that your people will be left behind. Similarly, shifting to a new organisation design can decelerate delivery in the short term as people learn their role in their new teams.

Getting it right involves the beautiful combination of people, ways of working and technology.

Time to change how you do change

Let's take the example of change and the delivery of new features to the customer. We know from our research that those shipping features faster are also growing users and revenue faster. However, many banking incumbents take far more than eight weeks to get a feature into the hands of a customer.

Source: 11:FS

Source: 11:FS

This is because big banks have a history of gravitating toward big scary changes without even realising. We’re not talking about huge integrations or divestments which can take plenty of planning. We’re talking about the types of changes that happen painfully regularly, like a monthly business release to a digital channel. They get big and scary for a number of reasons:

  • Each technical component is managed by a different technical team, increasing complexity

  • Maintenance windows mean that many changes are typically rammed into an antisocial hour or two at the weekend. For instance the application is updated by one team while another is patching the operating system and restarting infrastructure

  • Tasks are performed manually by people who often understand the technology but have no idea if the overall change worked

  • A long list of approvers adds very little value and the time spent chasing approvals significantly distracts from the preparation and execution of a successful change

Get change wrong and watch the organisation roll into a ball like a timid hedgehog.

Overbearing scrutiny, finger pointing blame and stagnation…

What everyone aspires to is featureful releases, done safely at speed and on demand. Here are some of the ways this can be achieved.

Source: 11:FS

Source: 11:FS

Mission

The mission has to be well communicated and regularly referred to. If the business is to give the customer a great payment experience, behaviours from leaders and followers must align. Unaligned and the change gets blocked on a technicality…maybe a missing approval from someone who isn’t close to the change. Aligned and the hedgehog becomes supersonic. One of the challenger bank brands we work with is brilliant at doing this. A six-week plan and regular punching updates from the business side.

The mission has to be well communicated and regularly referred to.

Modern architecture to go faster

There are a lot of different architectural approaches to enable agility but today I’m covering the microservice architecture in relation to an integration service layer. Microservices give you decoupled services organised around the business capability. Payment transactions or identity services for instance. When we build the backend services we use Kotlin for the reasons explained here. How you choose to code is up to your organisation. It’s really important that the services have clear boundaries, full test coverage and distributed tracing. Breaking the monolith up into services means that more people can get involved without tripping each other up. It all helps to build faster and move forward safely.

Org design for capacity and speed

We organise around the mission and our teams mirror the different business priorities at the time. Each of our feature teams has a mix of skills. Frontend and backend engineers, product owner, QA, UX designer and more. They have the autonomy to set their own priorities and make sure they deliver customer features. They’re empowered to focus on the features which benefit the customer and are responsible for their release cadence.

Technology choices for on-demand deployments

Making good technology choices enables on-demand change. Public cloud is a given these days for a whole bag of reasons. On top of cloud we have a Kubernetes cluster (or clusters) which orchestrates the deployment of the backend microservice containers.

Deployments to the Kubernetes cluster are defined in code which is stored in the Github version control system. Changes can be rolled across the cluster in minutes with no customer impact. To keep it even safer we can do canary releases or A/B testing, either defined in the Kubernetes deployment or through the use of a service mesh like Istio.

Gone are the days of detailed backout plans and restores from backup. It’s a smaller change and everything we need to get the service layer to a point in time is safely stored as a versioned bit of code or configuration.

Build using repeatable pipelines for safety

The continuous integration and delivery pipeline can be likened to the manufacturing line of a factory. It takes the code and configuration, builds the images for the services, tests them, deploys them and then tests them again! Deployments are triggered by a source code event which runs the workflow end-to-end. This puts the deployment in the hands of the feature team. Gone are the days of the three-day change lead time and 10 approvers.

Test like you mean it

Finally the testing coverage needs to be top notch and the end-to-end tests against the external API need to cover the different interactions from the mobile or web app. With this deployments can be performed across the day without the risk of breaking things.

There’s a lot to consider when thinking about releasing features quickly into the hands of the customer. Getting the technology and architecture right is a big part. But people and ways of working are just as (if not more) important. With alignment to a mission, the feature teams are empowered and the culture around them provides the nurturing environment for them to be successful.

At 11:FS we understand that getting tech right is hard, which is why we created the Truly Digital Tech Assessment. Over a structured eight-week engagement our experts will work through a process to get you fit for your mission. We’ll have some great conversations across your organisation, figure out where you are facing challenges and work with you to build a roadmap for change. Get in touch.

 Nick Stemp
About the author

Nick Stemp

Nick is also responsible for engineering and architecture within 11:FS Consulting, supporting the build out of new products for our clients and helping them transform their technology.

We are 11:FS

We believe digital financial services are 1% finished. We’re building the next 99%.

What we do

11:FS builds next-generation propositions for challengers in the financial services industry: existing firms looking to innovate, start-ups looking to scale, and everyone in between.