As a DBA, my job is to protect the data. And that means protecting it from all foes, internal and external. Our greatest nemesis is the developer. In the past, I fought with developers regularly. These days, working in a hosting environment, my battle skills are getting soft. Or so I thought.

Working in hosting, the only developers I typically deal with are with those who work for our clients. We have very specific rules around what we allow and support. If the client wants to do something we don’t support, that’s when I leverage their account manager to have difficult conversations with the client. It usually works well.

We also have an army of internal developers who write our product. They almost always work in our R&D infrastructure that I can’t even see. Another DBA team manages that infrastructure, and they leave me alone. Almost always.

Recently, we have a group from our R&D department who is putting together a project for a client that works with a partner application. It’s all very new to us. And unfortunately, they have to do some development work with the client’s development instance of our product. This particular developer has this belief that he needs to have the sysadmin role of every instance he touches. The guy is brilliant and is used to getting his own way. Clearly he hasn’t met the Cranky DBA. I work in a secure cloud hosting environment. He’s going to get absolute minimum privileges required.

A few weeks ago, we sat in a meeting where he proclaimed that he needed the sysadmin role in this client’s instance. I giggled to myself and then asked what he was trying to accomplish. It turns out he really only needed the SSISAdmin role in the MSDB database. You see where I’m going here? This was also the same meeting where he tried to one-up me and asked if I knew about the SQL Saturday being held in Boston. I played dumb for a few minutes while he told me about how amazing it was going to be. That’s when my belly laugh escaped and I had to confess that I was the one who was organizing the event. He was put back in his place for a little while.

Today, the fit hit the shan. No. The shit hit the fan. He was stuck and couldn’t proceed. He needed the sysadmin role on this instance. He was dead in the water and couldn’t do his work. That’s when I started troubleshooting. What was he trying to do that we didn’t account for? It didn’t matter. He had to have the sysadmin role. Or at least that’s what he believed.

I had a great conversation with my manager around this. Maybe he did need the sysadmin role. But I wasn’t going to give it up without a damn good reason. My manager brought up a really good point. What was he going to do in Dev that would need to be promoted to Test? And how would that make it to Production? No. We weren’t going to give him the permissions he wanted. It turns out he only needed to create the SSIS catalog. Seriously? That’s it? Three minutes later, he was back in business. And he still didn’t get the sysadmin role on the instance.

Now we have this documented so that when we build the Test environment, my team can pull out that document, implement, and go.

The best part of this is that I work for a manager and a director who get it. My manager actually told her senior managers that whatever needs to be done, if the DBA team does it, she’s confident that it will be documented and repeatable. With cowboy developers, all bets were off. And her senior managers backed her up. A little later, I got a call from my “boss” who asked where we stood on keeping this developer happy. I told her what was going on, and she thanked me for holding the line. She doesn’t like it when her team gets bullied. And I certainly wasn’t taking it this week.