3 October 2017
3 October 2017

Can the database be included in DevOps in financial services?

I’ve had a lot of conversations with Database Administrators (DBAs) who work in financial services and, for many of them, deploying database changes is the most taxing part of their job. They’re often required to review thousands of lines of script and it can take days, depending on how many errors they find.

Even when database deployments are better planned, it’s not an easy journey, and DBAs are often regarded as the blocker in the process, the ones who are causing the problem rather than trying to resolve it.

Yet the same drivers that make DevOps so attractive for the development of applications in financial services also apply to database development. Increasing the speed of delivery, for example, reducing downtime, and improving compliance are all just as applicable for the database as they are for applications.

DevOps is about changing the culture of software development and improving collaboration between development and operations teams. But it’s also about automating many of the common jobs in delivering software, such as source control, testing, compliance and security checks, and deployments. With the automation in place, a process is established that is becoming increasingly common in application development:

Development progresses from source control through continuous integration to release management before changes are deployed. At each stage, the changes are checked and tested so that errors are picked up earlier in the cycle and software releases are both faster and more reliable.

Databases, however, are more problematic because business-critical data needs to be safely and correctly preserved. In addition to this, there are specific challenges in financial services, such as extremely complex systems, legacy databases, and siloed departments.

Tools and processes have now been introduced, however, that allow databases to be developed alongside applications by plugging into and integrating with the systems and infrastructure already in place:

As can bee seen, rather than database development being separate to that of the application, and managed at the very end by a siloed team, it becomes an integral part of the whole development process.

By committing database changes to source control on a regular basis, automated builds and tests can be introduced to make sure all of those small units of change are tested and validated multiple times before being deployed to the next environment. This results in releases being more reliable and less time-consuming, and means teams can respond to change a lot faster. As a direct result, the speed of delivery increases and downtime is reduced.

Importantly for DBAs working in financial services, it also makes auditing and compliance far easier because it becomes a natural part of the process. There is a record of every change, including who made it, when, and why, and the review step at the release management stage means the DBA has a full and complete view of every release.

This is a real advantage for companies and institutions where, typically, the database has been a bottleneck. Because the application and database are developed and tested together, errors or potential issues are highlighted much earlier in the development process, avoiding problems when changes are deployed. It also, of course, means that established financial services companies can compete alongside new fintech disruptors, rather than being left behind.

For more information about how you can include your database in your move to DevOps, visit the Redgate DevOps pages online,or connect with me on LinkedIn.

You can also see a snapshot of DevOps adoption rates in financial services with an online infographic, which extracts all of the relevant data from Redgate’s recent State of Database DevOps report.


This is the second post in a series about database DevOps in the financial services sector. You might also be interested in the first and third posts:

What are the leading DevOps drivers in financial services?

How advanced is database DevOps in financial services?


Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Blog

Major new study reveals the true ROI of database DevOps

DevOps is moving into the mainstream, and the database is now being included, but what holds many C-level executives back is the thorny issue of calculating the Return on Investment. They need to know...

Also in DevOps

5 tips for achieving continuous delivery

If you’re struggling to set up a reliable, repeatable release process you’re not alone. The good news is that most of the problems you’ll encounter have been solved before.

There are many smart...

Also about Database DevOps

How advanced is database DevOps in financial services?

Whether you’re exploring the advantages of DevOps or already fully immersed in the journey, including the database brings additional advantages. But how are you performing compared to the competitio...

Also about devops

The four pillars of DevOps

Firstly, let's get something out of the way. DevOps is something that polarizes people because there are various definitions of what DevOps is. I actually never use the word with technical people beca...

Also about financial services

What are the leading DevOps drivers in financial services?

DevOps is gaining ground everywhere. By offering a route to releasing software faster, with fewer errors, it can give companies which adopt it an immediate advantage. Unfortunately, it’s not somethi...