Operations | Monitoring | ITSM | DevOps | Cloud

A constant challenge for many development teams is how to include test data management in the development process. Testing with consistent, realistic and compliant datasets, and bringing the database into CI and DevOps pipelines, has been shown to catch data-related issues long before they reach customers. The result: an increase in efficiency, a reduction in costs, and an improvement in the quality of software releases, enabling value to be released to customers faster.

In this series of blog posts, we speak with database professionals from Financial Services organizations around the world to better understand how DevOps is shaping the sector. On the way, we dig into key current factors including the rise of technology upstarts in fintech and insurtech, the speed of digital transformation and the ever-increasing threat of cyberattacks.

For the last five years and more, there’s been an elephant in the room when it comes to the way businesses and organizations collect, manage, store and analyze data: PostgreSQL. An open source relational database that offers the kind of enterprise advantages that have already attracted businesses like Netflix, Instagram and Spotify according to the tech stack intelligence platform, StackShare.

In this series of blog posts, we speak with database professionals from Financial Services organizations around the world to better understand how DevOps is shaping the sector. On the way, we dig into key current factors including the rise of technology upstarts in fintech and insurtech, the speed of digital transformation and the ever-increasing threat of cyberattacks. First up, we speak with Hamish Watson, DevOps Alchemist and Managing Director at Morph IT Consulting.

In this series, we’ve been exploring the different layers of business value you can gain from deploying software more frequently. We’ve already looked at the hard costs you can save, and the valuable developer time you can recoup. But that’s not the end of the story. Not by far. Picture an iceberg. The top, the visible part, is those hard costs. Just beneath the surface is that time that can be gained by redeploying wasted time to projects that matter.

As part of a recent Redgate Summit which focused on digital transformation and data modernization, I was fortunate enough to be able to interview Pramod Sadalage, a Director at Thoughtworks. There, and I’m quoting here, he enjoys the rare role of bridging the divide between database professionals and application developers.

The first post in this series introduced the idea of the different layers of value that your business can gain from frequent deployments and focused on the hard costs you can save. We’re looking at the role the database plays here because it’s the most complicated part of the process and it’s difficult to hit aggressive KPIs and goals when your teams are burdened with process bloat due to mistake-prone, manual work.

We’ve written a ton of content about how to unlock the value of frequent deployments for your database as well as applications, from improved coding patterns to strategies for architecting smaller deployments. But the multi-million-dollar question for you and your business is something else entirely: what is the real business value of frequent deployments? That’s the question I’m going to address in this series of three posts.

Digital transformation seems to be on the to-do list of every organization at the moment. Alongside it, DevOps is one of those buzzwords that gets lumped in, with some vague intention of having things automated. If you’re championing a DevOps implementation in your organization, or wish to see where your current processes measure up against your peers, read on.

Database DevOps has come of age. Now seen as a key technical practice which can contribute to the successful implementation of DevOps, it stops the database being a bottleneck and makes releases faster and easier. Conversely, perhaps, the automation and audit trails it introduces can help to protect personal data within databases and make compliance part of the same process rather than an additional time-consuming step outside it.