SQL Server Reference Guide

As you progress in your career, at some point you will have gained a great deal of experience. Perhaps you’re a consultant or contractor and you’ve worked in several industries and organizations, or you’ve been at your organization for quite some time.

Over time, you will find that your organization looks to you for more than just programming a database or running a backup. They begin to think of you as the technical representative for your area to the organization. Sometimes they formalize this by giving you a new title (such as “Architect” here in the U.S.) and sometimes it’s just allowing you to give input to the higher levels of business or your organization.

This is especially true when a new or different technology is talked about at their level. Lately I’ve been dealing with this in the SQL Azure space, which is a “cloud” database. You might face this too — someone stops you in the hall and asks, “so should we be using a “cloud” or “NoSQL” system? What do you think?”

There are a couple of ways you can respond. The first is to say “What we have now took a long time to get right, and it’s working well, so we should stick with that.” Or you could say “I’ll research what the features are in that new technology, compare it to what we have now, and tell you if it’s better. Then we can change over to that.”

But both of these approaches are wrong.

The proper way to approach a new technology isn’t from the technology angle at all — it’s from the needs of your organization. Take a moment and let that settle in. The executives in your company or organization don’t actually care about the technology. They only care about three general things:

1. What it can do
2. How quickly it can do it
3. What it will cost

If you can keep that in mind, it becomes a more simple, scientific exercise to decide on whether to use a cloud database, NoSQL, SQL Server, Oracle or DB2, or anything else. There’s a process you can follow to find the answers to those questions, and a couple of tools you can use to explain your findings. In this tutorial, I’ll explain a process I’ve used, along with a couple of deliverables that you can use to communicate your findings.

Note that this will take time. It will be on top of your “regular” job. That’s the nature of being a senior resource — you’re asked to do more. If this isn’t something you care about — you’re interested in technology, not necessarily how it is used — you should still read on. You need to know what is directing the choices for your technology, so you know what is driving your work opportunities.

What follows are some concrete steps you can take to evaluate your needs, and then map them to a technology so that you can make the right choice. The process holds true for technologies from cloud databases to on-premise solutions. You’ll find this process plugs in to everything from Application Profiles to Business Continuity Plans. The answers and artifacts (like documentation) in those areas feed this one, and vice-versa.

Define Your Application Areas

First and foremost, you should define the business or organization “key” processes, as they pertain to technology. For instance, if your firm builds airplanes, then how is technology a part of that? And which parts are the most critical? If your company is in the financial industry, what is critical to do the work? You need to document at least the most important areas to accurately determine what your technology needs are.

It should be noted that some things don’t apply to your role — if your organization picks flowers for a living, computers may not be the largest part of that operation — or perhaps they are. The point is that you need to know what your organization does and what it’s core missions are to make this assessment.

This might uncover some things you normally don’t have to think about when you’re writing code or doing a backup, such as any privacy, legal or regulatory requirements. Note those down as impacts to the application areas.

Define Your Application Use Profile

The next part of the documentation needs to be the applications that are currently in use, or those that are candidates for the new technology. Think about things like the load of the application. Is it “steady," “increasing," or “bursting” (such as a holiday spike in activity, or end-of-month closeouts, things like that).

Next, consider the performance requirements for the application. Sure, you want the best performance you can possibly get, but think about things like being able to scale the application, and how easy it is to do that. Do you have to buy a huge server for this solution, so that you can handle peak loads, or is it something that can be scaled up and down? What is the requirement versus the desire for high performance? Be specific, all the way down to the round-trip level.

I alluded earlier to security and regulations, and you also need to consider the specific needs that cover computing requirements in this phase. In other words, the business or organization might be required to “safeguard” information, but a computer system might have an additional restriction to encrypt that data to a certain level. You need to include this information to ensure the new technology has a way to deal with it.

Define You Application Development Profile

Unless you’re in a brand-new company that has no current IT infrastructure, you have some sort of talent in a specific technology. Perhaps you use the .NET languages primarily, or T-SQL, or maybe you use open-source software development. Document that.

You also need to document the development methodology your shop uses. Not every technology fits into a particular development method. Document what yours is, and whether the technology supports it — or whether you’re able or willing to change to use the technology.

Your IT department may have Service Level Agreements (SLA’s) on certain applications. That means you have to meet a certain up-time, performance or other goal. The idea is that IT wants to make sure the organization knows that this kind of thing costs, so they use the SLA as a way of communicating that back to the organization. If this particular application area has one of those, you need to ensure that the technology you’re considering doesn’t break that.

Compare Your Results to a Technology or Technology Stack

The steps I’ve mentioned above are only a broad outline. There are other areas that you can consider, but if you document the information above you’ll have a great start.

Now you can create a column or paragraph that includes the technology you’re considering (one at a time — more on that in a moment) to see how it stacks up. You might do this in the form of a “Request For Information” (RFI) or “Request For Purchase” (RFP) process. You lay out the information from above as a set of requirements, and ask multiple software vendors to answer that for you. While that can work, keep in mind that each vendor wants you to use their solution, so don’t just take answers at face value. Ask questions, do your own research, or get a third-party to help.

This is especially important in some open-source software, where there is no “vendor” to answer those questions. You’ll end up doing your own research there, or get a third-party to help. Not a problem — just a data point.

And this is the part where you need to understand that a particular technology might not be a complete “lift” of your current environment. Just as in the case where you own a spoon and a fork, you may be able to mix the new technology in with your current process. This is called a “hybrid approach," and is especially useful for High-Availability and Disaster Response environments, or to add capacity during peak loads. In fact, this is where I’m seeing cloud systems used quite frequently. Rather than buying lots of servers to handle load, a local environment can “scale” to another one, and then back down again.

Track the Money

Although a new technology might solve your needs, in the end it’s all about the money. Once you have the variables laid out and the technology mapped, you need to define the cost for both.

How do you pay for this new technology? Will you need more software, hardware or people — or all three? Can you use what you have? Will more or less people from other parts of the organization be affected?

For these answers you should work with your vendor, along with doing your own research, to get the answers. From there you can develop a “Total Cost of Ownership” or TCO, and a “Return on Investment” or ROI for that particular option. If you’re not familiar with either of those terms, a quick search here on InformIT will give you lots of education.

Repeat for each Technology Option

You’ll notice I haven’t advocated a spreadsheet or matrix approach for this exercise. While you might end up with one of those at the end of the process, you have to consider each solution option in isolation first — sometimes the options just don’t have enough in common to fit in a matrix view.

It isn’t that bad, however. The work you did in the first sections of defining your business and organization needs is the same. What changes are the answers to those needs, and the money part.

Present and Deliver

Finally you’re ready to deliver your findings to the organization. I’ve found that it’s best to start with a high-level set of findings, boiled down to just a few paragraphs, and to attach the TCO and ROI information.

From there, have your detail ready, with the documentation from the process all ready to display to others, you should collaborate with the business or organization leaders to select an option. It’s a partnership — they will look to you for the technical suggestions, and ultimately they are responsible for the solution working for the organization. So you’ll need to build trust that you know what you’re talking about — and this process, along with the deliverables, helps you build that trust.

InformIT Articles and Sample Chapters

Although not strictly an article, I talk a little more about an ROI calculation for the DBA in my blog post ROI and the DBA.

Books and eBooks

Dr. Timothy Chou has a great discussion on TCO in his book The End of Software: Transforming Your Business for the On Demand Future. Very thought-provoking.

Online Resources

You can find a sample of working through a TCO in this calculator — there are others from other vendors, this is just an example.