DevOps in Banks: What’s Hidden in Plain Sight

Adopting DevOps approach to software delivery in banks can be one of the best ways of gaining a competitive edge for them.

Modern banking institutions are complicated units with colossal infrastructure, stale operational workflow and multiple security and compliance regulations. Providing extreme protection to financial data and PII is great, yet bureaucratical limitations and multiple approvement stages form a barrier for fast-paced software improvement.

This, in turn, impairs the customer experience and might force the customers to go for another financial service provider, with more convenient self-service portal and mobile app. Therefore, delivering and improving the software within tight timeframes becomes essential for the banks and adopting the DevOps model can solve this daunting challenge. However, there is a plethora of obstacles the banks should overcome  — and some not-so-obvious vantage points they have.

The existing challenges the IT departments face in the banks

There are quite a few challenges the IT specialists have to face and overcome in the banks nowadays:

• Legacy hardware and software ecosystem
• Strict delegation of responsibilities, leading to siloing of tasks, tools and workflows
• Multiple approvement levels and other bottlenecks

Legacy hardware and software form one of the biggest challenges both in terms of transition to DevOps and in terms of remaining competitive nowadays. The existing ecosystem is often several decades old, with mission-critical environments running on clusters of dedicated servers with manual configuration of each new machine deployed. This leads to huge problems in  administration of banking software and the rest of the ecosystem – like Windows Active Directory and various custom software and modules. These systems are often combined with jury rigging and demand intense manual work on ongoing maintenance, not to mention improvement.

Security is the main concern in banking, which leads to locking out many functions of the software, strict control over hardware requisition and multiple limitations the IT department has to face. The things should be done one way and this way only, according to a strict workflow, to ensure security and transparency along with the ease of audit.

In addition, there is a potential for managerial overhead with approvals and possible bottlenecks with software QA and improvement or procurement of additional hardware for another staging environment. All of this might result in a situation, when a much needed and pretty obvious action cannot take place for weeks, because one signature is missing, as some executive went on vacation. The reasons can vary, the result is the same — banking software development timeframes suffer, releases are quarterly or even semi-annual, which is clearly not enough in the modern fast-paced business world.

Possible vantage points for adopting DevOps in banks

While the most obvious solution is hiring additional talent to deal with manual tasks or duplicating certain managerial functions to avoid bottlenecks, such an extensive way of solving problems cannot work forever. Embracing DevOps methodology not only in terms of corporate software development, but in all aspects of the bank’s operations is the way to overcome this crisis and gain an edge over the competition.

Oddly enough, the Development and Operations departments in many banks already have all the prerequisites for adopting DevOps methodology, as they already actively use Agile ideology. Here are just a few examples:

• Automation — the existing banking infrastructures are almost always held together and operated through thousands of lines of Powershell scripts, providing much needed automation layer for the systems that would be totally unmanageable otherwise. Increasing the coverage by actively adding automation wherever possible is quite a doable and highly beneficial effort.
• Microservices — unlike many other enterprise solutions, banking software and infrastructure is much less monolithic and more modular. In particular, the middleware is oftentimes built around messaging solutions like Websphere MQ, Tibco and Informatica. This sets the banks a huge step ahead of the other enterprises, who are yet to accept the concept of splitting their software into standalone API-connected services and updating them separately.
• Full stack mindset — banking software is aimed at providing reliable and secure service for sensitive financial data. This requires the developers to have a much broader mindset, including the understanding of software maintenance, database operations and architecture, the principles and advanced features of both backend and frontend development, etc. This also develops a certain feeling of software ownership, as the developed software is not passed to a customer and forgotten – it is a long-standing project that will demand improvement over time, so thinking strategically helps avoid multiple issues in the long run. Such mindset is one of the cornerstones of the DevOps ideology — “you build it, you run it”.

As you can see, despite the things like strict department structure, multiple hardware and software security limitations and complexity of legacy hardware, the banks have a huge advantage in adopting DevOps model for their software development process.

Conclusions

Just like any other enterprise entity, financial structures like banks will inevitably face multiple challenges when adopting the DevOps methodology. One of the most preferable models of transition to DevOps was described in our previous article, and the best thing is that the banks already have all the prerequisites in place. The only thing they have to do is giving their developers more operational freedom and embracing the vast structural, cultural and operational changes that the transition to DevOps brings.

However, speeding up the software development cycle multiple times along with providing a seamless customer experience works wonders. When the requests can be processed by any available team member without operational overhead and other bottlenecks, response times shorten drastically, which leads to decrease in lost business value and significant increase in customers’ satisfaction and loyalty.

At the end of the day, customer loyalty is what matters, and the ones not able to obtain and retain it, will be left behind. After all, the stone age did not end due to the lack of stones, it ended when the people learned to do things in a better way.