8 steps to building and maintaining an infrastructure road map

An outside observer might imagine that just about every IT department would have some kind of technology road map. After all, without one, how could you avoid costly mistakes such as overspecifying or underspecifying new infrastructure hardware purchases? But all too often that documentation simply doesn’t exist for one very simple reason: How can you possibly build a coherent technology plan in the face of immediate and constant change?

The trouble is that a plan that includes the additions and modifications to your infrastructure you’ll make over the next three to five years often takes so long to do correctly that it’s completely outdated when you’re done. That alone is enough to cause many IT departments to simply give up and resign themselves to a life of reacting solely to immediate needs — a stressful existence invariably resulting in blown budgets and orphaned hardware that was outgrown far too early in its lifecycle.

It doesn’t need to be this way. You can plan for the future in the face of rapid change without all of your work being for naught. Here’s an eight-step process for such a task; I’ve found it works well.

First, define the period of time your technology road map will cover. This varies based on several factors, including how often your organization adopts new technologies and what your long-term budgeting requirements are (or should be).

Generally, this window shouldn’t be shorter than two years; a plan focusing on a horizon any closer than that isn’t likely to be of much value. Similarly, it probably shouldn’t be much longer than five years — it’s usually too difficult to imagine where the state of technology or your organizations needs will be beyond that.

Step 2: Build a generalized infrastructure questionnaire

The next thing to do is define a questionnaire that lays out all of the basic requirements to be placed on your infrastructure. At this point, you’re not trying to provide answers to these questions — you’re just defining the questions. You also want to be careful not to delve too deeply into specific technologies; you’ll get into that nitty-gritty later.

Instead, focus on high-level questions. You’ll likely find that many of these questions are entirely nontechnical in nature — as it should be. Here are some very generalized examples I’ve seen:

• What is our year-over-year data growth?
• What is our year-over-year compute capacity growth?
• Are we aware of any new applications/initiatives/technologies that are going to be introduced?
• Does the business have any long-term expansion plans (such as new offices)?
• What are our uptime/reliability requirements?
• What are our RTO/RPO (recovery time and recovery point objectives) requirements?

When you’re done, this list will be fairly extensive. What you’re looking for are questions you’d need to answer to allow someone (even a third party) to design a greenfield infrastructure that could shoulder the load and meet the policy requirements your business stakeholders are demanding. If there isn’t enough information in your questions to do that, you aren’t done yet.

Step 3: Find the answers

Now the fun part: filling out for the first time the questionnaire you created. Answering some of these questions (data growth rates, for example) may require that you implement monitoring tools you don’t have in place. Others may require difficult conversations with your business stakeholders to force them to put real numbers on policies such as RTO/RPO.

Step 4: Design a future-state infrastructure

Once you have a completed questionnaire, it’s time to design a greenfield infrastructure that would meet the requirements dictated by the answers provided at the endpoint of your planning horizon (be sure to compound the annual growth figures over that period). You want to include everything you think you’d need to meet the requirements at that endpoint — even if you already own a lot of it.

When you do this, be sure not to include specific technologies or products; chances are those technologies will have changed by the time you reach the horizon. Instead of saying that you think you’re going to need an EMC Clariion CX4-240 with a 95TB of storage capacity and 30,000 IOPS of transactional capacity, generalize the model to “a primary storage solution” and keep the capacity figures. For cost calculations, round off the current cost of a currently available model as a budgetary placeholder.

If you don’t have the bandwidth or experience to do this kind of design work internally, don’t be afraid to farm it out to a trusted consultant or adviser. Given that you’ve already covered all of your requirement information in Steps 3 and 4, even a third party that doesn’t know you well should be able to take care of this.

Step 5: Get buy-in

The next step is to take that future-state design to your stakeholders (specifically, those controlling your purse strings) to validate that they’re on board with your long-term plan for the infrastructure and its overall cost. This is where you find out if those stakeholders who told you they needed five nines of reliability are willing to pay for it. If they aren’t, you can go through whatever iterative process is necessary to modify their expectations and decrease the cost of the infrastructure design — or convince them they’ll have to pony up if they really believe they need those levels.

Step 6: Perform gap analysis

After you’ve been granted tentative buy-in, it’s time to define the gaps between your current infrastructure and the long-term infrastructure design. This step defines what changes you need to make between the current state of your infrastructure and the end of the planning horizon — answering questions such as:

• How many more virtualization hosts will I need?
• How many more switchports will I need to deploy?
• How much disk capacity do I need to add to my primary storage environment?
• Can my current storage platform scale to that extent?
• How much more throughput/storage will my data protection environment require?
• Will my current data protection environment scale to that extent?

Step 7: Build the road map and start to implement it

After you’ve defined where your gaps are, you can start to plan when those changes should actually be executed to stay ahead of growth. You can define as projects those that may happen in the current budget cycle, and you can begin choosing specific products and specifications for them.

By having long-term requirements before you start selecting products, you’re in a much better position to make product choices that will survive the test of time. Consider primary storage as an example: You’ll know with some accuracy when you’re going to outgrow the Clariion CX4-120 you currently operate and know that by the time you reach your planning horizon’s endpoint, you’ll need something similar to a VNX5500 — not the VNX5300 that might’ve seemed like a better option in the short term. Better yet, you’ll have all the information necessary to justify that choice when it comes time to get the funds.

Step 8: Maintain the road map

It’s often said that a good planning process never ends. However, you’ve already done a lot of the hard work, so updating the road map shouldn’t require anywhere near as much effort as creating it. All you need to do is periodically review both the questionnaire and the answers you came up with the first time and evaluate whether any of them have changed. If they have, modify the end-state design to incorporate those changes in requirements. Then update your gap analysis to include those changes.

As with setting the planning lifecycle, the frequency with which you’ll want to revisit your plan varies; I’ve seen some organizations do it monthly and others do it quarterly or even every six months. Just be aware that the longer you wait between revisions, the more difficult those revisions are likely to be.

Boy, that sounds like a lot of work!

It is! No infrastructure planning process will ever really be easy. The trick is to make the time you spend planning be as effective and valuable as possible. Although this particular approach may not work for you, certain parts of it may. Working the process from the end of the plan to the beginning will avoid a lot of rework in situations where the current state is a fast-moving target.

Whatever you do and however you do it, don’t abandon technology planning completely. It only takes the avoidance of one big planning mistake (that choice on replacement SANs, for example) to make the entire process worthwhile.

This article, “8 steps to building and maintaining an infrastructure road map,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.