Database automation: The DBA’s DevOps dilemma

In our recent webinar, How to Build the Business Case for Database DevOps, we learned from live attendee polls that database administrators (DBAs) can be one of the most difficult stakeholders to sell on the value of database DevOps and release automation. But securing buy-in from the professionals who may see the most changes in their daily work – and who sit at the crux of the database schema management workflow – is critical to getting your database DevOps initiative off the ground and accelerating.

DBAs, primarily focused on operations, performance, and stability, tend to get blamed for data loss and downtime. And when a developer’s code changes cause issues in production, DBAs have to trudge through frustrating, unpleasant conversations with devs to sort the issue. Faced with the extension of CI/CD pipeline automation to the database level, they tend to have two competing reactions. On the one hand, automation can free them from time-intensive manual code reviews.

But on the other hand, they’re hesitant of relinquishing control and changing processes – because change can bring risks, such as the risk of data loss and downtime. So they’re cautious about removing manual oversight and allowing developers – who tend to embrace change and risk – to deploy their own changes.

When intrigue meets concern, the result is hesitation. And hesitation is the enemy of innovation, progress, and scale.

Why might DBAs hesitate to embrace database DevOps?

That’s a great question – why don’t you ask them? Seriously. As you work towards org-wide enthusiasm, it’s important to have open and honest conversations in which you serve as an empathetic sounding board. Let DBAs know you’re trying to better understand their pains – so you can solve them – and also their aspirations – so you can leverage automation to give them time back to pursue innovations.

But you don’t want to walk into this conversation blind, so here are a handful of reasons DBAs can shy away from database DevOps and CI/CD automation.

It’s new and different

Accustomed to process and reliability, many DBAs are committed to their manual processes because they’ve working well enough for long enough. Simultaneously, they’re unfamiliar with DevOps and the level of automation that has taken root and grown rapidly on the application development side of the industry.

Like any professionals, DBAs may resist change, especially if they have been successful with their current methods. They may see no immediate need to change their workflows. In other instances, DBA leaders nearing the end of their careers may want to continue their focus on current initiatives rather than cue up a process change they may not be around to see through.

As with any new initiative, there can be hesitation to change and try new things. With so much business value riding on these processes, it’s understandable.

They’re worried about security, control, and risk

When your job is to oversee data integrity and security, the terms “new” and “automation” can be cause for alarm – changes like these can introduce unknowns and vulnerabilities. Taking their hands off the wheel to trust automation can require an emotional leap as well as a long list of technical checks and balances to build confidence.

DBAs are used to having a high degree of control over database changes and may fear that automation could lead to mistakes or unauthorized changes. They may be risk-averse and prefer manual oversight, even if it means they deal with a lot of tedious back-and-forth with developers on change requests.

The database is too critical to the business to change anything

The above concerns can be magnified when the database is at the very core of the business function – for instance, an online store that drives the majority of the revenue or a SaaS server that supports critical capability to customers or could even pose a safety risk.

The legacy system is too complex, too ingrained

For some DBA teams, the conversation about database DevOps and automation struggles to even get off the ground when faced with the headwinds of old, outdated, complicated systems that are resistant to change. If the existing environments aren’t well-suited to DevOps practices and tools, there’s another huge decision to make. Do they face the extremely daunting task of trying to make the existing systems work or take on a migration to new systems that support DevOps automation?

Databases can be complex, and automating database processes requires a deep understanding of both the database technology and the DevOps tools. Some DBAs may perceive this as too complex or time-consuming to learn. It may push them out of their comfort zone to learn how to version control their scripts, for instance, because they’re not a developer. Yet it’s a key component of database DevOps automation.

They’re afraid they might risk quality

In traditional manual database schema updates, a DBA personally reviews, tests, and validates changes. For some DBAs, letting go of those reins puts code quality, stability, reliability and uptime at risk – and thus, the whole SDLC. While they understand the slowdown their processes create in the pipeline, they’re afraid they will have to choose between speed and quality.

The organizational culture’s not there

DevOps is a culture. It’s not a tool, a process, or a metric. The most successful DevOps organizations became that way because they were aligned and bought in, culturally, across the entire organization.

In a registration poll for the “How to Build a Business Case for Database DevOps” webinar, most respondents were still in the first two stages of DevOps maturity:

• Initial: Traditional environment with Dev and Ops separate
• Managed: Beginning stages focused on agility w/ initial automation

While only about a third fell into the three categories at the more mature end:

• Defined: Org-wide transformation begins with defined process
• Measured: Process & automation with continuous improvement
• Optimized: Achievements are visible, team gaps disappear

