4 Myths About DevOps in Financial Services
4 Myths About DevOps in Financial Services
DevOps works to break down the technical and cultural walls that divide developers, testers, business analysts, and operations teams.
Join the DZone community and get the full member experience.Join For Free
Discover how you can reduce your Kubernetes installation from 22 steps to 1.
This is from a great article in CIO Review by Andrew Phillips.
Most people think that the high-tech, fast-moving, disruptive world of DevOps can never blend with the conservative, highly regulated, change-resistant financial services industry. The reality however, is quite different.
DevOps works to break down the technical and cultural walls that divide developers testers, business analysts, and operations teams.
Just like everyone else, financial services are under daily pressure to improve their software and operations without spending too much money. Customers have gotten used to doing things with a click of a button and expect their banks to function the same. If the bank is unable to satisfy their needs, the customer will simply join a competitor.
When your competitors are able to release new features quickly, your financial service company will need easy, quick, and efficient release processes that support many updates per month. In fact, Antony Jenkins, the former CEO of Barclays, recently talked about the risk big banks face of becoming merely capital-providing utilities that operate in a highly regulated, less profitable environment, which is a situation unlikely to be tolerated by their shareholders. This is due to the struggle of keeping up with new technologies at the same pace of their smaller, newer rivals.
So, not only does DevOps bring together various teams that generally would not communicate with each other, but it does this with the goal of building more scalable, higher quality, software that delivers better service to customers.
Myth 1: There is a strict separation between Dev and Ops imposed by regulators.
There is a lot of hype about making sure that the developers don’t mix in with the production and that the operations people don’t tinker with the software. However, once there is good communication between these teams, the two groups will work together to improve continuous delivery of software without violating any legal definitions of their specific roles and responsibilities. Furthermore, DevOps comes with a high degree of automation that provides a more seamless, end-to-end, easily accessible audit trail than using emails and documents does.
Myth 2: The software and hardware environments of financial service companies (specifically banks) are not compatible with DevOps.
Some people are concerned that since banks and credit card companies use so many legacy-based mainframe applications that run unaltered for years, that they cannot, or don’t need to, change the way the develop software or respond to market forces. Instead, they tend to just fix software when it breaks.
However, DevOps can improve the lifecycle of any application by instituting better communications between Dev and Ops, automation, enhanced standardization, and faster delivery of updates. In fact, in the mainframe environment, this kind of collaboration and shared understanding of both Dev and Ops of an application lifecycle is common.
Myth 3: Change can be disruptive and can cause system outages.
In an industry where uptime is often the golden standard, many executives are concerned that moving to a DevOps model may increase the frequency of outages and problems. This is a typical response for an industry that is conservative and reactive in its mindset, preferring the process to stay manual, periodic, and annual and hoping that the methodical changes done by humans won’t contain errors.
However, the main benefit of DevOps and continuous delivery is using new code that can be created, tested, re-tested, and released with much more frequency and with much less risk, leading to superior results than the old way of doing things.
Myth 4: DevOps needs to be implemented throughout the entire enterprise all at once.
While many financial service executives believe that DevOps must be embraced fully or not at all, the truth is that it can be implemented one step at a time, one application at a time, and its progress can be closely monitored for successes and failures.
As you can see, these four myths should not stop financial services from implementing DevOps, that, if properly done, can minimize errors in software delivery, bring teams closer together, and accelerate the time-to-market of new and updated software.
Published at DZone with permission of Yaniv Yehuda , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.