SQL Server Reference Guide

As technical professionals, we’re all called on to make decisions about one vendor, process, or other choices for our organization. And yet, many times people make decisions that don’t always fit the situation. In this tutorial I’ll show you how I normally evaluate my choices for solving a technical issue at the places I work. I’ll walk you step-by-step for the entire process, from defining the problem to strategies on living with the results of your choices.

Defining the Problem — No, Wait, Defining the Goal

Most of us don’t value changing a production system just for the sheer excitement of it, because we don’t like taking a chance on those systems and frankly, we don’t have the time. I’ve written before about not even upgrading a system unless you need to. That being said, as the technical professional, your organization looks to you to stay on top of the latest research and watch them for alignment to your business goals. This actually brings me to my first point — if you’re only facing a choice because of problems that arise, that’s a sure sign you’re in a reactionary mode. That’s not a good thing — it means you’re in trouble all the time and just reacting to that trouble.

Instead, by making good choices, such as setting up some sort of maintenance and monitoring interval that alerts you before a problem hits, you can move from a reactionary stance to one where you and your team are adding value rather than just firefighting. You can do that by defining a goal instead of recognizing problems. It’s a subtle switch in thinking, but quite powerful. For instance, consider these two statements:

Our backups fail constantly. We need to fix that.

Versus:

Our systems need a reliable recovery solution.

True, both statements indicate a need for good backups, however, the second statement puts you on a good mental path — it takes a “problem” off of the table, stating only the positive case of what you want. There’s another benefit here — did you see it? The second statement doesn’t say anything about “backups” — it states that the real goal is to be able to not only back up data, but to restore it as well, which is a very important distinction.

So, the first thing you need to do is to state the goals for any system, existing or new. The goals should start broadly, and go in big buckets like that “Business Continuity” item I just mentioned, and then get more specific as needed.

I understand that sometimes the decision is already quite limited — such as “Do we upgrade to the latest version of SQL Server or not?”, but even that should be framed in larger business terms. Again, never implement a change for its own sake in production. For testing, that’s exactly what you should be doing, so you know the impact of those changes there.

Evaluation Criteria

After you’ve carefully created your goals, your next job is to lay out what it important to your organization as criteria for the “right” selection. For instance, the overall goal might be that statement I made earlier of our systems need a reliable recovery solution. That’s a fine place to start, but there are a lot of questions that are raised with the statement. Those questions then turn into statements, like this:

1. We need a Recovery Point Interval (or Objective, RPO) of less than 500 transactions.
2. Our Recovery Time Objective (RPO) is two hours.
3. The solution must include the Application Server, the Middle Tier, and the Database Servers.
4. The solution must cost no more than X.
5. The solution must work with our current tracking system for reporting.

And so on. After that, you need to arrange these criteria in order of importance. This is sometimes really hard to do, but you have to involve the business to pick which item is the most important, which comes next, and so on. You are going to run into the situation where you’ll find two or more competing solutions, and you’ll have to pick between them. They will all do everything you need, with one or two exceptions — and those exceptions will be the tie-breakers you have to already have decided.

Locating the Options

Now you’re off to selecting the various options you have. This is often the place most people start — they think “we need a backup solution”, look up the backup vendors and off they go. They end up driven by marketing information, which can end badly.

Instead, you have your questions for the solution lined up as criteria — and that’s where you start your search. Instead of searching for backup vendors, you can consider the right mix of procedures (which are thing you and your company needs to do regardless of vendor), processes, and then product. It’s important to enter all of these as parts of a complete solution — it’s rare that a software or hardware product solves any issue completely. It’s almost always a mix of these three items.

With those identified, now it’s time to find your options. For complicated solutions, I recommend you hire a consultant, partner or services engagement to walk you through the process. These folks, and I assume you’ll vet them to find good ones, are kind of like a “buyer’s agent”, in that they are supposed to be as independent as they can for the solution. Sure, it costs money, but choosing the wrong decision can be far more expensive.

