Be the DBA of the Future! – InApps 2022

Earlier this year, Datical released results of a survey on the challenges with digital transformation. What was not at all surprising? The database change process is slowing down application releases. What was absolutely mind blowing, however, was how clear the problem is to the rest of the company, not just to you, the database administrator (DBA).

Ninety-one percent of DBA respondents believe that the database change process is slowing releases. And 90 percent of application development managers stated the same. Never have I seen application development teams and the DBAs agree on something so clearly. Sure, maybe agreements that the Star Wars prequels were a missed opportunity and that food in the breakroom is a good idea. But to have such agreement on a technical issue? Absolutely amazing.

So, What Do We Do about It?

Now that everyone in IT, including the CIO, realizes the significance of the challenges associated with the database change process, DBAs need to take part in the creation of the solution. And that solution must be able to handle the rapid increase in the number applications and the subsequent smaller, more frequent releases.

To be successful and add value to their company, DBAs must align themselves with the rest of the application teams: development, testing, and DevOps.

DBAs Must Partner with Development to Align Interests

Development thrives on change — it’s their job. Of course, change can be the enemy of stability and we all know stability is a friend of the DBAs.  So how can development and DBAs achieve alignment in what seems to be an environment of competing interests?

Development requires near-instant feedback on changes as early as possible to deliver the RIGHT kind of change. This feedback increases stability. To provide this feedback, developers use unit tests to know at build time if their new code has failed. Thus, waiting until a database change reaches the production tier is unacceptable. DBAs need to provide feedback on proposed database changes earlier in the systems development lifecycle (SDLC). Waiting until a support ticket hits your team to review a change is not the solution; think proactive, be responsive.

Help Testers Go Faster, Safely

The increase in the number of applications and the frequency of their releases will also create a similar — yet more intense — pain for the testing team. Their use of automated test tooling has increased dramatically. Testing teams are leveraging automation tools to provision ephemeral environments and deploy release candidates. However, their reliance on a manual database change process is slowing them down. By definition, testing teams deploy more applications than the production teams. After all, not all release candidates will pass testing. The solution is not to hand over database deployment tasks to the testing team to do it themselves. Think speed AND safety. DBAs need to help the testing teams solve this problem through automation. After all, when the testing team deploys a release candidate, they are not only testing the application itself, they are also testing the deployment process. That is, of course, if they are the same mechanism.

Bring DevOps to the Database

Finally, DevOps teams are moving your company to lights-out, fully automated deployments. As they increase the rate of change for the non-database parts of the application stack, your life will become increasingly more difficult. Manually reviewing database data definition language (DDL) deltas in a compare screen does not solve this problem. DBAs must take advantage of the infrastructure the DevOps teams have built. Otherwise, we will continue to have a bimodal change process where the application deployment is slowed by the database change process.

All Together Now!

For too long, the data team has been siloed and kept separate from the rest of the company. The only way to get a database change done was to create a support ticket and expect it to be completed within the service level agreement (SLA) time frame. That sort of thinking has gotten our DBA teams into the mess of working nights and weekends or adding more trained DBAs to the team. Neither of those options will result in long-term success.

By aligning DBA needs and expectations with development, test, and DevOps teams, we can solve the problems that get created when the database change process slows our entire application release process.

What to Do Now?

When it comes down to it, times have changed. We no longer live in a world a where DBAs can comfortably keep up with the rate of application changes. All signs now clearly point towards the need to modernize the database release process and finally remove database deployments as a barrier to delivering application innovation. The time for change is now.

So ask yourself this: Do you want to be a DBA of the past? Do you want to spend even more time reviewing every change in every change script? Do you want to work more nights and weekends? Do you want to spend more time on 3 a.m. conference calls, crossing your fingers and hoping your database deployment does not fail, preventing the application from going live?

Or do you want to spend less time on things you don’t want to be doing (like reviewing change scripts) and more time on things that move the business forward (like that getting the database finally upgraded to the current version)? Do you want to be able to push your database deployment to Production at 3 p.m. on a Wednesday instead of 3 a.m. on Saturday? Do you want to spend more time at little league games, dance recitals or on date nights? If you’ve answered yes, then embrace automation and be DBA of the future.

To see more on how the database release process impacts digital transformation, check out the report conducted by IDG and commissioned by Datical.

Feature image via Pixabay.