In this post I share findings from our research regarding Financial Services. I then cover two key patterns used by real-world Redgate clients in the Financial Services industry to improve both speed of delivery and the quality of database deployments.
Financial Services reports the highest level of investment in DevOps
In the 2020 State of Database DevOps Report, we found that respondents in the Financial Services sector reported the highest levels of investment in DevOps, compared to other industry verticals. Here’s how the adoption rates broke down for folks in Financial Services:
Adoption or Investment
- 20% – DevOps has been adopted across all projects in the organization
- 41% – DevOps has been adopted across some projects in the organization
- 16% – DevOps is currently in a Proof of Concept or experimentation phase
- 15% – A plan is in place to adopt DevOps in some or all projects in the next two years
No plans for investment
- 8% – No plans to adopt DevOps in the next two years
Speed of delivery is a significant driver for Financial Services
Respondents across all industries are concerned with speed of delivery, including Financial Services. When asked about the greatest downsides of traditional siloed development patterns, the top concern cited by respondents in Financial Services was “slow development and release cycles.”
Further, when asked about the main driver for automating the delivery of database changes with DevOps, 35% of those in Financial Services Cited “to increase the speed of delivery of database changes” as the top reason — compared with only 28% of the total survey population selecting this as their top reason.
We also found that 54% of respondents in Financial Services deploy production database changes once a week or more often, the highest average rate of deployment across all industry sectors.
Together, these numbers show organizations in this sector are highly motivated to deliver change quickly.
Pattern: protect customer data by default
When working closely with organizations in Financial Services, I’ve heard customers express the need to deliver changes quickly, which is very much in line with our research.
I’m happy to say that I have also heard a lot of care and concern over code quality and the appropriate use of customer data.
Organizations in the Financial Services sector are not only under significant pressure to deliver changes quickly, they also work under a high level of regulation and concern regarding data breaches. In addition, organizations in Financial Services want to invest in continuous quality, using automation to enhance the early detection of bugs in the software development lifecycle.
The customers I’ve worked with in Financial Services have goals to protect customer data by default:
- De-identify data before it is available for use in the software development lifecycle
- Centralize management of development datasets, using technology to create lightweight copies of large databases (and avoiding sharing copies of backup files which may easily leak company IP if laptops are lost are stolen)
- Provide on-demand capabilities for short-lived development database environments aligned with feature branches in Git for isolation of feature development
This combination of a highly competitive and highly regulated environments has pushed our Financial Services customers to innovate quickly and adopt the latest database DevOps technologies available.
As Redgate continues to release features integrating lightweight clones with our DevOps workflows, I find that it is our customers in Financial Services who are most eager to experiment with and implement these integrations immediately.
Pattern: reduce dependencies and complexity of legacy databases
Another pattern that I have heard from customers in Financial Services is that they wish to move away from legacy databases where multiple teams share a single schema. These legacy databases present challenges to delivering changes quickly:
- Changing a single database object can impact multiple teams
- It is difficult to document or understand the dependencies between objects
- Sharing a single schema makes merge conflicts more likely and adds significant complexity to code review, testing, and release management
In some cases, I hear that customers are moving toward a microservices architecture. In other cases, I hear that microservices is seen as more of an extreme, and the organization’s goal is more moderate: they wish to move to service-based architectures where multiple services may sometimes share a datastore, but there are a greater number of datastores and each has more manageable dependencies.
In all of these cases, customers explain that they cannot halt the flow of changes while they work on the larger architecture. Even while functionality is split off into new services and as some data migrates to new datastores, work must continue against the legacy databases.
To enable progress to happen on both fronts, customers in Financial Services implement workflows for database changes which will work both for their new projects as well as for their existing databases.
This pattern enables:
- Developers to move between teams and work with familiar workflows
- Changes to be deployed to all databases with quality and a high rate of speed
- Improvements in workflow to be shared across the entire development team as time continues
It’s an exciting time to work in Financial Services
I have a great deal of fun working with clients in the Financial Services sector: we’ve seen that these folks are not only motivated to innovate, but also that their organizations are eager to take on the work of DevOps cultural change. These companies not only want to move faster, they also want to empower their engineers, foster psychological safety, and create great places to work where developers and IT staff can be creative and productive.
I personally believe that this industry is leading changes which will continue to sweep through other verticals.
If you’d like to learn more about the Financial Services sector, we have a host of videos, whitepapers, case studies, and research to continue your learning.
Was this article helpful?
Also in Blog
A lot of work with Flyway is going to take place on development machines with the Flyway command line installed. Another healthy chunk of the work will be on dedicated instances used for Continuous In...
Also in DevOps
Going strong into its fourth year, we published the 2020 State of Database DevOps report at a time when we couldn’t have predicted the changes to come for every industry. However, it still contained...