The promise of what Agile and DevOps can do for enterprises is an enticing one: The ability to be nimbler and react faster through continuous integration and continuous delivery. Why, then, are banks and other financial institutions struggling to implement it?
It’s not that they haven't tried—heck, most banks are on an Agile and DevOps rampage lately, with many creating innovation companies within and beyond their walls to attract talent and break from the legacy culture or systems that impede true DevOps adoption.
I’ve spent the last 15 years in technology organizations within banks as a change agent. That experience has taught me that fundamental change “takes a village.” Everyone in the organization has to want to change, and it takes fortitude, passion, and perseverance to put that desire into action. For banks—which tend to be large institutions rooted in traditional processes—rapid change is easier said, than done.
While that’s true, DevOps offers tremendous promise to financial services. In this article, I detail some common obstacles companies encounter when adopting DevOps, as well as ways to avoid these pitfalls to quickly bring in-demand products to market.
DevOps and Agile: Understanding the differences
Agile and DevOps are often spoken of interchangeably, but should not be confused with being the same thing. Agile is a set of principles; DevOps puts those principles into practice using integrated teams.
Many in banking leadership will say "we’re Agile," without fully embracing its principles. For instance, many banks will adopt Agile development within a traditional waterfall software development life cycle—a term most call "Agile fall."
This isn’t Agile. It’s a a leftover of legacy culture that simply doesn’t work. Successful banks must embrace Agile transformation within a DevOps process. Then, practice it daily—top to bottom—embracing the culture throughout. DevOps, simply put, is the next step in the Agile process.
A (brief) software methodology history
I’ve been in application development for some time and have worked through the evolution of software development life-cycle methodologies. From waterfall (1970s), to iterative development (1980s), rapid application development (1990s), and to early adopters of the Agile manifesto (2000s). Now, we’re evolving to DevOps (2010s). All of these methodologies ultimately result in releasing code. As we’ve progressed through the years, the expectations of instant gratification have increased, requiring continuous integration (CI).
CI is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, automating testing, and DIT deployment, allowing teams to detect problems earlier.
Is this Agile/DevOps? No, but we’re getting warmer. What you’re missing with DevOps is the operations side of the business.
So, what is DevOps?
Banks are known for following processes and rules—technology standards, government regulations, information security, know-your-customer, risks avoidance, and more. It’s almost paradoxical: Banks that look to optimize by reducing costs and taking fewer risks adopt technologies and methodologies, which increase costs and risks. DevOps reduces these risks.
Forrester defines DevOps as the following:
"Helps organizations address a critical business challenge—that of continuously capturing and responding to feedback (both internal and external) so we can rapidly and repeatedly turn innovative ideas into highly relevant, and desirable, products and services. This involves not only development and operations, but all aspects of the organization, as it entails the collaboration across the entire organization including business and supply chain. Compared to single-direction, traditional models, DevOps is bi-directional and is based on not just pushing something out to the customer but also on getting their feedback to make improvements."
“DevOpstacles”
Most organizations will rush into DevOps. Typical reasons we see why most fail are:
Poor requirements (e.g., not following a behavior-driven development (BDD) mindset, a lack of executable acceptance criteria)
Tightly coupled architectures or legacy platforms (closed architectures)
Infrastructure provisioning takes too long
Server software is installed or maintained by external teams
Varying environment landscapes (e.g., development is different from integration, which is different from quality assurance (QA), which is different from user acceptance testing (UAT), which is different from production)
Manual software and database deployments
Development and operations teams work in isolation, as distinct teams. Developers think that their job is done when they’ve finished coding. Operations, dreading that moment, want smooth, reproducible, automated and reliable production releases
An inability to implement a Continuous Integration and Continuous Delivery (CI/CD) process
External teams mandate which tools the developer uses
Lack of or inadequate tooling (e.g., SCM, CI, Testing automation, etc.)
Lack of or insufficient level of test automation
Lack of support for operations in the code (logging, resiliency)
Lack of monitoring
Red tape (e.g., controls imposed by organizations to safeguard the stability of production systems)
Inadequately skilled staff—often seen in development and Scrum
A successful DevOps implementation
DevOps is simply an extension of the Agile transformation. Here are some ways organizations can ensure a successful DevOps adoption:
Form and keep dedicated product teams. Form dedicated, cross-functional teams, avoid over-specialization and ensure that teams aren’t interrupted by side projects.
Run and operate a Lean organization. Eliminate the overhead of periodic and manual status reports and status meetings, which absorb valuable time and distract focus from delivering value.
Embrace full transparency and a constant feedback loop. Transparency on a team’s progress helps everyone see where the project is at any point in time. It also gives visibility to potential risk, without decreasing productivity.
Define and deliver a Minimum Viable Product (MVP). Deliver the smallest viable product or application, then improve it in subsequent rapid releases, based on feedback. This delivers value incrementally.
Keep Sprint duration small (two weeks). Delivering in smaller batches helps to expose the most uncertain issues first. This also enables feedback on the most valuable usage models earlier in the process.
Build a loosely coupled architecture. Use loose architectural coupling within and between applications to reduce complexity and enable delivery in small increments.
Automate testing using application programming interfaces (APIs). The shift away from heavy manual testing improves delivery speed, quality, and testing accuracy. It also dramatically reduces cost.
Quick and continuous delivery. Eliminate unnecessary steps, delays, and friction between steps to increase the flow of work.
The tremendous promise of DevOps
Devbridge has worked with clients in various stages of Agile and DevOps maturity. A cornerstone of success is having inclusive, cross-functional teams (operations, infrastructure, information security, risk, and any others) constantly involved in the Agile process. We also help clients assess their DevOps maturity to gauge how much we can push them to the next level of DevOps, when they’re ready.
A common struggle for banks is ensuring that they invest up front to create a process and implement automation. When our clients allocate the required resources to focus on the business challenge, deliver iterative releases, and allow feedback to guide the next delivery, the product is delivered quickly. Embracing a culture in which it’s acceptable to fail—as long as you can react quickly to deliver—allows the organization to quickly deliver products that meet its goals.
Banks that embrace DevOps as part of the Agile process—not a separate add-on—will deliver products to market much faster. They’ll also have the ability to react to market or product failures that much more. The nimble, reactive nature of DevOps gives business what they’ve been wanting for a long time: quick failures with quick return on investment to deliver the products their customers want.