DEVOPSdigest

Redgate's annual State of Database DevOps Report presents a yearly glimpse into the latest facts, figures and trends about DevOps across different industry sectors. Over the last four years, Financial Services has consistently been the top performer, with more respondents in the sector adopting DevOps and introducing automation across the database development process, enabling them to deploy changes faster.

That's the good news. On the surface, businesses in Financial Services are ahead of the pack in their desire to deliver features quicker, respond sooner to changing business requirements, and provide more value to their customers. They appear to be better at overcoming the common hurdles of disruptions to workflows, upskilling their developers, and aligning their development and operations teams.

Dive a little deeper into the survey results behind the report, however, and three complications emerge, which may hinder how quickly DevOps is adopted in Financial Services.

Protecting Sensitive Data

Financial Services, like Healthcare, is subject to stricter regulations than most regarding the privacy of data. Given increasing concerns and legislation around protecting personal data, the survey asked if production data used in development, test and QA environments should be masked or de-identified. It then asked if the data was indeed modified in such a way.

64% of all respondents said data should be modified, and 55% said all data was, indeed, masked or de-identified. The gap is a small concern, but at least the respondents were aware of the necessity for modifying data and may well be working to resolving it.

Focus on the Financial Services sector alone and a different picture emerges: 69% of non-enterprise respondents (those with less than 1,000 employees) agreed that data should be modified, and 69% also said that data was masked or de-identified. There is probably not a perfect correlation between the answers, but it's a good sign.

Turn to enterprises, however, and while 83% agreed that data should be modified, only 49% said that it was. Maybe there's an issue with legacy systems, or the complications of masking and de-identifying production data when a lot more developers need access to it, but this is a red flag that enterprises in Financial Services should be aware of.

Change Approval Board Delays

In the latest survey, change management was included to discover how database changes are proposed, assessed and reviewed. Across all sectors, 38% of respondents stated approval was required from a Change Approval Board (CAB), but this rises 46% for those in Financial Services.

This is probably due to a combination of legacy practices ("We've always done it this way and we see no need to change" mentality), complexity (Financial Services often have more complicated systems, and more care needs to be taken when deploying changes), and risk management (the cost of downtime due to failed deployments is far higher in Financial Services).

There is a caveat here. Even though just over a third of total respondents to the survey reported the use of CABs, there was no evidence that they succeed in reducing the number of code defects. While their main purpose is, understandably, to be a safeguard, the only effect that emerged from the report is that they increase the lead time for changes.

Canceled Deployments

Deployments that are interrupted at a late stage often have a negative effect on the software development process. They can either cause re-work for teams if the deployment is sent back for changes after nearly making it to production, or have a knock-on effect in the deployment pipeline for other changes.

That said, the Financial Services sector is the most likely to report deployments that are canceled late, with 34% of respondents canceling 2% — 10% of deployments, and 13% canceling 11% — 25% of deployments.

The problem isn't just the cancellations because the report found that respondents who reported more cancellations late in the software development cycle were also more likely to report a higher percentage of deployments to production which cause defects that later require hotfixes.

Summary

The Financial Services sector has long been the front-runner in adopting DevOps. It's notable that while the Database DevOps Report found that the barriers to introducing DevOps are the same for every industry sector, Financial Services have been the most able at overcoming them.

Shortfalls emerge, however, when it comes to protecting personal data, relying on Change Approval Boards, and cancelling planned deployments. These are areas that the sector should focus a little more effort to ensure they stay ahead of the game.