There is no denying that database administration requires a bevy of technical know-how.
The DBA is the information technician responsible for ensuring the ongoing operational functionality and efficiency of an organization’s databases and the applications that access those databases. As such, DBAs are tasked with designing, implementing, and administering databases, but also performance monitoring, backup and recovery, capacity planning, data movement, ensuring availability, storage management, and more. Not to mention, the on-going interaction with developers in terms of SQL performance, design reviews, and migration of code and database objects from test to production.
Furthermore, it is undeniable that DevOps is increasing the speed of development, which therefore speeds up DBA practices and procedures. And cloud computing is also significantly impacting the role of the DBA.
As DBAs embrace their traditional duties and digest these changes it is typical for them to think about the technology aspects of their job. For example, the tooling and integration required to provision databases for developers and implement database structure changes rapidly and correctly. Yes, these things (and much more really) require improved technology and tooling to ensure success with modern database development and management.
But perhaps even more crucial is focusing on, adapting and embracing changes to the cultural issues and implications derived from them in place at most IT shops.
For example, there is a common perception among developers that DBAs act as a barrier to progress. The developers work on their code, test it, and are ready to move forward, only to be barred by the DBA from doing so. So, developers view the DBA as a bottleneck.
But it important to understand that DBAs are not just stopping things for the fun of it. There is important work that the DBA must do to ensure that the application can be turned over to production without causing problems. This includes:
- Reviewing SQL code and access paths for performance and to do it using production volume and workload
- Ensuring that everything is production-ready: including statistics collection, index analysis and design, join method analysis, system parameter analysis, and so on
- Reviewing database structure changes required to support the application and making sure they fit shop and industry standards, as well as match up with other related data in the organization
- Building scripts to ensure a successful migration
- Coordination of database changes with application changes
- Ensuring that all support jobs (backup, recovery, reorg, etc.) are in place for every database object
- Determining and mitigating any impact of the new application (or changes) on any other existing applications and databases
When there is little, or no, communication between development and database administration until the code is ready to be delivered to production, it will take time to allow the DBA to perform their portion of the application delivery. The more these things can be intelligently automated and integrated into the development pipeline, the easier things will be. But you can’t just ignore any of this stuff.
And yes, technology can help to alleviate these issues. But it cannot be done with technology alone. Working as a team, communicating progress and activities, and understanding that everybody is working toward the same goal … these are the things that will enable technology to be adopted and integrated into your processes safely and successfully.
And on the other side, DBAs have this image of developers as just pumping out code with no concern for performance and accessibility. A common misconception is that the developers have little-to-no understanding of database issues. This is almost never the case, as developers regularly code SQL to access the database and have a good understanding of the nature and type of data in use for their applications.
So, this cultural mindset of mistrust has to change to one of cooperation. And it needs to be throughout the organization, from the executives to the managers to the DBAs and developers.
Perhaps one of the most important cultural issues to overcome these days is speed. Most Ops folks, including DBAs, adopt changes much more slowly than a DevOps development cycle encourages. A study done by Forrester Research showed that Dev teams are accustomed to new releases on a quarterly basis or faster, and out on the edge there are teams that deploy multiple times a day! Then we have Ops teams, where the expectation is to have new releases twice a year or even slower.
And yes, the most common reason for not achieving the speed that DevOps promises is a lack of automation across the complete software delivery cycle. And database management is one of the key areas that is lacking … a recent study of Database DevOps conducted showed that only about a third of DevOps teams had fully incorporated database change and delivery into their processes. This has to be improved.
The Bottom Line
Technology and better tooling, integrated into the fabric of the development and operational life cycle, is a requirement for adapting to the breakneck speed required for modern development efforts. But technology alone will not be enough. You need to break down the cultural barriers and foster an environment of teamwork and communication for your entire IT organization, and indeed, for your entire company. Only then can we take full advantage of the technology and processes that can help us move faster and with fewer errors.
