“We Want a Better SQL Environment, Just Not Yet.”
No one wants a slow, unreliable SQL Server that leaks data like a sieve. No, they want a fast, reliable, and secure database environment. However, they may not want it right now. Creating a better SQL environment can wait until later, right?
It might seem that way, but the risks will only grow while you wait.
So, why do so many businesses delay making essential improvements to their SQL Servers?
Roadblocks to creating a better SQL environment (and how to navigate them)
Budget is frequently an issue. However, there are likely other factors compounding that barrier. Let’s look at some common reasons companies choose to delay making changes that would help to create a more stable and secure SQL Server environment.
- “That’s part of a future project.”
- “We don’t know where to start.”
- “We don’t know what we don’t know.”
- “We just can’t.”
- “We’re not sure who owns those.”
“That’s part of a future project.”
Sometimes companies will postpone tackling an issue with their SQL Server environment because it gets lumped into a much larger project.
For example, a company may recognize the need to regularly test their SQL Server backups. It’s important, and they know that. After all, an untested SQL Server backup file and process is only a hope that they can restore. (See How Often Should I Test My SQL Server Backups? for some background here.)
Creating a process to regularly test SQL Server backups may still be deferred because “that will be part of the Disaster Recovery initiative.” However, if that DR initiative isn’t budgeted and doesn’t have a start date, that means delaying improvements indefinitely.
So, what can you do?
Start small. Take baby steps that lead you in the right direction. Often those baby steps will contribute to the larger project anyway.
In our backup example, check the status of your backup jobs every day. Schedule a job or another process to verify the backup files. Create reminders to periodically restore a key database to another server and run an integrity check on it.
Is this a perfect solution? No. But it’s far better than ignoring the gap until the larger project is funded.
“We don’t know where to start.”
Sometimes, the hardest part is knowing where to start. Even worse, not knowing where to start can make getting started seemingly insurmountable.
For example, let’s say a company has 15 SQL Server instances and they’d like to get that down to 8 or 10 through a consolidation project. But before they begin, they have questions.
- Which application databases can be moved to another SQL Server?
- Which ones will play nicely together, and which will compete for limited resources?
- Are there security considerations that require some applications to remain separate?
- Will we have to add resources to the target instances?
- And what haven’t we thought about that we should?
Those unknowns can seem overwhelming, especially if you don’t know how to go about finding the answers.
So, what can you do?
Start small, build momentum, and keep your eye on the end-goal while making incremental progress.
In our SQL Server Consolidation Project example, can you build a high-level project plan with only the most basic steps? Then you can drill down into the details, step by step.
For example, the first step is to get a list of all of the SQL Servers that may be candidates for the consolidation project. Then, determine what applications use these SQL Servers. Then, identify the applications’ requirements, and so on.
We know projects like this can become dauntingly complex if you’re not used to doing them. As with most anything, breaking things down into smaller, more manageable steps will help.
“We don’t know what we don’t know.”
This one is common and can take many forms. As an example, let’s say IT wants to decommission a SQL Server, but they’re unsure whether it’s being used. It’s got a dozen databases on it, but some are from older applications that may not be used anymore. Maybe the guy who created the database isn’t even with the company anymore.
Another example: IT would like to do a side-by-side upgrade of a SQL Server. They know there are a lot of data pipelines that rely on that SQL Server. However, do they know how many pipelines? Who owns them? Will they have to be redeployed? Are there any other aspects they’ve overlooked?
What should be a relatively simple request can become a larger issue. It can seem safer not to upset the apple cart when there are so many unknowns at play.
So, what can you do?
Having a long list of open questions with no clear path to find the answers can feel paralyzing. To find your way forward, focus on your goal and your reasons for wanting it. In the upgrade example, your goal is to upgrade your SQL Server. Why? Using an older, unsupported SQL Server version could cause serious issues; an upgrade would improve security, compliance, and supportability, which means you’re less likely to encounter problems.
Once you’re clear on your motivation, determine how you can begin to answer the first unknown. Then the next one. Then the one after that. Incremental progress will help you grow in confidence about your ability to improve the environment in addition to answering those unknowns.
“We just can’t.”
Sometimes limitations are self-imposed. Other times, limitations are implicitly imposed by stakeholders, even if they don’t have the authority to make the call outright.
This can happen with patching. As an example, vocal and influential stakeholders may insist that a SQL Server cannot go down for maintenance, period. IT may accept that limitation rather than fight it. As a result, things may progress until neither the SQL Server nor the Operating System have been patched in over two years. Not good!
So, what can you do?
This one can become overly politicized or personalized. Look for and emphasize common ground.
In the patching example, the common ground may be that everyone wants the SQL Server to be available and secure. From there, you can communicate how patching will help achieve that common goal. Planned downtime is always better than unplanned downtime, and reminding stakeholders of that can help put things in perspective.
Sometimes, IT has a reputation for implementing technology for technology’s sake, regardless of what’s in the best interest of the business or its stakeholders. Keep that in mind. Present your points so that the other party can see how they’ll benefit.
“We’re not sure who owns those.”
Sometimes there’s no clear owner of your SQL Servers. No one wants to make decisions about them, even if it helps to create better SQL environment. This can happen after an acquisition, during a re-org, or when responsibilities are not clearly spelled out.
For example, IT may become aware of some new SQL Servers. However, the team isn’t sure if those instances fall within their purview or the responsibility of another team or department. Spoiler alert: if something happens to one of the SQL Servers or its databases, IT almost always ends up having to fix it.
So, what can you do?
Uncertainty in areas of responsibility can lead to big problems. Get clear on who is responsible for SQL Servers (and any other assets) as soon as possible. Otherwise, those SQL Servers will become increasingly vulnerable to breaches or data loss.
Moving forward to create a better SQL Server environment
I’m sure this list of roadblocks isn’t comprehensive. There are likely other reasons companies don’t improve their SQL environment. Many of them may even be good and valid reasons.
However, in cases where creating a better SQL environment would be in everyone’s interest, don’t let the perfect be the enemy of the good. Look for ways to make incremental progress, however small, toward a more reliable and more secure SQL environment that performs.
If you’re not sure where to start, we can help. Helping clients overcome barriers to create better SQL environments is what we do for a living. Schedule a call to see if working with our team of DBAs makes sense for you.