Automation Isn’t Accountability: Why the DBA Still Owns the Outcome on IBM Z
While there is real value in automation and much promise in AI, human expertise will still be required—because humans will still be accountable, Craig Mullins observes
There is a growing expectation that database management is becoming “self-driving.” With advances in automation, machine learning and AI-driven tooling, we are told that the database can tune itself, optimize itself and in some cases, even fix itself.
For organizations running critical workloads on IBM Z with Db2 for z/OS, that message can be appealing. After all, these environments are complex, workloads are demanding, and experienced talent is not getting any easier to find. But let’s be clear about something that marketing glosses over. Automation can execute tasks. AI can recommend actions. But neither can assume responsibility.
And in database management, responsibility is everything.
The Push Toward ‘Hands-Off’ Database Management
If you look at the direction of database tooling, the trend is unmistakable. We are witnessing a significant shift toward the “autonomous” database, where the focus of modern features is squarely on the reduction of manual intervention. The days of the DBA spending hours on mundane, repetitive tasks are slowly being eclipsed by sophisticated internal mechanisms designed to handle the heavy lifting of system optimization.
At the forefront of this evolution is the automation of statistics collection, which ensures that the optimizer always has a clear view of the data distribution without requiring a scheduled job or manual trigger. This is further bolstered by the rise of intelligent indexing engines that provide recommendations based on actual usage patterns rather than theoretical modeling. Furthermore, we see the emergence of self-adjusting buffer pools and advanced workload management enhancements that allow the DBMS to dynamically reallocate resources in real-time as application demands fluctuate.
Even the way we execute SQL is being transformed through transparent query acceleration and automated query rewrite capabilities, effectively masking inefficient code with sophisticated internal logic. While these advancements certainly ease the operational burden, the savvy data professional knows that “automated” does not mean “unattended.” Even as the tools get smarter, the underlying requirement for a deep understanding of database theory and a watchful eye on performance remains as vital as it has ever been.
On IBM Z, many of these capabilities have existed in some form or another for years, but they are becoming more sophisticated. And increasingly these tools are being marketed as a path to reduced DBA involvement.
The pitch is simple: Let the system handle the routine work so your team can focus on higher-value activities. That’s a reasonable goal! But it becomes a problem when “reduced involvement” turns into “reduced understanding.”
The Accountability Gap
Here’s the question that rarely gets asked: When automation makes a bad decision, who owns the outcome? But it is an important question to ask because bad decisions do happen. Consider, for example:
An automated RUNSTATS executes at the wrong time and destabilizes access paths.
A recommended index is implemented and increases overall I/O instead of reducing it.
A query rewrite improves one workload while degrading another.
A buffer pool adjustment causes unexpected contention.
None of these situations are hypothetical. They are the kinds of things that can happen in real-world Db2 for z/OS environments. And when they happen, the system doesn’t step forward and take responsibility. Real human beings have to take responsibility, diagnose the situation and build a remediation plan. This can be DBAs, operations personnel and application development teams, depending on the situation. Failure to take accountability, and then action, means that the business feels pain.
In other words, automation does not attend the post-mortem meeting.
Why Experience Still Matters
One of the persistent myths surrounding AI-driven database management is that it can replace experience. It cannot. And that is because automation lacks context. It may not understand things like:
- The business importance of a specific workload
- The service level agreements tied to that workload
- The ripple effects of change across interconnected systems
- The history of prior issues and “lessons learned”
- The political realities of downtime in your organization
Automation and AI typically operate on patterns, probabilities and rules. Now don’t get me wrong; that is useful, but it is not judgment. And on IBM Z systems, where workloads are tightly integrated and highly optimized, judgment is often the difference between a safe change and an outage.
The most dangerous database decisions are often the ones that look reasonable in isolation.
The Risk of Blind Trust
The real danger is not automation itself but over-reliance on automation. When organizations begin to trust the system without verification, bad things can happen. Skills begin to erode, and given enough time, your DBAs become operators instead of practitioners. Visibility decreases, causing fewer people to understand what is happening “under the covers.” This makes recovery harder because when something breaks, fewer people know how to diagnose it.
This is particularly risky in long-lived Db2 for z/OS environments, which are quite common as Db2 was first shipped in 1985! The stability of these older systems and applications is often the result of years of careful tuning and institutional knowledge. And an outage can result in significant financial pain.
You don’t want to discover that vital know-how is gone the first time something goes wrong.
A Better Model: The Augmented DBA
The right way to think about automation is not as a replacement for the DBA, but as an extension of the DBA. This keeps a knowledgeable human in the loop.
Automation works best when it is applied to tasks that benefit from consistency and repetition. It can handle routine activities with precision, surface potential issues earlier than a human might notice and generate recommendations that would take far longer to assemble manually. It can also accelerate analysis, helping DBAs move from problem identification to resolution more quickly.
But automation does not mean the DBA steps aside. It means the DBA shifts focus.
Human oversight remains essential where decisions carry risk or long-term impact. Structural changes still require careful evaluation. Performance tuning still demands an understanding of trade-offs across workloads. And coordination across applications, teams and business priorities still requires judgment that no automated system possesses.
In environments running on IBM Z with Db2 for z/OS, this distinction matters even more. These systems deliver their reliability and scalability through layers of capability that are powerful but not simple. Automation can assist in managing that complexity, but it cannot replace the experience required to navigate it safely.
The goal, then, is not to remove the DBA from the process, but to elevate the role. Let automation do what it does well while the DBA remains responsible for understanding, validating and ultimately deciding what changes are made and why.
On IBM Z, this balanced approach is especially important. These systems are designed for reliability and scale, but they achieve that through complexity that cannot be fully abstracted away.
What DBAs on IBM Z Should Be Doing Now
As organizations increase their use of automation and AI, the goal should not be resistance, but disciplined adoption. That begins with understanding. Enabling automated features without knowing how they work, or what assumptions they rely on, is a recipe for problem creation. DBAs need to take the time to learn what is happening across the environment and in fine detail, not just that it is happening.
At the same time, clear boundaries should be established for where automation is allowed to operate independently and where human review is required. Not every action carries the same level of risk, and treating them all the same can lead either to unnecessary caution or unnecessary exposure. Thoughtful guardrails help strike the right balance. And only skilled practitioners, like DBAs, are capable of installing appropriate guardrails.
It is also important to focus on outcomes rather than activity. The successful completion of an automated task does not guarantee a beneficial result. DBAs must continue to evaluate performance, access paths and workload behavior to ensure that changes are producing the intended effects.
Staying engaged with the system remains critical. Even as automation takes on more responsibility, DBAs should continue to analyze trends, monitor behavior and understand how workloads evolve over time. Disengagement is where risk begins to grow.
Finally, investment in skills cannot be neglected. Automation is most effective in the hands of knowledgeable professionals who can interpret its actions and intervene when necessary. On IBM Z running Db2 for z/OS, expertise is not optional. It is the foundation that allows automation to be used safely and effectively.
In other words, automation should amplify expertise, not replace it
Responsibility Doesn’t Automate
There is real value in automation as well as real promise in AI. But neither changes the fundamental truths about database management on IBM Z:
You can automate execution. You can accelerate analysis. You can even improve consistency. But you cannot outsource responsibility.
And when something goes wrong, and it inevitably will, it is still the DBA who is expected to understand why, fix it and ensure it doesn’t happen again. That hasn’t changed. And it isn’t going to.