How to encourage DBAs to embrace DevOps, rather than fear change
How do we help Database Administrators (DBAs) embrace DevOps in a way that can be really productive and part of a rich DevOps team that delivers value to customers quickly and continuously?
That’s an important question to ask right now because there’s a common view among DBAs that DevOps isn’t for them. They’re responsible for documentation and maintenance and deployments, they have internal customers, and they serve internal requests.
Moving from a bureaucratic, inward-facing structure to a DevOps approach that focuses on end users requires a real shift in perspective, motivation and how success is measured. So let’s look at each of those areas in turn.
Change their perspective
Before trying to convince DBAs to change the way they work with others and motivate them to really embrace DevOps, I would find out a few things about how they see things now. For example, what do they see their role is? How would they describe the value they provide? Do they see themselves as a kind of protector of data, or is it something else? I would also ask them who think their customers are.
That last question is the really critical one because when I started out as a DBA longer ago than I care to remember, my then CTO saw our customers as the other units in the business. When we start doing DevOps, that view needs to dramatically shift to serving the needs of end users instead.
The problem here is that many DBAs have a view that they’re workers within a silo of IT engineers, and they have internal customers and serve internal requests. They’re part of a cost center and their value is to fulfil requests from other people. It’s a bureaucratic structure, where the DBA is responsible for documentation and maintenance and deployments.
When everyone is focused on the end users, the role of the DBA moves to a position where they’re in a cross-functional team and their goal under DevOps is to automate as much as possible, and deliver value to end users more quickly. Instead of working in siloes, they work with other team members to solve problems, and introduce automation with tools that aren’t just the typical tools people inside the DBA team use.
Make no mistake here. In the DevOps world, the goal isn’t that DBAs go away, but that they become database specialists who have fewer manual tasks to do, and can help design architectures to deliver value to the customer more quickly. I think that’s a much more interesting and rich role for people to take on.
Give them a new motivation
We need to talk a little bit about motivation because just changing who DBAs view as their customer isn’t necessarily going to motivate them. Now one thing that can be very motivating to people in IT is reducing the parts of their job that are painful, and the great pain that comes out of deploying changes to production is something that a lot of DBAs bond over.
It’s often the case that changes come over from a development team or an outside vendor, and it’s left to DBAs and IT staff to review a massive amount of code. They’re then held responsible for the quality of the changes which they deploy (and which generally they didn’t write), and these changes frequently break.
The deployment scripts themselves often don’t execute successfully because there’s been some schema drift between the production environment and the environments it was tested with. If something goes wrong after the deployment, there’s also generally no rollback script, and simply reverting the database to an earlier point in time may well impact far more users than the ones negatively affected by the change. So there’s a ton of pain when it comes to deploying software.
The promise of finding a way to eliminate that pain through automation, streamlined processes and smaller, more frequent releases can be a big motivating factor. You’re also going to get more value from DBAs with a culture where you don’t have release pain, where changes can flow out and your customers can see new features sooner and take advantage of them faster. All without DBAs and IT engineers having to suffer, lose sleep and be fixing things non-stop after every release.
The motivation here is about providing more value, not DBAs automating themselves out of a job, because there’s still going to be plenty of work for database people in a DevOps world. The higher the rate that you deploy changes in a world without deployment pain means you need a ton of expertise in terms of figuring out how do we deploy things and automate the release cycle and continuously improve it.
Measure their success as part of the team
What does success look like and how do we measure DBA success in a DevOps world? This is a really important question and in a more bureaucratic non-DevOps structure, we typically have a silo with developers and a silo with DBAs. Here, the traditional way to measure success is to judge DBAs on the stability of production and other environments, and developers on release frequency and release tempo.
Unfortunately, this just creates a wall of confusion. Developers are throwing changes over the wall as fast as they can because they’re measured on getting releases out. The DBA and IT staff are resisting them because they’re being judged on stability. Having these two competing interests actively inhibits collaboration and communication because we’re measuring people in a way that doesn’t work with DevOps.
For DBAs in the DevOps world we need to measure their performance on release frequency as well as production stability. And it’s the same thing for developers. They need to be just as responsible for stability as they are for frequency. Aligning these things and saying these are our shared goals, we’re part of the same team, will in turn help you change the perspective of DBAs and motivate them in a new way.
To find out more about how DBAs can embrace DevOps and deliver value quicker while keeping data safe, visit our solutions pages.
Read next
Blog post
Challenges to Implementing Database DevOps: How Do You Get The Data Team On Board?
I think this is my single favorite question that came up at the recent panel discussion: How do you get DB folks who just go in and make changes to understand they need DevOps, source control, change management, etc.? There’s a lot to answer in this question, however, to keep this down to a blog
Blog post
How Do You Overcome "We Have Always Done It This Way"?
I work in computers and my son works in manufacturing, but both of us loathe a single phrase: We have always done it this way. Please allow me to be clear on this. If you can back up this statement with “Because…”, and you list out valid points, even if I disagree with them, we’re
Download the free report
The 2021 State of Database DevOps
Now in its fifth year, with over 8,000 survey participants to date, this industry-leading report will help any team interested in adopting or improving their approach to Database DevOps, no matter the choice of platform.
You may also like
Blog
What is Test Data Management (TDM)?
Blog