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.
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:
Was this article helpful?