Understanding Storage Requirements

A few months ago, I received an email from a reader in Australia, Iain Anderson, who took issue with my article Purchasing Professional Storage Services, Part 1. Here is what Iain had to say:

An important aspect which I believe may be missing from your paper is IT practices, which your storage vendor should be engaged with. Increasingly, as components within the storage model commoditize and data is still poorly understood and managed, the PS organization of choice needs to include competencies such as:

• Information management — to understand why the storage components are used
• Strategic development — to set information management strategies
• Enterprise architecture — to maintain the infrastructure standards to ensure reuse, consistency and economies of scale are realized.

After thinking about this, I agreed. Iain is correct: Storage architecture is all about knowing and determining the requirements, or making your best educated guess when you can’t know for sure. In my article, I had made the implicit assumption that customers know their requirements, but as Iain pointed out, more often than not that is not the case. Iain, who works for EMC as a national practice manager for consulting, went on to list other competency requirements:

• Business Continuity Planning Process (BCP) /Disaster Recovery (DR) — so that technical recovery strategies are tightly coupled to the business continuity objectives, and hence enterprise risk management
• Record keeping and archival management — so that storage solutions are optimized against a long-term view of information management
• Operations management (ITIL, or IT Infrastructure Library), including SLA frameworks — because research shows that a significant portion of the TCO comes from the execution of the storage solutions.

Most vendors have moved away (in spirit at least!) from box dropping and living off their technical prowess. Certification standards and ever-growing channels show there is an army of talented folks bearing screwdrivers and UNIX manuals.

Whether Iain’s last comment is correct could be debated, and could depend on where you live, what vendors you deal with and even the people the vendors have working with you. However, his comments about competency requirements for professional storage services are completely and totally accurate. It would be nice if all vendors had the same level of knowledge and understanding of the process as Iain, but as they say, caveat emptor: Buyer beware.

So what should everyone know about the requirements process, and what are good sets of questions to ask vendors to see if they have the skill set to help you solve your problems? I believe Iain is absolutely correct that a vendor cannot help you solve your business objectives unless you know what those objectives are and have at least some understanding of the technologies and costs.

Determining Your Requirements

Sometimes customers have unrealistic expectations. I recently had an experience with a customer that told me that they wanted a highly reliable, fast, scalable, simple backup solution for 6TB for $50,000. I told them that they should increase their budget by about 2 1/2 to 3 times that amount in order to meet their business requirements. They responded, “We only budgeted for $50,000 and no vendor can meet our requirements. Can you help?” I told them no, and said they needed to increase their budget significantly.

Before you call a vendor, you should have a good understanding of your requirements, or as a first step you need to have someone help you gather those business requirements. Whatever you do, some simple questions need to be answered before you hire someone to help you or begin the requirements analysis process yourself.

Four Steps to Storage Happiness

What do you need to ask yourself to understand your requirements? I have found that the following four simple steps give everyone involved in a project a well-grounded understanding of expectations and how business requirements relate to the potential network, hardware and software architecture.

Whether you end up doing the integration work yourself or hire an outside contractor, you need to go through these steps. Even if you outsource your whole operation, these steps are important to ensure that you have clearly defined your expectations to the outsourcing organization.

Step 1: What are the business requirements?

The first step is to gain understanding of the organizational business requirements. These are generally high-level requirements, but include some critical areas such as:

• What is the expected budget for the project for each year?
• For some organizations, especially government organizations, what is the operation and maintenance budget for each year?
• What is the expectation for how long the hardware, software and project will last?
• What are the business continuity and continuity of operations expectations for this project?
• What are the expectations for how this fits into the enterprise architecture?

You need to be able to answer each of these questions to move to the next step. How could you plan an architecture without a good understanding of what the expectations are of management? Therefore, the first step is to sit down with management to understand their expectations.

Step Two: What does that mean?

Given that management has just given you a set of requirements, what does that mean in technical terms when you define an architecture?

For example, your management may want 99.99% system availability (51 minutes of down time per year). What does that translate into for system architecture, given that the failure of a large server and the repair will likely take more than 51 minutes? Add issues like HBA failover and switch failover and it becomes clear that a high-level set of architectural requirements can be extracted from management’s business requirements. In addition, the business continuity planning will provide you with a detailed set of requirements that translate into an architectural design and cost.

You also need to add the costs of training, ongoing engineering, and other operational tools and functions that management might not have considered.

Step Three: What is available?

Now that you have management expectations and you have translated them into a high-level set of architectural requirements, you need to do a bit of research to determine what technologies are available in the market today and what is going to be available in the near future.

Reviewing various technologies is not difficult thanks to the Internet, and since at this point you have a good understanding of what high-level architecture you need, doing searches of technologies won’t be difficult.

I am not a strong proponent of asking technology questions via a USENET post such as “What is a good technology to solve problem xyz.” I see these postings often, and since you do not know who is responding, sometimes you might get answers from someone who is very knowledgeable, while other times you might get someone who sounds knowledgeable but is not. Determining if a respondent is knowledgeable and whether they have a vendor bias is difficult, if not impossible. This is another way of saying you get what you pay for. However, if you see regular posts from someone who seems knowledgeable and independent, it might be worthwhile to hear what they have to say.

Another part of this step is to look at some rough order of magnitude (ROM) pricing for the technologies that will meet your requirements. Releasing an RFP or RFQ on the street for an architecture that meets your requirements, but causes sticker shock for you and management when responses are received, delays the inevitable: the architecture must change.

Step Four: Setting expectations

Once you have developed a high-level architecture, and determined the ROM price you need to match that architecture within the available budget, including operation and maintenance costs, you should show management how much each requirement will cost in terms of the software, hardware and network needed to carry it out. Maybe management cannot afford some of the requirements, but from what I have seen, it is important to present the architecture in terms of the requirements and the resulting cost.

The best way to do this is to have a meeting with the management team and present the requirements and the resulting architecture, with the cost of each of the requirements overlaid with the architecture. Yes, this is PowerPoint Engineering, but it is an effective tool. From my experience with this process, even the bean counters get it when you lay it out this way.

Conclusion

Of course, you might not have the luxury of having a group of people that can develop a high-level architecture and determine the resulting cost. Sometimes you need to bring in professional help in the form of a vendor, independent consultant, or a new employee.

However, you don’t get all the information you need — the high-level architecture and resulting ROM cost — by just giving vendors and integrators a set of requirements and asking for bids. That method just gives you the potential for sticker shock. After the sticker shock wears off, you generally wind up back at the drawing board determining the cost of the requirements anyway, so you might as well do it up front in the first place.

I have been working on high-performance computing problems for more than 23 years, and I have never seen a situation where a customer has been successful in deploying a new architecture without understanding their business requirements and getting agreement on those requirements from end-to-end in the organization. I have seen a huge number of failures where that process hasn’t been followed.

I am a firm believer that in most cases, requirements are best obtained from within the organization, followed by outside peer review. If the organization uses an outside consultant to gather requirements, it should be done working hand-in-hand with the organization’s own staff to ensure that all of the management and workflow requirements are addressed. The review could happen from a consultant, vendor, integrator, or another part of the organization, but in most cases, internal review within another part of the organization seems to be the best approach.

This article started with a comment from a reader in Australia. I think this shows that requirements gathering and system architecture are all universal needs. We might have differences around the world on how requirements are gathered, but whatever the process is in your country, region or business area, you must know your business requirements before you can start the architectural process. Many thanks to Iain for reminding all of us of this.

» See All Articles by Columnist Henry Newman