Why Big Tech’s Approach Doesn’t Apply to Global Finance

By Nigel Kersten, field CTO at Puppet

There’s a certain allure to the technology industry that’s impossible to ignore. These modern titans of innovation make it all look so easy – they don’t have to migrate to the cloud because they’re already there; digital transformation is last year’s news. The start-up model is predicated on moving fast and breaking things. There’s no fear of experimentation and no real consequence for failure.

What a seductive business model. Like a siren’s call, it has beckoned to many enterprises looking to modernise – and I’ve seen too many stumble in their attempts to modernise because they fail to recognise the constraints of their specific industry, business, technical environment – or all three. What works for a young industry like technology simply doesn’t translate to the traditional enterprise or century-old bank. It would be like trying to use a sail to propel a multi-story cruise ship.

Moving fast and breaking things may work for a company proffering social media profiles, but it certainly does not work for the banking and financial industry. There are entire additional industries built on fining banks and finance firms if they make even the smallest error. So how does this industry best balance the need for speed and autonomy with the requirements of governance and compliance?

I’ll tell you: it’s a platform team approach.

How to make DevOps work for global banking and finance

For many years now, I’ve been working closely with customers looking to scale their DevOps practices. I’ve co-authored the industry-standard State of DevOps Report which examines, broadly, the DevOps maturity of a company as it correlates to its technical and business success. The DevOps movement began from a desire to shorten the software development lifecycle by enabling collaboration between development and IT operations teams, but this was left open-ended. There has never been a prescriptive model for DevOps.

That’s fine for a tech company whose entire business model is rooted in risk – but enterprises need a roadmap. The “two pizza team” ideology coined by Jeff Bezos simply doesn’t translate to a 200-year old, 10,000-employee bank that must abide by strict regulatory requirements and meet compliance and security standards. Amazon was building a platform, whereas enterprises and banks are largely seeking to build applications for external users. Initially, adopting a DevOps strategy may have worked for some enterprises exempt from governance, but ultimately, this approach could not scale.

So how do we successfully leverage a DevOps mindset within the banking and finance industry? With a platform team approach that delivers infrastructure to product teams in the form of self-service products through an API. In other words, the platform team manages all backend infrastructure, abstracts away implementations and operational management, and bundles it behind a self-service API. Crucially, this must be done with a product mindset, by which I mean the platform team must constantly interact with the product team to incorporate feedback and optimise their user experience. This requires empathy, patience, and commitment.

It also requires a cross-functional team of people with software engineering skills and infrastructure and operations expertise, who is responsible both for managing the entire platform as well as building the APIs that expose it to the product and application delivery teams. Why? Because this is the only way to ensure the team is aligned on shared outcomes. This team must have access to an automation platform that is flexible and opinionated in order to solve configuration drift issues and simplify operational tasks.

Critically, the platform must receive continuous investment from management. The data shows time and again that top-down support enables transformation (or at least, it did in our most recent State of DevOps Report). A product manager for the platform must be empowered by the organisation to prioritise features for the platform, assess both legacy and greenfield environments, and evangelise the platform throughout the organisation – in other words, to ensure teams are actually using the APIs being built by the team. They must also have the authority to sign off recovery and change actions as they are in the best place to understand the impact to customers and the business, instead of the traditional outside recovery management and change approach.

Why does this approach work?

Taking a platform team approach centers developer teams, and is ideal for a highly regulated industry like banking and finance. Here’s why:

• Delivering a great developer experience helps with velocity, quality, and retention for your development teams.
• There is a single point of control, making governance, compliance, and auditing cheaper and more effective.
• A platform team product manager who is deeply engaged with platform users enables you to keep IT capabilities aligned to current requirements
• An instrumented platform means that you know exactly when it’s feasible to deprecate little-used functionality, keeping your operations lean and efficient.
• The platform team can iteratively replace legacy infrastructure layers with more modern ones as appropriate, but because the infrastructure has been abstracted away from the user interface, customers are unaffected.
• Platform engineers have a clearer sense of purpose than your average banking IT operations engineer; they know who their customers are, they know what success looks like, and they’re not hamstrung by organisational silos around monitoring, networking, or operating systems.

Experiment (safely) with platform teams

The DevOps movement has been enormously successful for organisations who have adopted these practices, but a lack of a single agreed-upon definition has limited that success within industries that need structure, such as banks and financial firms. Platform teams are a proven way to apply DevOps principles within a defined structure, enabling banks and financial firms to adopt these practices and discover new ways to balance speed and autonomy with the requirements of governance and compliance.

About Nigel Kersten

Nigel is field CTO at Puppet and co-author of the industry-leading State Of DevOps Report. He works with Puppet’s largest customers on the cultural and organisational changes necessary for large-scale DevOps implementations. Prior to Puppet, Nigel belonged to Google’s site reliability engineering organisation, where he was responsible for one of the largest Puppet deployments in the world.