Xanthe Saunders Martin

15 May 2020

Discover the real state of Database DevOps in Financial Services in Redgate’s latest report

Earlier this year we published the 2020 State of Database DevOps report, in which the responses from thousands of IT professionals gave us a unique insight into how organizations and individuals are adopting DevOps. It also covers how teams operate, key areas for optimization, and the biggest challenges they currently face.

To gain a deeper understanding of DevOps in the Financial Services sector, we’ve now released a special Financial Services edition of the report. It shows businesses in the sector how they compare to their peers and others from different sectors, as well as providing valuable guidance on where to focus their next digital transformation initiative.

As mentioned in our previous post about the adoption rates and key drivers for Database DevOps in Financial Services, those within the sector were the second largest industry to contribute to the report findings, and are also the frontrunners when it comes to implementing DevOps for the database. This post will explore some key areas which are pertinent to Financial Services in the context of DevOps adoption, and dive a little deeper into some of the challenges and benefits the sector experiences.

Deployment frequency

Ever since the Database DevOps report was first published in 2017, the proportion of respondents deploying changes at least once a week has increased every year across all sectors. However, the proportion of organizations deploying regularly is consistently higher in Finance Services compared to other sectors:

54% of respondents in Financial Services reported deploying database changes to production at least once per week, ahead of Media & Retail and Healthcare & Pharma at 53% and 51% respectively. This follows a similar trajectory to DevOps adoption rates, which have increased to 77% in Financial Services, compared to the next highest sector, IT & Tech, at 70%.

However, it’s not as simple as DevOps adopters being the only ones deploying regularly. An interesting point to note is that Financial Services respondents who haven’t yet adopted DevOps report a slightly higher amount of deployments than those who have fully adopted DevOps.

When we dig further into the detail and look at the quality of deployments however, we see that non-adopters report a significantly higher frequency of hotfixes required, which may be attributed to the greater frequency of releases:

DevOps adopters not only report fewer hotfixes, but also far less scheduled downtime, and the period it takes for database changes to be deployed is reduced too. In fact, the majority of DevOps adopters also make their deployments while the application is live for their users, so there’s no need to even interrupt the application’s availability:

We can reason here that full adopters of DevOps are releasing at a high frequency – and that the process is more efficient, the quality of the code is better and, consequently, deployments are more reliable.

Shared vs. dedicated environments

The Financial Services sector is among the industry leaders when it comes to those who are most likely to have dedicated development environments. 29% of respondents from the sector reported that they utilize dedicated environments for high-value database work. Although this makes them one of the frontrunners, it also shows that a relatively large proportion of businesses in the sector are still using shared environments as the default for database development.

This despite the fact that the dedicated model introduces a number of good practices which could otherwise be bypassed in the shared system, such as developers version controlling their database changes so that one source of truth is always maintained. With dedicated environments, developers are also given the time and freedom to innovate and test their changes, without the risk of failed experiments affecting the whole team. Conflict management is taken into account too, removing the need for constant, labor-intensive communication among the team that inevitably results in code clashes despite best efforts.

So why haven’t more organizations implemented it? The explanation may be that, while reducing risk and allowing for greater speed and security of development, it still takes time to introduce dedicated development environments. And, as we saw in the previous post on DevOps adoption rates and drivers, many businesses report that adopting new tools and processes can be off-putting due to the expected disruption to existing workflows, at least during the implementation phase.

But for those that do choose to take these steps to modernize and improve their systems, they can reap the benefits that this more modern way of working facilitates. It’s likely we’ll see an increase in those using dedicated environments as time goes on – we’ve already seen it increase each year in line with other best practices like version controlling database code and performance monitoring. And although dedicated database development is an investment for companies, more and more are seeing how slow or poor-quality releases can easily cost far more to fix in the long run.

Change Approval Boards

In the latest Database DevOps report, 38% of respondents stated that approval for database deployments is required from a Change Approval Board (CAB), which rises to 46% for Financial Services respondents. We also saw this rise further for Enterprises and for those respondents with larger development teams.

Despite the fairly prevalent use of CABs, and that their main purpose is to be a safeguard, the report shows no evidence that they facilitate lower code defect rates, only that they increase lead time for changes. This, in turn, is a major blocker to continuous delivery in the industries that require it the most. Respondents in Finance Services were the most likely sector to report some percentage of deployments being cancelled late, with over half of respondents in this group indicating that this happens in 2% or more of deployments.

So how do you improve the relationship between CABs and IT teams?

Firstly, consider how to approach the CAB with proposed changes. Those on the board are looking at each suggested change and evaluating it in terms of its added value to the business, as well as any associated risk it brings. They need to be given the right information to make an informed decision. Essentially, for those who are proposing the change, the best approach is to mitigate the risk as far as possible, and think about the value it generates, not only on a smaller scale, but also to the wider business. As Grant Fritchey, Redgate DevOps Advocate, writes in a section on CABs in the full Database DevOps Report, the key to working with them is information and education:

We educated the board members on how exactly we were automating things and the level of documentation we could provide. Not only were we able to show successful testing, but we could also show exactly what changes we were making and when. That helped to reassure the board and, instead of a blocker, they became participants in the process.

In addition to how the board is approached, adopting DevOps can help improve some of the underlying issues organizations face when working with CABs. Once a mature system is in place for continuous integration and continuous delivery, it’s then possible to have a positive feedback cycle. Releases are more frequent because they are lower risk, and it also highlights problems earlier on in the delivery cycle when they are far easier to resolve.

With successful procedures in place for repeatable and scalable software delivery, and processes for error management, it’s easier to gain the trust of the board for future planned changes, in turn, speeding up approval time.

We see evidence of this being reflected in the Database DevOps report, which showed that DevOps adopters are markedly more likely to report it being straightforward to get a code review, with 70% of those who have adopted DevOps across all projects saying it is easy to get a code review. And in Financial Services, it is even higher, at 72%:

In conclusion, there’s every reason for organizations to be open-minded to a DevOps approach. It’s a part of staying agile, and particularly important within sectors like Financial Services where it’s vital to remain at the forefront of database development to be able to keep up with the competition. It can handle a myriad of challenges which businesses in Financial Services now face, from increasing the efficiency and quality of regular deployments, to integrating best practices as standard and improving the way teams work with CABs.

Read the special report

To find out more about the particular challenges the Financial Services sector faces in adopting DevOps, download the 2020 State of Database DevOps in Financial Services. It highlights the differences – and similarities – that exist for businesses in the sector compared to other sectors, and gives a valuable steer on where they should focus their digital transformation initiatives.