When I want to check out a piece of software, one of the first things I look for (after the price tag) is the support matrix. I want to know what versions of SQL Server and Windows they support. I lined that up with the available machines I had in-house, picked the right platform, and got started.
Years ago, I noticed that when other users wanted to bring a new piece of software in-house, they brought me the product’s support matrix and asked what versions & servers we had in-house. Some departments (like the mainframe guys) got so many requests that they published their own standards document showing what they supported. When a manager insisted on putting certain kinds of software onto specific servers, the mainframe guys could point to their support matrix and say, “Sorry, that doesn’t match our standards. It needs to go on this other server over here.” Bam, discussion over.
Wow – why wasn’t I doing that?
I decided to build my own support matrix and standards document for our SQL Servers. I broke the servers out into categories: Development, QA/Testing, Production, and Mission-Critical Production. I came up with standard descriptions for each category that covered our HA/DR levels, our on-call availability, and security. Here’s a screenshot:
My SQL Server Support Matrix
Kapow, I laid down the law. For example, I would not be on call if the dev server crashed at 9pm when one lonely developer was working late – he could open a support ticket, and I’d address the issue in the morning. Note that this didn’t mean I wouldn’t fix the dev server after hours; I still set up SMS alerts to notify the team whenever ANY server was experiencing problems, and I wanted to get them fixed before the developers came in the next day. However, with this support matrix, I was setting up reasonable expectations across the staff so that we knew what was an emergency, and what wasn’t. If someone needed a database to be available 24/7, then that fell into the production category, not development.
When I built this document, I didn’t show it to my existing customers. (Yes, I really think of my users and developers as my customers, not my coworkers.) The goal of the document wasn’t to change expectations for our existing databases, but to shape expectations for any new databases and applications that came on board. When a project manager wanted to bring in a nasty, poorly-written app that required SA permissions and 24/7 uptime, my support matrix backed me up. I simply said, “No, that’s not in our support matrix,” and handed them the document.
If the manager has dealt with support matrixes before, they’ll recognize that these documents are usually built over time with a great deal of testing time and political wrangling. Your document wasn’t – but they don’t know that. They don’t know your document was only crafted with your finely honed intellect. They’ll assume the support matrix is not negotiable, because the vendor’s got a support matrix too, and it’s not negotiable either.
The project manager will take the vendor’s support matrix, set it side by side with your support matrix, and look for a way to make this work. They want the path of least resistance. Your support matrix needs to give them an easy way to get their app in the house in the way YOU want to support it. In my support matrix, I noted that with asterisks – if someone really wanted to get remote desktop access or SA access to their server, they could have it – as long as we could install them in a dedicated VM.
“No one will take me seriously.”
You think you’re powerless against your customers, and you’re right. The project manager can pull rank over you and tell your manager to shut up and start installing. For years, they’ve been kicking sand in your face, but I’m going to introduce you to your enforcers. Your existing customers will play the bad cop. Watch how this works:
Ned the New Guy: “Here’s an installation script for a new database we need. After you put it on the mission-critical production cluster, let me know what the SA password is.”
Me: “Sorry, apps on the production cluster don’t get the SA password. Here’s our support matrix.”
Ned the New Guy: “I’ll show you where to put that support matrix. Don’t make me ask your manager.”
Me: “Well, if I give you SA permissions on that cluster, I’m also giving you SA permissions on our SalesApp database – the system that all our revenue comes through. I’m not comfortable doing that without Bob’s okay. He’s the SalesApp project manager. Hey, Bob – would it be okay if I gave someone else permission to truncate your tables, drop your databases, and shut down your servers?”
Bob the Bad Cop: “Hell no, Ned, you’re not getting that. Go get your own server. Don’t make me get the CFO.”
Presto – you’re not the bad guy, and you’ve got someone with much more power in your corner. Get started today by taking my sample SQL Server Support Matrix and making it your own.