If an organization does not prioritize or support DevOps and automation initiatives on a broad level, DBAs may be hesitant to adopt them in their workstreams.

They’re worried about job security

It’s hard to fault someone for thinking automation of their core duties could put their job at risk. Why employ someone to manually review database changes across hours, days, and weeks when automation tools can get the task done in seconds, minutes, days?

The problem with that thinking is that DBAs were never supposed to be spending all their time on manual release requests. The velocity, acceleration, and size of software developments and corresponding database updates has exploded with the sprawl of online experiences, SaaS, and the use and proliferation of data in general.

Software development is moving faster every day. Therefore, automation isn’t a job-stealer but a necessary tool in the box for the next generation of DBAs who will instead be freed up to focus on strategic priorities that can drive significant business impact.

The concern for job security can also be countered when you consider that other DBAs are concerned that…

There aren’t enough resources available to make the evolution

Implementing DevOps and automation can require time, training, and investment in new tools and technologies. Organizations with limited resources may struggle to make this transition. But as automation takes hold – team by team, database by database – the DBAs unleashed from, their manual code reviews can redeploy to support automation – and whatever innovations they dream up next.

Despite these hesitations, the benefits of embracing database DevOps and automation – such as faster and more reliable deployments, improved collaboration, and the ability to focus on strategic tasks – often outweigh the initial concerns.

But these concerns do make it crystal clear: To successfully implement these practices, organizations should provide training and support for DBAs, address security and quality concerns, and gradually introduce automation to ensure a smooth transition.

Freeing “release engineers” from the tedium of manual updates

During the “How to Build the Business Case for Database DevOps,” SVP of Technology Operations/Enterprise DBA Leader, Jonathan Nhou, explains how he saw DBAs become, essentially, “release engineers.” That is, instead of living out their full duties in database administration, they spent all their time receiving, reviewing, packaging, and deploying releases.

With database release automation, many database teams go so far as to allow self-serve deployments. If the code change passes the automated quality checks and governance elements, it can make it to Production in no time. If there is an error in testing stages, the database DevOps tool rings an alert so DBAs can pounce on the issue before it reaches Prod.

But in the meantime – when 99% of deployments go off nearly instantly, without a hitch – DBAs are free from the manual tedium of reviewing every single individual update request. With their newfound freedom, they can be the best DBAs they can be by shifting their expertise to impactful infrastructure, process, and technology innovations.

At its core, the role of the DBA can shift from reactive to proactive, simply by handing over the bulk of the manual review work to automation capabilities.

The joys of the proactive DBA

So what is the proactive DBA to do?

With database schema updates automated and additional DBA-level automation coming from cloud database vendors, DBAs suddenly have a lot more time to focus on more exciting projects. Driven to provide value and flex their technical muscles, proactive DBAs can dive into other aspects of the database to discover, improve, and launch new initiatives in areas such as:

• Cost optimization
• Analytics and monitoring
• Security and compliance
• Data integrity, quality, availability, and reliability
• Performance and scalability

They can also look to company culture and communication for ways to improve collaboration and create healthier, more productive teams. Along the way, they’ll also have the bandwidth to pursue professional development that enhances the company’s operations while progressing the DBA’s career. Similarly, DBAs can spend more time training others on best practices, proprietary methods, and the latest advancements to upskill teams and lock in competitive advantages.

But what they won’t have to do is continue to juggle the burnout-inducing off-hour and weekend work typical of the old manual processes, because developers can safely and reliably push their own change scripts without error. Self-serve deployments for developers can be automated with sufficient guardrails to catch bad changes early on while training developers on allowable database changes. Unburdening the DBA from running developer script and nearly eliminating errors that require urgent remediation is a win-win for DBAs – plus a huge boost to the organization’s overall DevOps momentum.

Bring DBAs – and everyone else – into the DBDevOps mindset

Of course, DBAs aren’t the only stakeholders you’ll need to appeal to in order to get database DevOps liftoff. To craft a compelling story for other stakeholders – C-suite, leaders and managers, software teams, and more – you need to understand how they think and what makes their jobs easier.

That’s exactly what’s discussed by Liquibase’s VP of Customer Success, Ryan Campbell, and a national mortgage company’s SVP of Technology Operations/Enterprise DBA Leader, Jonathan Nhou, in this on-demand webinar: How to Build the Business Case for Database DevOps (Get org-wide buy-in for database release automation).

Check out the recording in which Jonathan details his success in spreading database DevOps throughout his org. Then put his advice to action for your own benefit with this plug-and-play slide deck: Build your own business case (Slide template for DBDevOps buy-in).