Attention CIOs: Database administrators are in trouble.

The same experts CIOs have relied on for years to protect critical business data, address performance issues and review changes before they are deployed — DBAs — aren't telling their IT leaders how difficult their lives have become.

DBAs have just barely kept their heads above water while Agile, DevOps, continuous integration and continuous delivery transform application development processes and speed software delivery.

Meanwhile, CIOs have pointed to their increases in application releases as evidence that adopting Agile and DevOps were great choices, but they don't always involve DBAs in that process.  DBAs can't tread water much longer, and they'll take the entire IT organization down with them.

Falling behind

It shouldn't be altogether surprising that DBAs would hesitate to report they're falling behind as more and more releases need their attention. After all, they've been the ones telling the rest of the IT organization to keep their hands off the database.

But now database schema change workloads are becoming too much to handle.

"While the age of automation and cloud may be upon us, an increasing number of database managers and professionals report that they are being mired in manual processes," according to a 2015 IOUG Survey on Database Manageability report. Of the 301 data managers and surveyed, "more than one-third cited this as a challenge, up a dramatic 162% from four years ago."

Four out of five application updates require a corresponding database change, and the backlog of change scripts means the applications the rest of the business or its customers depend on are not released on time.

As Redmonk's James Governor puts it, "developers have driven the change. We've seen this in a number of areas, whether it's data management or databases, where the developers said, 'We're not going to wait for the DBA anymore.'"

That's obviously no good for the business' bottom line, but missing release dates also becomes an internal morale problem incumbent upon CIOs to address.

DBAs' unbearable workloads and longer hours are making them unhappy workers. How often are DBAs the last to leave the office on Friday afternoon? Do they ever leave? At least 20% of DBAs own up to working more than 40 hours a week, according to the Bureau of Labor Statistics. But talk to any of the remaining 80% and they'll more than likely admit they're still on call 24/7.

Intervening to make sure they have the tools they need to succeed is the right first step to take in order to make sure they're working efficiently and aren't overworked. Equipping DBAs to better handle the influx of changes will also help CIOs avoid the time-consuming and ultimately costly process of adding more people to the team — or replacing DBAs who burn out and leave.

Automation is the answer

The rising tide of change scripts DBAs see also means increased likelihood of a bad change finding its way into production, which can result in poor application performance, prolonged application downtime or data vulnerability issues. Should a particularly poor change slip past the DBAs, it could bring down the database altogether, grinding business to a halt and leaving customers frustrated, while the already-overworked database team rolls back to a previous version and painstakingly combs through changes to find the issue.

Potentially even more damaging, poorly-written database changes can open security vulnerabilities in applications. DBAs are manually checking thousands of lines of code before applying changes to the database, and probability suggests that security will be compromised eventually. Intervening and solving the manpower and efficacy problem on the database team will help CIOs avoid the damaging impacts of losing confidential data to a breach.

So what does an intervention look like? If a CIO has implemented DevOps tooling in other parts of the delivery pipeline, the solution to their DBAs' problems may be obvious — automation.

Tools exist that can help DBAs automate a significant portion of their change management workload. While nearly all application releases require a database change, the vast majority of those changes are simple and don't really require a DBA's full attention. Automation tools let DBAs write a checklist for schema changes and will only flag poor changes for their moderation. The rest will be automatically checked, approved and pushed to the next environment.

DBAs can take this automation a step further to enforce compliance and security requirements as well. This means that changes potentially introducing security flaws (like elevated user permissions) are automatically escalated for DBAs to review.

DBAs might be telling CIOs that everything is fine with the database, but privately they're singing a song of pain. Automating database changes is becoming increasingly common, and taking a few minutes to intervene and talk to the database team about lightening their workloads could pay off tenfold later on. Otherwise, the pace of software delivery will overwhelm DBAs altogether and stall the business, giving customers reason to look elsewhere.