DBA, Grow Thyself – Moving and Shaking in the Era of Data Dominance

Beefing up your technical skills is important, and it’s what makes you a good DBA, Developer, Architect, or whatever you happen to be. But at the same time, it is incredibly important to keep up with the professional trends in your organization. While all organizations are different, there are some definite trends that are taking shape in most businesses that it would be wise not to ignore. And after all, all those storage, database, application, and utility vendors promised you tons of free time when you adopt their platform, right? It’s not like you have a lot to do. /sarcasm

Earlier this week I wrote an article about the role of DBA teams in the business today, focusing on advice for the DBA manager (though it is also very useful for DBAs as well). Today I want to focus on the DBA specifically with some points which, in my experience, are highly important at the business level and possibly unknown at the technical IT employee level.

Development/QA – It’s the New Production

I remember years ago, I made it a personal mission to tell every DBA I worked with that backups should be treated like production. Even then it was such a novel concept to some people; who knew that the bundle of files that may one day save my career and company might actually be a production environment? Well certainly not the people who lost their jobs due to lack of backup. Ye sorry souls.

Nowadays that should be common knowledge and a common phrase, harkening back to the days when Russian roulette was played by DBAs and administrators for lack of disk space or free cycles. However, a new paradigm has arisen which is in many ways difficult to support but wholly necessary: development and QA are just as important as a production environment. In fact it’s not really a new paradigm at all, it’s just being enforced more and more.

To a company, being able to reliably push out software updates, new products, roll out new features or content, fix bugs, and provide solid user acceptance testing is paramount. It increases both user and executive confidence in the business and IT as a whole, and it creates fresh sources of revenue and opportunity. The last thing any DBA wants is to be the bottleneck in that process. In all areas of development from a database perspective – creation of development/QA databases, refreshing from production, providing viable statistics and metrics, monitoring, and backup and recovery – the DBA must be as active and safe as they would be in production. At some companies, even development environments have change request procedures that must be followed by the DBA or developers.

Let’s face it, DevOps is taking off and businesses know it. If the DBA (and system administration) groups can’t keep up with fast paced frameworks and QA requirements while keeping all aspects of development moving smoothly and safely, then they will be consigned to the “doesn’t have a sense of urgency” bin. The business will see the database as just a part of the software stack (and rightly so), and will not understand the reasoning behind a bottleneck however logical it may seem.

That’s why tools like Delphix are taking off. It’s not another monitoring tool or performance management tool…it’s a storage agnostic thin provisioning layer for databases allowing fast deployment and refresh of QA and development environments through virtualization. They are experiencing huge growth by reducing the dev/QA footprint and speeding up release schedules. I predict that in the very near future, a bottleneck to provisioning development/QA/reporting databases despite incredible technology support will be viewed as highly unacceptable.

Lobby for control over new technology

If it’s data centric, own it. I know this may be a controversial one because of the serious lack of resources some DBA teams already encounter, but if at all possible the DBA should be keeping up on modern trends and embracing them. Like it or not, at some point your business will bring up the idea of using MongoDB, Hadoop, MySQL, or a wealth of non-Oracle technologies. While you need to make sure they are using the right tools for the job (like not replacing every single Oracle database with MongoDB just to do it), at some point the adoption of new technologies will be inevitable. And whether you feel those technologies are fads, useless, or boring you will need to keep up on them to stay relevant.

Take Hadoop, for example. It’s not a database, it’s a filesystem. The data stored on it is as dirty as it is plentiful, the environment is spread out over dozens if not hundreds of nodes, and doing anything meaningful with it requires coding or complex tools/layers. Yet if your company is not going to hire an experienced Hadoop Administrator, it’s a great job for the DBA. Gwen Shapira makes a great note of this, arguing that the DBAs experience with complex tuning requirements, data warehouses, and developers makes us a very suitable candidate.

Honestly, I wouldn’t say you need to become an expert in every data technology out there. There are just too many. But try to remain open and somewhat versed in the environments. And if your company starts moving toward one, be ready to jump at the opportunity (should it be logical) and take part in it. If possible, own it.

Sometimes it is as simple as saying that you want it. When new work comes down the pipe it is very common for everyone to take a step back; if the project is data centric, you should be taking a step forward. The goal is to make you undisputed heavyweight data champion of the world. New technologies mean new opportunity both inside and outside your company. Even niche products can look really great on your resume later down the line. If you can’t simply take over a technology, then lobby for it. Research and discuss it with developers, business analysts, and project managers. With just a little bit of conversation and a few emails, it isn’t hard to convince people that it is in their best interests to hand the data management to the DBA no matter what form it is in.

Speak to your target audience

One of my favorite reddit subs (don’t judge) is r/explainlikeimfive (ELI5 for brevity). The idea is to take a complex idea and pound it down until it can be explained to a five year old. Now I’m not advocating that a DBA talk to everyone as if they were a child (though I know many IT professionals who do so), but more advocating that you speak appropriately to your target audience. Many of us already do this. But I can’t count the number of times I’ve seen an IT professional stand in front of a business analyst spewing out details about kernels and kdumps and semaphores and concurrency while the analysts eyes glazed over faster than a piping hot Krispy Kreme donut. Like it or not, there will be people at your company that don’t understand parameter settings and b-tree indexes. Trust me, they have their own language that you probably wouldn’t grok too quickly either (see what I did there?).

Just like learning different technologies, learn different business dialects. If not the verbiage, at least learn what interests them and their level of technical understanding. Metaphor is a great vehicle for this. I’ve had great success selling ideas or projects when I used metaphors that interested the person in question; sports metaphors for sports types, car metaphors for car types. Just make sure your metaphors make sense… don’t be that person everyone will one day giggle about for comparing improving database performance to the running back scoring a home run.

So when you talk to project managers, talk in terms of milestones and deadlines. For business analysts, talk about goals and roadmaps. For VPs, talk about objectives and projects. Notice every single one of these examples has to do with things getting done, not the process involved. That’s right! For the most part, they don’t care how it is done as long as it is done quickly, efficiently, and correctly. Leave the hidden parameter discussions for your technical brethren and your final report.

Of course, your mileage may vary. If you work for a company where even the CEO has written kernel code, you might look like a fool if you try to coat over the technical details. Use your gut, but keep a critical eye on your target audience before you flood them with details.

Above all, keep your ear to the ground and your mind open. Data is fast moving out of the cubicle and into the boardroom. If you want to improve your impact and influence, be ready to go along for the ride.