I love Monarch butterflies. They’re big, colorful, and are only seen twice a year where I live in Texas. When traveling north to Canada from their winter homes in Mexico, they experience many generations. The butterflies go through the larval to adult insect phases every few hundred miles. This change helps propel them forward to eventually returning to their winter home. Database administrators (DBAs) are very similar in that they have a specific task (Sentries of the Data!), yet need to adapt to new technology and tools. Sometimes, that is an elementary shift when moving from one version of a database to another. Things become more complicated when migrating to a completely different database or data store (e.g., RDBMS to NoSQL). Throughout these shifts, we have been very bad to our DBAs. Application Development teams have adopted new methods and architectures. Agile increased the rate of change that DBAs must handle. With DevOps and microservices, the rate of change has increased exponentially… without much concern for how our DBAs handle that increased rate of change. Though companies have invested heavily in new ways to create software faster, they have paid lip service (at best) or completely ignored their database administrators (at worst). This has happened to our detriment, as it has only served to sap the benefit of new development methods and delivery tools.

Fuel for Database Administrators

Much like flowering plants feed the adult Monarch, and milkweed feeds the larval Monarch, we must make sure our database administrators have what they need to be successful. This includes both education and tools. IT management must make it a priority to improve the effectiveness of DBAs and their quality of life. Programs must be created and funded to retain DBAs and help them evolve. If not, those DBAs will find more progressive companies and take their knowledge and experience with them. Programs can take a “brown bag” approach, where development, cloud, and DevOps teams can meet in a casual session with database professionals to describe what they do and how they do it. If the database professional can understand the reasons why the company adopted DevOps, they can better align themselves with those goals. Of course, that begs the question: How do I evolve as a DBA to support these new initiatives?

A New Way of Thinking

Database administrators must change how they approach their problem space. Typically, a developer thinks about the system of engagement while the DBA things about the system of record. However, both ways are self-limiting. In a time of hyper-competitive threats and changing business models, we cannot be locked into any one way of thinking. Much like the full-stack developer, we need a full-stack DBA that understands that data safety and security is just as important as data delivery. This new way of thinking must also be adopted by development. DBAs fill an important role for the organization, one that cannot be easily brushed aside because it is inconvenient. Developers must understand that DBAs not only protect a company’s data (its most valuable asset!) but also can be a resource for developing better applications.

Put It into Action

First, IT leaders must help database administrators start thinking in terms of “as a service” instead of discrete tasks of changing database schema to support a release or patching the database server. These tasks add little value to the customer experience, but must be done. Instead of finding a way to become a faster SQL reviewer, the DBA must look for ways to eliminate the need to review SQL change scripts. After all, do we perform a code review prior to a production push? No! We’ve already done that in development. DBAs must consider how they can deliver their value to the company via a service that is most definitely self-service. Second, DBAs must have their skills enhanced. Every single new technology released today has some sort of programmatic API, and the good ones have plenty of Python examples. To offer their value as a service, DBAs must be able to write code to tie their systems in with the existing application delivery pipeline. Instead of manually responding to tickets, DBAs must offer their partners, their customers, the ability to perform a step themselves and avoid creating the ticket in the first place. Third, DBAs can no longer be tied to the platform. The idea that one is an Oracle DBA or SQL Server DBA is over. DBAs’ value is not in their ability to understand Oracle, but to understand what the data means to the business and the value it can unlock for development teams and others. Besides, all DBAs still Google error messages—but only the best ones know which result to try first. Finally, IT leaders must do their utmost to retain DBAs. Recent CS graduates have little to no interest in becoming a DBA. But there still needs to be a single team ultimately responsible for the data’s security and safety, so we will need this role. Until that stops, IT leaders must make certain their DBAs’ quality of life is high and burnout is kept in check.

Do It for the Best Reason

By educating, encouraging and investing in our database administrators, IT leaders can double-down on their current investment in DevOps, cloud, microservices and other areas. Streamlining processes that overwork our DBAs will increase their work satisfaction and retain these brilliant and necessary employees. In turn, this creates a virtuous cycle that delivers software faster while maintaining the necessary tribal knowledge in a department and company. Robert Reeves is co-founder and CTO of Datical, a provider of database release automation software.