Recently, I had a customer ask for further clarification on a proposed storage assessment. They, wisely, had asked third parties (Gartner) to give them perspective on the value of doing a storage assessment. The third party, expensive, consultancy came back with four major areas that should be addressed:
- Proper provisioning of storage
- Maximize ROI by devising Data Lifecycle tiering strategy
- Capacity planning for future purchases
- Validate disaster recovery strategy and intra-company SLA’s
The customer, again wisely, asked us and the two other bidders to explain how our proposals would address the above. My response was very targeted, but had some insight that I think should be thrown to the aether. I’m also expanding it a bit since the original response did not address all of the points (they were out of scope for what we were trying to do).
So without further ado, here’s my thoughts on this:
1) Proper provisioning of storage
Gartner identifies this as an issue because most organization do not have a good understanding of what storage they have and how it is allocated. In addition, most organizations allocate storage as a “knee jerk” reaction to demand. By that, I mean that most allocation is done either by satisfying the customers requests (“I need 400GB of disk for my SQL database”) or by including storage in the acquisition of servers. These types of allocations do not consider the true cost of data management or even the true storage requirements. Provisioning is also typically looked as a one way function: storage allocation. However, there is a flip side to this: storage reclamation. As you well know, most users will over request storage because it’s easier to go to the well once. Very rarely, if ever, will they tell you “I asked for too much – you can take back 200GB.”
So, the first step in establishing a provisioning strategy is to understand what storage you have, how it’s allocated, and how well it’s being utilized. Once you have that understanding you can start making more informed strategic decisions on how your business should operate the storage infrastructure. With that in hand you can then start creating policies and procedures regarding your storage allocation and de-allocation. Only then will you be able to design a technology architecture to support your business requirements.
A good star for an assessment, internal or external, should give you: and understanding your current policies, procedures, and infrastructure. Additionally, it should make some broad recommendations as to the direction to take for your next step. However, determining a complete storage provisioning and management policy should be a project of it’s own right.
2) Maximizing ROI by devising Data Life cycle tiering strategy
Similar to point #1, the first step in understanding your data life cycle is to map your current storage. Any strategy needs to consider the results of #1 and do exactly that for both your unstructured and semi-structure data (files system, and email). An analysis of the data should give you the ammunition necessary for you to determine what tiering structure makes sense for you. Careful consideration should be given to the results to match them to industry best practices. However, those best practices should only be a guide as each business is different. The ultimate strategy will be a blend of best practices and targeted site specific practices.
3) Capacity planning for future purchases
This, again, ties to point #1. Capacity planning is part and parcel of a provisioning strategy. Because storage, systems, and growth in most companies varies drastically, a plan should be developed for the projected requirements for the subsequent 18 months. This will assist you in planning for the current, expect growth. However, as is the nature of any assessment like engagements, the recommendation are created only with data that identified during the duration of the engagement. If your business changes unexpectedly or grows faster than the projections created during the engagement, the recommendations will probably not be accurate. This is where you would need to have a capacity planning process that accommodates for changes. This process would, but it’s very nature, need to be something that is on-going and self monitoring. Typically, It is outside the scope of and assessment to device this capacity planning process. However, it is something that you should be able to device, albeit with some minor help, after this type of engagement.
4) Validate disaster recovery strategy and intra-company SLA’s.
Storage provisioning, allocation, and capacity planning is part of a properly maintained DR strategy. However, many companies fall into the trap of believing that a data protection or data replication plan is the DR plan. They neglect to consider the people and non-IT processes that are required to implement disaster recovery. While it’s true that these data based protection mechanism can help in the case of minor or even major disasters, a DR plan should be primarily based on managing the business processes in the case of an “event.” A good storage protection strategy would be used to accelerate the recovery process, but not be the recovery process. Any assessment engagement that addresses this element, should be focused on either how to implement a data protection methodology, or how the current or proposed protection systems map to the larger DR plan. The only way to drive these results is to create or validate SLA’s amongst all of the business units or stake-holders.
Speaking of which, that is the other most common failure amongst many of my customers. Data protection mechanisms are created based on perceived needs rather than any measured or clearly defined business requirements. As an example, it’s very common to encounter sites that use backup technologies to capture nightly incremental backups and once weekly full backups. These are typically implemented across the board without considering that some applications require more frequent, or even less frequent backups. Often, secondary protection mechanism are implemented by application groups, DBA’s, or even non-storage system’s administrators. These secondary schemes are in place because the system wide protection mechanisms are perceived as either in-adequate or not realistic to their needs. These are clear indications that the overall DR strategy is flawed, and needs to be addressed.