Classic mistake No. 1 for evaluating data: The SLA

We have to know how valuable a particular data set is to a business before we can implement an intelligent strategy to deliver the storage services that our stakeholders require.  I say this because even though our storage may be virtualized, our days most certainly are not. 

Just as it makes no sense to leave business-critical files unprotected, it also is unnecessary to overprotect data and apps that the business doesn’t much care about. The concept of data value allows us to assign appropriate levels of service to the data, so that we can heavily service some files and spend less time with others.  I think any overworked manager today who has trouble meeting maintenance windows will agree that there will be significant benefit if they no longer had to concern their staffs with overservicing junk files. 

In most cases, data importance is evaluated in one of two ways: the owner defines its worth via a service-level agreement (SLA), or the IT group makes some general assumptions about the data and follows through on them.

Relying on SLAs is mistake No. 1.  SLAs are potentially very useful when it comes to storage, but they all suffer from one problem of near-epidemic proportions: when it is time for business or engineering managers to tell IT what is important to their line of business, project, or department, these managers find that EVERYTHING they save is important.  The result of that thinking winds up in the SLA, and the IT team winds up backing up everything from key databases to the office football pool.  It is unlikely that a manager is going to tell you he keeps trivial data in his storage allotment, and this means that everything he owns is deserving of the best service levels you can provide.

The point here is not that SLAs are bad.  Quite the contrary.  EMA spends a lot of time advising clients on SLAs, and we really do understand that an SLA offers a tremendous opportunity for good. But improperly executed SLAs can suck scarce IT resources as certainly as the Red Sox will crush their fans’ hopes again this September.  And next.

The point then is that storage SLAs have to be raised above the current, selfish, level of “protect my data at any cost.”  IT managers need to establish a hierarchy of value among their various data sets, but in order to establish a hierarchy of services to go with this they will need buy in from each group that executes an SLA.

You may have ample evidence at your own site that you should have pushed back harder when an SLA was drawn up.  When budget constraints caught up with you, did you find yourself with too few assets to properly protect all that “critical” data?  If you are backing up too much data, and are not restoring it quickly enough when the need arises, it may be a good idea to help your stakeholders to a greater understanding of the relative value of their data. 

Good luck with that.

Next time: IT staffs without the guidance of SLAs use their own rules.