T-SQL Tuesday – Will the Real DBA Please Stand-up

Be the Interpreter

Steve Jones (Blog|Twitter) is hosting this month’s T-SQL Tuesday where his topic is about getting your job done while dealing with business requirements and mandates.  Over my career I have seen many instances of management mandating that something be implemented because they saw an ad on the internet or some magazine.  The problem is that they don’t understand anything about the technology or the availability of other options.

Our job as DBAs is to be an interpreter to understand what the end result is that the business requires and the options to get that result.  The first thing you have to do is recognize the situation where interpretation is needed.  If the request from management has little technical requirements and lots of industry buzz words, that’s your first clue.  Once you have identified the situation you need to reverse engineer it and start asking questions that will allow you to discover management’s desired end result.

Recently I received a request from management to consolidate our reporting platforms.  Once we did our discovery work, we realized that a couple of groups were coding their own reports in C#.  The data they were reporting against was in SQL so it was easy to say that SQL Reporting Services needed to be the chosen platform.  Our reasons were because it is free with the product, would provide the same results, and could seriously reduce report development time.  Although this practice needed to be changed, I suspected this was not what management was really after.  I was right.  Management was not looking for a product standard, but a single report consolidated from the several they were already receiving.  Management did not clearly articulate their desired end result and used a bunch of buzz words that indicated something entirely different.  As a result, my team’s interpretation of their request was incorrect and I guarantee we will ask more questions next time.  Fortunately our detour was not a waste since product standardization is something we needed, and getting the developers onto SSRS saved tons of labor hours.

Dodging Bullets

Bust out the Matrix

Management is firing out mandates so you start dodging bullets like Neo.  Not that kind of Matrix!  There is nothing management likes more than a matrix…well except for a matrix that shows a cost reduction.  One way to make sure you are interpreting requirements correctly is to document your interpretation and submit it back to make sure your solution meets their expectations.  Depending on the request you might have to write it up in another form, but over the years I have found that management really likes things presented in matrix form.

Stand-up (Slowly)

I work in a large corporation where politics abound.  It is very common to see something implemented poorly or incorrectly because an executive asked for it.  Remember that internet add your VP saw?  Well it would not be prudent to simply implement it without asking what the benefits are and how it helps the business.  This is where business requirements, technology, and your career come together on a fine line.  Will the real DBA please stand-up?  I believe you should stand up, but you should do it slowly.  You need to voice your opinion on the right method to use as a solution, but be sure to back it up with facts and explain it well.  You also need to be sure and have it documented in email for the classic CYA.  That being said, you need to be very careful in how you present these technical challenges.  I find that asking questions is a good technique.  You don’t want to overdo it to the point you come across as uninformed and incompetent, but simply spewing out facts and statements can come across is confrontational.

Be a real DBA and stand-up, but be smart about it.