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

How to build a DevOps roadmap to kickstart your digital transformation journey

Business leaders have never been more aware of the disruptive impact of digital technology. Across every industrial sector, organizations are embarking on digital transformation programs aimed at impr...

Also in DevOps

The top 7 benefits of DevOps for CEOs

If you were asked what the benefits of DevOps are, you could probably name two or three straight away. Maybe four or five. But – and here’s the thing – what if the person down the corridor was a...

Also about Database DevOps

Bringing DevOps to the database. Part 2: Continuous delivery

In part 1 of Bringing DevOps to the database, we saw how DevOps thinking is moving from the application to the database. By encouraging collaboration not competition between developers and Database Ad...

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

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...