There are lots of different ways to define and write a strategy. The IT strategy page describes how to write a simple, single page strategy. This is often preferred as it is short and to the point and so is more likely to be read. This strategy page describes how to prepare a more traditional, detailed strategy which is more based on technological capability. However you could easity adapt the single page method if that is your preference.
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 it's impossible the write a strategy without considering technology.
The bottom line for any storage strategy should be to ensure that data is stored in the most cost-efficient way, it gets the correct level of performance for the application, it is retained so that it is recoverable in case of a disaster and is compliant with legislation. You also need to ensure as far as possible that required data is never lost, and you have adequate capacity that can easy scale as storage needs grow.
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.
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 ...'.
This is a statement of where you think you should realistically be in x years time, taking into account how much 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 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.
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 25 terabytes worth of images and could take four days to recover'.
There is a straight link between these definitions and some people would combine them 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.
Strategies are often associated with projects, and Reference Architectures are useful aids for planning strategic projects. 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.
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. Unfortunately, most organisations insist on a formal style for strategy documents.
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 then is to make your infrastructure flexible.
It is best to split storage up into components to reduce the complexity. I suggest that you carve it up in terms of hardware components and services that you deliver. Examples would be Cloud, Disk and Tape storage, Storage Networks, space allocation, backup and recovery and disaster recovery. Taking these elements in turn:
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.
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 now using a mix of disk types; Solid State, Fiber Channel disk and SAS/SATA drives for backup and archiving, and even for primary data.
The easiest way for an SME to achieve shared storage for is to introduce Network Attached Storage (NAS). NAS devices combine a RAID protected disk array with NFS and CIFS protocols so they can deliver file-level data to clients on the network.
The storage subsystem comparison section might help you with disk selection.
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 and storage tiering are now mainstream. The ability to automatically move data between different types of storage at block level, depending on how active it is, is bringing enormous benefits. The virtualisation section has details.
Virtual tape 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. iSCSI SAN devices are cheaper than Fiber Channel and are more suited to SMBs. They serve data at block level to the file system on servers, but use the existing TCP/IP LAN infrastructure instead of needing a Fiber Channel SAN.
The SAN section has details.
If you can afford it, you should seriously consider test hardware systems that are 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.
As storage pools get ever larger, the traditional method of backup up from live disks in becoming impractical. Backup from snapshots is the answer, or maybe even using snapshots as backups.
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.
Policy based storage has been around for a long time. The idea is that you assign values to every piece of data that can be used to determine what kind of storage service it gets as that data progresses through its lifecycle. The big problem with this it that it an almost impossible task to analyse each piece of data and get business buy-in to determine what service it needs. Business requirements usually come down to best possible service at cheapest cost. The consequence has been that most companies just provide a single class of service, and all data gets that class.
This issue has been resolved recently with the introduction of advanced automated data tiering at block level. You may still need to make some high level decisions about which kind of data needs to be installed in which tiering systems, but low level decisions are made by the automation. For example, you may decide that Oracle Databases should be on a 2 tier 'solid state' and 'Fiber Channel' tiering system, while Office data can be held on single tier SATA disks.
PC data is often omitted from storage strategies, partly because it is controlled by the desktop team in most organisations, and partly because it is a contentious issue. Business customers were always told never to store vital data files on their PC local drives, and if they did, it was in a controlled, encrypted directory. Ideally the desktops were locked down to enforce this. With the proliferation of hand held devices and the BYOD to work concept, these policies are becoming unworkable. If you allow controlled data storage on desktop and handheld devices, then you need policies for controlling access and for backup and recovery.
The following tips might help you to develop a Policy Based Storage Strategy
Outsourcing was in fashion a few years ago, but has declined in popularity recently. Outsourcers made their money by charging extra for all the items that were not in the contract, and it seems to be that the actual cost case for outsourcing has not stacked up so well as the theory. It could be worth inserting a paragraph into a strategy document that explores outsourcing and explains options. Cloud Storage should definitely get a mention. It actually makes a lot of sense for small and medium businesses as you can pass all these issues over to a Cloud provider and let them worry about what type of hardware to use. The Cloud Strategy page has some pointers on how to do this.
Like any other strategy, Cloud storage should not be about cost, but also about risk and complexity. Cloud Storage is an on-demand. pay-as-you-go model that does not required up front Capital expenditure, but runs from Operational expenditure. For some reason, accountants are much happier with OPEX. The problem is that the data is still yours and you still need to understand it. You need to know retention and legislative requirements, and you need to know that the data you send to the cloud is required, otherwise you are wasting money.
The following is a suggestion for how to lay out a strategy document.
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 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.
Why the business needs this service and what they expect to get from it.
A bit more detail about what you are providing including shortfalls and gaps in the provision.
Why does the current position need to 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.
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.
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.