Understanding Storage Requirements
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?
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.