Jeffrey Garbus, CEO Soaring Eagle Consulting

Featured on Tampa Bay Business Journal

When I began writing this article, I thought to myself, “I’ve written books about this…where do I stop?”

I won’t make you read a book today. I’m going to hit some highlights for executives who may spend more time running their business than managing their data — in a Letterman-esque list. (If you’re not old enough to know who David Letterman is, look him up when you need a chuckle.)

1. Are you certain you can restore your data? Has this been tested?

My company has acquired more than one new client because a corruption was backed up. Testing for corruption should be part of your backup process, and verifying a lack of corruption should be part of your restore test.

We’ve also acquired new customers because their databases have gotten so large that standard backups take too long, or a real-time restore would drastically blow up their SLA.

Finally, air-gapped backups (i.e., backups not on your SAN) are a critical component of ransomware protection. Whether you decide to pay a ransom or not, you will want the ability to perform a bare-metal restore. Remember, software and middleware also need to be backed up.

2. Do you have a board-cleared ransomware plan in place?

Ransomware happens. Chances are that at some point in your career it will happen to you. Sometimes this occurs because of an external hacker, but these days it is more often caused by a careless employee clicking on a malicious link in an email.

Make sure that you have a plan that you’ve run by your board. If your board clears your plan and you follow it, you are golden. If you do not have a plan, you are a target.

3. Is preventive maintenance being run correctly?

Recommended

I’ve personally performed hundreds of health checks/performance reviews at hundreds of client sites. I can count on one hand the number of times a complete preventive maintenance plan has been set up, followed and monitored.

Regardless of DBMS, your data needs to be backed up, maintained, indexes balanced and tuning reviewed. You need to have a positive mechanism for identifying that it either ran correctly, failed or didn’t run.

Many shops come close but lose it when it comes to knowing that a failure occurred, or that a job (like a backup) didn’t run.

This is a good place to consider doing a health check with an external resource that will also test your backup regimen against your SLA.

4. Is your data archiving happening? Does it meet all contractual and legally mandated requirements?

If your company has been around for 20 years, there’s a good chance you have 20 years’ worth of data in your databases. There’s also a good chance that your backups are taking longer, your storage is increasing and your restores are taking longer.

My team and I meet with a lot of companies that are implementing archiving projects right now, and it never ceases to amaze me how many people need to be involved in deciding how long data needs to stay online or recorded in an archive database. This requires knowledge of business needs, contractual needs and regulatory needs.

Get everybody into a room, take notes and make sure it’s signed off by all parties (because it will change mid-project). Finally, make sure somebody is responsible for making sure the jobs run periodically.

5. Are you using your data for all it could be?

Sometimes you don’t even know what questions you can ask when it comes to your data, and the answers to those questions can be worth money, or more.

Recently, an insurance company created a project to examine treatments for diseases in different parts of the country for efficacy. This strikes me as a great use for data that might not otherwise have been used. Insurance companies keep information on what the diseases are, how much it costs to treat and how long the treatment lasts. I’d have thought that it ended at underwriting, but no. Not only does understanding what treatment is better help their bottom line, it saves pain, suffering and perhaps extends or saves lives.

Sometimes you don’t even know what data you have until somebody chooses to look at it a bit differently.

6. Are you throwing hardware at a software problem?

I won’t get to a full Letterman top 10 so will end my list here.

I’ve lost track of the number of calls I’ve received that went something like this: “Jeff, I’ve just spent $10 million upgrading my hardware and the performance hasn’t improved. Got any ideas?”

It seems self-evident to me that you identify a problem before throwing resources at it, but sometimes when the users are screaming loud enough and offering to fund it, faster hardware seems to be just the right choice until it shows up and it wasn’t.

There are plenty of tools today that can help you identify both resource and software bottlenecks. I strongly recommend tuning the software first, then identifying a specific hardware bottleneck, then solving for that bottleneck.