If you really don’t have any money, I mean you really don’t, then leverage the community. Ask questions on your social networks (like Twitter and Facebook and LinkedIn) and in forums. Ask when you attend your user groups. Put the word out that you are looking to solve a particular problem, and phrase those questions carefully and respectfully. Of course, protect your company’s private data — don’t Tweet, for example, that you just suffered a major outage and you’re looking for a backup solution.

One final note on getting community help: make sure you vet each answer you get. Especially in the “free” area, it’s very much a question of quality. Don’t use just one set of answers to find your solution, instead make sure that you compare each answer and look for common information. That’s usually more interesting than the one-off solutions you’ll hear.

The easiest place, of course, is to check with the vendors in the areas that you need a solution for. All major vendors have web sites, sales teams, marketing and advertising that makes them easy to find. Although I save the vendors for last, I do include them. However, I show them my criteria list, and insist that they address that list.

Work with the vendor — you can in fact make them a partner in the process, and if not, then switch vendors. It’s really that simple.

Crunching the Numbers

Now you have a matrix of requirements, and you can place the options you’ve found across the top of the matrix. Now it’s a matter of assigning a value to a particular solution based on your requirements. Here’s an over-simplified example:

In my case I’ve assigned a numerical range from 1 — 5 to the solution a vendor has offered. The view above does not have the “notes” section from my real spreadsheet or all of the data findings that I did for the research.

This brings me to my next point — it’s important to set up a test environment and ensure that you’ve tested as best as possible the complete solution and documented your findings. This is essential to getting “real” or reliable data that you can really trust. Otherwise, you’ve simply done a lot of work and still run the risk of making a poor choice. In other words, the quality of your choice is directly related to how much time and effort that you put into this step. And the good thing is that this kind of effort gets easier as you do it. The testing servers are built, the scripts are all done and so on.

Presenting the Findings

Now you’ve crunched the numbers, and you have your choice ready to submit to management to write a check. Stop!

You need to have at least three solutions ready, usually in order of cost, and presented in terms of benefits for that cost. I call this my “T-Shirt” sizing — you get this size shirt for this much, this one for that cost and so on. Any manager gets nervous if all you give them just one choice. So line up your choices, and it’s best to put your “favorite” one in the middle. Sorry to politicize the technical discussion, but it’s just human nature not to pick the bottom or top choice given three of them. I’m not saying, by any means, that you should manipulate numbers. What I am saying is that you should investigate all kinds of solutions, don’t just stop at the one you like.

Now take your data to the managers that will make the final decision and explain your decision process to them. This explanation gives them confidence that you’ve done your homework, and breeds trust in your professionalism.

Living with the Choice

The managers may push back, and hard, on the solution you choose. They may have good reasons for going with one solution over another, and in some cases the reasons are, well, less than good. Either way, you’ll have some solution to work through. At that point, you’re not done — in fact, you’ve just started.

First, don’t let those vendor’s off of the hook. Some vendors like to sell a solution and then move on — hopefully in your earlier investigations you identified these folks and ruled them out. You should be working with your vendor, and they should provide you with best practices, architecture patterns and so on. This really isn’t too much to ask — it’s standard fare for any enterprise-level solution, and it’s something you should expect.

If you don’t agree with a particular practice or plan, then ask questions, join that support community, make it better. You’ve got this thing in place, and it’s your reputation that is on the line right along with it.

Finally, you’ll need to instrument your solution and bring it under your monitoring and management framework, so you can track how effective, efficient and functional it is. This will allow you to develop a Return On Investment (ROI) metric to make your decisions better, and of course to let your boss know why it was such a good idea to hire you.

InformIT Articles and Sample Chapters

I've covered this process in practical terms for selecting a database back end elsewhere in this Reference Guide in the appropriately-titled Choosing the Back End.

Books and eBooks

This information stretches to other technologies as well — Selecting MPLS VPN Services is a great book that covers this process for a VPN offering.

Online Resources

The CIO magazine blog has a good explanation of this process in terms of saving money.