Wall Street and North American banks in general are serious about their tech teams. They are trying to provide a viable alternative to skilled candidates who would otherwise have ended up in Silicon Valley (read article for details here). With fintech and other disruptive innovations in banking, these skilled candidates are being recruited for the banks’ high-innovation teams (like BMO did with its AI and Data Science group or Live Labs at CIBC) but what about the larger enterprise? Have the lessons learnt from these smaller groups been translated to the existing legacy-operations systems?
Evidence suggests enterprise-wide DevOps adoption in financial institutions is still a non-starter
The sort of challenges that financial institutions must overcome before they can consider moving to a strong DevOps culture are not trivial. These challenges have been a part of their fabric since the beginning of time and to expect them to become DevOps-compliant quickly is unreasonable. In the opinion of this analyst, the top three challenges are:
Challenge 1: The weight of legacy technology and controls
Usually, large financial institutions have a history of mergers that has resulted in their technology portfolios being based on millions of different moving pieces and not all of them are compatible with each other. Financial organizations have also been amongst the earliest adopters of technologies and are not shy of spending money to keep ahead of the curve. Some of the technologies are still old main frames mixed with COBOL, third-party ERP, COTS, J2EE, SOA, and a bucket full of other acronyms.
These technologies don’t support rapid iterative changes and deployment that DevOps is based upon.
In addition to these older technologies, banks have a data back-end that probably defies transitioning to Agile methodologies like DevOps.
Challenge 2: Compliance
Regulation is to the financial industry what smartphones have become to everyone else. We don’t want to live with them, always complaining about their influence on our time, but we also can’t live without them.
Regulatory compliance has a direct impact on every part of a financial organization. From the work a database developer does in the back room to the customer service rep manning the teller’s kiosk, every employee in a bank must be aware of laws that dictate what the banks can do for their customers. Multinational banks have it worst. Not only are they responsible for their local regulations, there are specific requirements from regulators in the other jurisdictions that need to be considered. Intentional or accidental breaking of the law can be disastrous for a bank’s reputation and stock price.
In such stressful circumstances, the DevOps adage of “fail fast, fix fast” doesn’t sit well.
Challenge 3: Security
In 2014, JPMorgan Chase was hacked through a single unpatched server on the bank’s network. An analysis was undertaken by America’s top investigation agencies and they discovered the attackers had been lurking in the systems for two months. This happened after JPMorgan Chase had been spending monstrous amounts of money (some reports suggest close to 250 million dollars per year) on its cybersecurity program.
The surface area for cybercrimes at banks has increased in the recent past. With mobile solutions and apps becoming the de facto strategy for business, we can expect more attacks in the future.
DevOps is a risky proposition then for information security professionals. For them, DevOps takes too many risks and, clearly from their point of view, prevention of risk is the best cure against it.
Transformation of any kind for even the most agile organization is a challenge. Financial giants are no exception. They are, in fact, typical in their risk alertness. However, Google, Microsoft, and ING are all big organizations that have legacy systems supporting them but are still not afraid of being “DevOps.”
In recent history, the industry has seen drivers for adopting DevOps become more robust:
Driver 1: Cloud
The cloud has changed the entire conversation around DevOps. Financial services are spending billions of dollars on constructing private and public clouds from general work management (HR, CRM, Office 365) to more development-related tasks such as coding, testing, and provisioning pipelines.
Security and data privacy related issues have been a primary concern against cloud adoption. To the credit of service providers like Azure, AWS, and GCP, they have worked hand in glove with regulatory authorities and financial services providers to make security a core part of their platform.
Driver 2: Containers and Continuous Delivery
Containers have taken the guesswork out of system compatibility and application performance for different environments. If an application in a container works in one environment, you can bet your bottom dollar it will do the same in another and another and another.
Driver 3: Test Automation
Financial services spend significant resources on testing of all kinds. No system can just make it to production without regulators having a chance to confirm it meets core requirements. In some cases, the scope of regulatory work can be so extensive that testing ends up becoming a bottleneck.
With automated testing, this bottleneck is loosened. Proper test strategy supported by automated test tools can ensure auditors don’t feel uncomfortable about signing off on a release. A well-constructed automation testing plan can make functional, regression, integration, system, and even assurance testing quicker and provide predictable quality.
Driver 4: Compliance as Code
Compliance must be built into the development lifecycle. Instead of looking at compliance as the thing that happens when everything else has been taken care off, include it in the policies and checks for each stage of the software development life cycle.