9 October 2017
9 October 2017

Can the database be included in DevOps in financial services?

I have a lot of experience working in financial services and I’ve recently been talking to Database Administrators (DBAs) who work in the sector. Unsurprisingly, perhaps, 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 Redgate can support you and your community

As I’m sure you’ve already heard, Redgate recently celebrated 20 years of making ingeniously simple software, but did you know that we’ve also been supporting the Microsoft Data Platform communi...

Also in DevOps

Redgate's journey to DevOps

At Redgate, we research DevOps, write articles, whitepapers and other content about DevOps, and talk a lot about DevOps. We actively encourage our customers to introduce database DevOps too, using our...

Also about devops

Why you should include the database in your 2020 IT strategy

It’s that time of year when business leaders and managers in organizations of all shapes and sizes are considering what the next 12 months’ strategy and beyond should look like. Specifically, what...

Also about Database DevOps

How to stop standardization being a stumbling block in database DevOps

More and more enterprises are seeing the merit of introducing DevOps to speed up application and database development and deliver value into hands of their customers faster. The collaboration and coop...

Also about financial services

5 ways to compete faster – and safer – in financial services

The financial services sector is undergoing a transformation. Tech giants like Google, Apple and Amazon are stepping into the frame with digital wallets, mobile payments and lending services, and FinT...