This page is often accessed by people looking for data on how to write an IT wide strategy. You can find pointers on how to write one here. This storage strategy will fit into the IT wide ideas at two levels; as the prototype of the overview, then as the detail behind the agreed overview.
Writing a Storage Strategy
Why do you need a storage strategy? A strategy gives you a sense of direction, a feeling that you know what you are doing and are in control instead of just responding to events. It also gives your boss the feeling that you are in control and you know what you are doing too. Strategy is about trying to predict the future and planning for it now. The one thing you can be absolutely certain of is that you will not always get it right! A strategy should not just be about technology; it should be about delivering business value. However storage hardware, software and processes are all changing rapidly so its impossible the write a strategy without considering technology.
How do you write a Storage Strategy? I suggest that the first thing to do is to speak to the person or persons that you are writing the strategy for and find out what they think a strategy is. I can give you my definitions of the various documents that some people call a strategy but I'm sure that everyone will have their own variations.
A Blue Sky Vision
If the sky is all blue then there are no clouds to obscure your vision and you can see for miles. A Blue Sky Vision then is what you would do in a perfect world if you had no restrictions on cost, technology capability or user requirements. It can be useful as a contrast to explain why you have to make realistic decisions in your strategy. So for example, you could say, 'my Blue Sky Vision would be ... but because of ... constraints my strategy is ...'.
A Strategy or Vision
This is a statement of where you think you should realistically be in x years time, taking into how much account money you are likely to get, potential customer requirements and availability of technology. Storage Strategies normally look forward for three to four years.
A Plan or Roadmap
A Plan is not a Strategy but is an essential accessory. There is not
much point in developing strategies that never happen and it is unlikely
that you will be able to realise a strategy in a single stage. A plan
is simply the route map that describes how you might reach your strategy.
At the very least, the plan should show where you expect to be each year,
and roughly how much money you expect to spend.
Position Statement
A Position Statement is not a strategy but describes where you are at this point in time. It is usually couched in terms of requirements and capability, for example, 'The Business requires that we can recover all their data within 24 hours. We can meet that requirement for most data, except for the image server. It contains 5 terabytes worth of images and could take four days to recover'.
Reference Architecture
Reference Architectures are architectural building blocks that have been used before, and are proven to work. They would typically be a set of templates combined with instructions on how they have been used in the past, or could be used for future projects. If you have a set of reference architectures then this means that you do not need to re-invent the wheel for every new project.
There is a straight link between these definitions and some people would combine the first four together and call the composite whole a strategy.
The Position Statement is where you are now, the Vision is where you want to get to and the Road Map is how you are going to get there. I'm inclined to call that combination a strategy.
Writing the strategy
A general comment first. Strategy documents can be very boring to write and even more boring to read. If you want to hold your audience then try to make things interesting. A picture is much better than the five paragraphs it would take to describe it and an informal narrative style helps the reader.
It is best to split storage up into components to reduce the complexity. I suggest that you carve it up in terms of the services that you deliver, such as space allocation, backup and recovery and disaster recovery. You could also split out any technical components like disk, SAN and tape hardware and ILM software. Once you have identified your components then for each component work through the following process.
Start with your blue sky vision. You are looking at the logical architecture at the top level here. You need to understand your goals and requirements first, then ask yourself the question 'If I was starting from a green field site and had no money or resource restrictions, what would I do?'
Then answer the questions, where am I now? What am I supposed to be doing? Am I doing it very well? How do I know?
Look forward to the end goal. Answer the questions, where does my business plan to be in 3 or 4 years time? How will their requirements change? Are they happy with what I do now? Are there any gaps in the position statements? How do I expect technology to change in the next 3 to 4 years? How can I reduce or contain costs? What constraints do I have? What compromises must I make to fit those constraints?
Now work out the plan. How much can I realistically do each year? What are the biggest risks and priorities? How much will each bit cost? If I have to provide something urgently and the strategy will not deliver in time then do I have to make tactical short-term decisions? How do I get out of those tactical decisions in future?
A strategy template
The following is a suggestion for how to lay out a strategy document.
Introduction
Who you are, what you do, team mission statement if you have one. Include a brief statement of where you expect to be in three years time.
A heading for each service or component
Summary
A brief overview of what this component or service is and how well it works. It can be effective to present the status of the service as a red/amber/green traffic light.
Business Drivers
Why the business need this service and what they expect to get from it.
Current Position
A bit more detail about what you are providing including shortfalls and gaps in the provision.
Strategy
Why should the position change, how will the business drivers and technology change over the next three years, how can you use technology to meet business needs, including fixing any shortfalls in the current position.
Route Map
The short plan for how you will get there. Include details of what will be delivered when, how much it will cost and what benefits it will provide. Indicate if the deliverables are strategic or tactical.
Conclusion
A 'joined-up' plan that pulls together all the plans from the individual components and works out the costs of the whole strategy on a year-by-year, or maybe quarter-by-quarter basis. This does not need to be at the level of detail you would expect to see in a full programme brief. As a suggestion, a simple table like this should suffice
Strategy Item
Completion Date
Deliverables
Tactical/Strategic
Cost
NAS install
31/06/2006
NAS connected to 4 servers.
DAS storage removed
Saving on management effort €3,000 p.a.
Strategic
€4,000
What should a Storage Strategy Contain?
You should start with your drivers for change. The main drivers for most companies these days are still compliance and rapid data growth. You may well have other business drivers that are specific to you like acquisitions and mergers. Details of these types of change are usually unknown until they hit you, for stock market compliance reasons. The key to coping with this them is to make your infrastructure flexible.
It is a good idea to standardise on common sets of hardware, partially to achieve that flexibility and partly to keep running costs down. A good rule of thumb is to stick to two or three hardware vendors, as that keeps things manageable, while retaining an element of competition.
When making hardware purchases people claim that price is not the most important factor in making a decision. The most important factor is product features, then services, then price. The storage subsystem comparison section might help you with disk selection.
In general, very large companies are segregating their data by application on discrete subsystems, while large to medium companies are consolidating their data into a single large subsystem. Most companies are using, or seriously considering SAS/SATA drives for backup and archiving, and even for primary data.
Despite repeated rumours that tape is dead, it is still important for many people, and not just for traditional backup and recovery. Compliance and Data Archiving are big tape users these days. The tape section contains details of tape types and capabilities.
Storage Virtualisation does not appear to be taking off yet. The benefits appear to be limited to making it easy to move entire disk volumes between different disk subsystems. This has its uses, but it is not something that you do very often. I think that virualisation will not mature until it can handle data at file level, and be part of a true ILM implementation. The virtualisation section has details. My position or strategy on disk virtualisation is wait and see.
One piece of storage virtualisation that is mature is virtual tape. Vtape
is almost essential to effectively use the modern high capacity tape drives and should form part of any medium or large business strategy. The virtual tape section has details.
Once you have all your hardware installed, you need to couple it all together. We have a lot of connectivity choices these days, Fibre Channel, iSCSI, GB Ethernet to name a few. Most large companies have installed a fibre channel SAN to handle all their centralised storage. In general, large companies are using or moving to director based SANs, while smaller companies prefer the core/edge model or maybe just a switch network. It is really all down to manageability as a large company would really struggle with hundreds of 1Gb 16 port switches, while a small company could not justify the expense of a large director. The SAN section has details. You should Zone your SAN by application to contain the impact of failure.
If you can afford it, you should seriously consider test hardware systems that as close to production as possible. This allows you to test hardware, firmware and system software changes in a risk free environment before it goes into production.
Software can be broadly classified into three types; Backup and Recovery, Data Management and Data Discovery. Your software should always be hardware independent to avoid vendor lockin.
Backup and Recovery software is very difficult to swap out, as apart from catering for change on all your clients, you also need to consider all those archive backups you are keeping for compliance reasons. If decide to you change your backup software then you need to copy all the old backups to the new format. For this reason, you do not change your backup software without a really good reason.
However, there are some good reasons coming along. Traditionally, we took backups from disk to tape in a dedicated window. Backups now can be 'D-D' (disk to disk) or ' D-D-T' (disk to disk to tape. You might also want to include continuous backup in your strategy.
Your strategy should also mention disaster recovery (DR). Most site are using some kind of remote mirroring these days; small sites are going for asynchronous IP, while larger sites are using synchronous mirroring.
Finally, you should mention data management software and include acronyms like ILM, SRM and ECM. All the vendors are saying that 2007 will be the year for ILM, but I remain skeptical. SRM is about knowing your data. That is easy on mainframes with products like FDReport, but much more difficult on open systems.