Busting 4 DevOps Myths in Financial Services

By Andrew Phillips, Head Product Management, XebiaLabs

Andrew Phillips, Head Product Management, XebiaLabs

Many people in the financial services industry wrongly believe that DevOps and financial services inhabit such different worlds that they can never blend together successfully. There is a widespread perception that DevOps is too high-tech, too fast-moving and too disruptive to be applicable to conservative, highly regulated institutions that resist change, operate a very diverse set of heterogeneous computer systems, and deal with a wealth of rules and regulations.

The reality, however, is quite different.

Sure, DevOps is fast-moving and potentially disruptive. However, DevOps is a great fit for any industry looking for ways to break down the technical and cultural walls that divide developers, testers, business analysts, and operations teams. In common with other industries, financial services is under daily pressure to improve software development and operations so that it can deliver software faster — without breaking the bank, or anything else in the process.

The need for speed in software development is increasingly being shaped by customers, whose experiences of web and mobile applications have given them insatiable appetites for automatic service, frequently at the click of a button. If Bank A cannot satisfy their service needs, customers will simply abandon ship and sail off elsewhere.

With competitors able to release new features within days or even hours, finserv companies can no longer afford unpredictable, lengthy, and inefficient release processes that barely support one update every couple of months. Antony Jenkins, the former CEO of Barclays, recently said in a speech that big banks risk becoming merely capital-providing utilities that operate in a highly regulated, less profitable environment, a situation unlikely to be tolerated by shareholders.

Jenkins said, “We will see massive pressure on incumbent banks, which will struggle to implement new technologies at the same pace as their new rivals. Ultimately, those forces will compel large banks to significantly automate their business.”

At its simplest, DevOps brings together disparate teams that traditionally might not communicate, or even want to communicate with each other. Those teams comprise developers, QA and operations people. The core idea of DevOps is to bring those teams together to improve collaboration and share understanding of the entire application lifecycle — with the goal of building more scalable, higher quality software that delivers better service to customers.

Myth 1: The strict separation of Dev and Ops — imposed by regulators — inhibits the adoption of DevOps.

There is some truth to this, but mostly there is a lot of hype about the risks of allowing developers to gain access to the production-side of the house — and the risks of allowing operations people to tinker with software development.

Once an institution imposes good lines of communication between developers and operations people, the two groups can work together to improve the continuous delivery of software without violating any legal definitions of their roles and responsibilities.

Going beyond that, the high degree of automation that typically accompanies DevOps adoption adoption provides a far more seamless, end-to-end, easily accessible audit trail than today’s manual handovers and coordination via a multiple of emails and documents.

Myth 2: The software and hardware environments of finserv companies particularly banks, are not compatible with DevOps.

Some industry people argue that banks and credit card companies have so many legacy-based mainframe applications — that have run unaltered for years — that these institutions do not need to and perhaps even cannot change how they develop software or respond to market forces. Often, the mind-set is reactive, to fix software when it breaks.

However, proactive banks know that DevOps can improve the software lifecycle of any application through better communications between Dev and Ops, automation, enhanced standardization, and faster delivery of updates. Ironically, this kind of tight collaboration and shared understanding of both the development and operations part of an application lifecycle is common in the mainframe environment, where one team often wears both Dev and Ops hats.

Myth 3: Change is more disruptive than creative, and is a major cause of system outages.

Some financial services executives believe that moving to a DevOps model of software creation and management will inevitably increase the frequency of outages and problems in an industry where uptime has often been the gold standard.

"DevOps is a great fit for any industry looking for ways to break down the technical and cultural walls that divide developers, testers, business analysts, and operations teams"

Again, this is another example of the conservative and reactive mindset at work — that change is bad and frequent changes are worse for being rife with potential errors. Instead of adopting DevOps, agile practices, and continuous delivery of software, reactive executives say, let’s stick with the way we create software today. Keep the process manual, periodic, and annual; let’s hope that slow, methodical changes done by humans will not be full of errors.

The key benefit of DevOps and continuous delivery is that new code can be created, tested, re-tested, and released much more frequently with less risk and far superior results to the old way of doing things.

Myth 4: DevOps must be implemented at once throughout the enterprise.

Some financial services executives believe that DevOps must be embraced totally or not at all. DevOps can be implemented one step at a time, one application at a time, and its progress can be closely monitored for successes and failures.

Myths have no place in modern application development and operations management. The goal of DevOps is to create an environment of shared access, control and insight into how applications are created and managed. Properly done, DevOps can minimize errors in software delivery, bring teams closer together, and accelerate the time-to-market of new and updated software.