I earned my nickname. I’m proud of it. I am the Scary DBA. I don’t really like to advertise my other nickname, Rant (get it, Grant shortened to another word). I earned that one too. I’m not proud of it at all. I got that one because I sometimes don’t listen as much as I should and, because I tend to be more than a little passionate about my job and my databases, I would go off on a rant. And yeah, I stood in the way of some development processes and approaches that I shouldn’t have. Instead of facilitating the development team and trying to understand their problems and issues, I just said “No.” Usually at length.

I just finished reading this post from Martin Fowler, whose work I’ve  enjoyed, about what he’s calling the NoDBA movement. It’s not so much a “movement” as it’s a by-product of the NoSQL movement, ORM tools, and other developer-centric/code-centric approaches to managing data. Some of these are natural, and appropriate, rejections of the relational storage engine. Let’s face it, it doesn’t work very well at all for some types of data collection. You should be using “pick your favorite” NoSQL storage engine for some types of code. But, there are two problems here. The first, Mr. Fowler mentions in passing, just because there are places where NoSQL works well doesn’t mean it works well in all places. Humans very much tend to fall into a mode where “I have a beautiful hammer. Look at all the lovely nails” becomes how we work. There are nails that need that NoSQL hammer, but there are screws and bolts and other types of fasteners out there that using the NoSQL hammer on will not work terribly well. Same as if you have a big data hammer or a structured storage hammer or a relational storage hammer or an object storage hammer or whatever kind of hammer you are currently enamored with. I am not casting aspersions on your very fine hammer to suggest that it’s probably not going to be efficient at pounding in screws. And, I’m telling you flat out, your ID value pair data collection engine which is great for pulling in “web scale” data is going to blow serious chunks when it comes to business reporting. It just will. That’s not questioning it’s utility for data collection, but just as the hammer-to-screw mechanism doesn’t work well, the collection-to-reporting mechanism doesn’t work well either.

The second thing that Mr. Fowler mentions is the social aspects of what’s going on here. It’s “Rant” that is causing the developer to try to find a way around the DBA team. In short, it’s my fault. It’s your fault. We have not been listening. We have not been communicating. We’ve been at war. And that’s just stupid. There are very sound, technical reasons for using an ORM. Standing in front of your developers with a furrowed brow and your arms crossed saying “no” without a full understanding of those reasons just gets you kicked out of the room. Then, of course, the development team goes off and makes some of the classic implementation errors that can be done with ORM tools. But, because you weren’t in the room because you became “Rant” instead of trying to engage and understand, those errors grew and were standardized within the app. It’s your fault. When the developers proposed changes to the structures of the database under development, instead of whining that it was going to take time and that they needed to fill out paperwork and get approval from fifty people, you could have listened and understood what they were proposing and why and then you could have either done the work, or showed them a better way to do the work, or proposed a different solution, or even suggested that maybe they’d be better off with a NoSQL solution. Instead, you became “Rant” and they bypassed you. That’s your fault too.

Now, the really fun part is, that even though you’ve been bypassed, in most organizations I’ve been in or worked with, inevitably the data has to be reported on and it has to be backed up and it has to go through a DR process. Then, suddenly, you get handed the mess. And it is a mess because no one even thought about reporting on the data collected or backups or the ability to get the site back on it’s feet in the event of a fire/flood/meteor strike. And this is not the mess that those nasty developers created. Oh no. It’s the mess you, “Rant,” created. Fault yours.

Yes, I’m off on a tear, a rant. Initially because after reading what Mr. Fowler wrote I was quite upset with him and his attitude. Then I recognized that at least half the problem lay at my own feet. And while I hope, to some degree, I’ve learned some lessons from being “Rant” a little too often, I feel I’m still seeing way too much of “Rant” in my peers. I see the outright rejection of Azure SQL Database. I see the scoffing at HDInsight. I watch people trying to block the adoption of ORM tools. I see data professionals unwilling to engage with their development teams in areas like source control, continuous integration, testing, agile processes, new deployment processes and more. All this is hurting our ability to influence, in a positive manner, the products delivered by development teams. Further, it’s hurting the businesses that we, data pro’s and developers alike, are supposed to support. Yes, the development teams are going to need to meet us halfway on this stuff, but I don’t see why we can’t be the first ones to offer a hand, to acknowledge our past misdeeds, to stop being “Rant” and get out there and help the people and the businesses we support. If you don’t, it’s your fault.