The Cloud Roadmap: Where Your Vision Gets Real

This post continues a series on taking your cloud journey from strategic vision to practical reality.

In recent posts, I’ve discussed the process of establishing an organizational vision and strategy for cloud technology. Once you’ve established a solid, supported, long-term strategy it’s time to get tactical and the bridge between strategy and tactical implementation is your roadmap. 

Everyone gets roadmaps as a metaphor and that a roadmap is a detailed guide to the stages of an organizational evolution. But I find that people often aren’t sure what this kind of IT transformation roadmap should really look like. Let’s dive in.

What is a Roadmap?

The roadmap documents the transformation goals and the timeline to get your organization from where it is today to where it wants to be. It also notes the value delivered in each phase. 

Fitting between high level strategy and day-to-day tactics of project management, the roadmap gives you a sense of the logical sequence of steps needed to move from your present state (say, all on-premises IT) to the desired future state (say, 80 percent cloud-based with a cloud-first bias for any new technologies in three years). 

Sample high-level cloud roadmap approach 

Informatica Professional Services does workshops around roadmapping that go into considerable detail. The above sample diagram gives you some idea of what a roadmap looks like at the high level. This is just one viable format— roadmaps come in many forms and there’s not a single universal template to hunt for. What’s important is that your roadmap covers the right bases for both the business and the technical aspects of your plan:

• The current state: An accurate assessment of where you are today.
• The end state: Where you’re evolving to and when you’ll get there.
• The milestones: Which rollouts will happen and in what order? This is usually determined by logic (you’ve got to set up your cloud database before you can migrate data to it, right?) and by business need.
• The value: What does a given piece of technology do for the bottom line? What’s the business capability it provides, quantified in dollars?

Marking the Milestones

Each milestone or rollout on your roadmap requires some mid-level detail. The roadmap might note the following for each specific goal:

• The technology goal: What’s being implemented or migrated?
• Business dependencies: Will there be downtime for critical systems or data? How will disruption be minimized? (For instance, you wouldn’t schedule a revamp of financial systems at the end of the quarter or biz year.)
• The people component: Who is affected, what sort of training is needed. Are new roles being created? Is there hiring to do?
• Process: How will processes or workflow change when the new technology is rolled out? Have the actual processes been designed and is training in place?
• Disaster/disruption control: If something goes wrong, is there a plan to act quickly to minimize disruption (such as temporary rollback to old tech/systems)?

Truly granular detail, such as step-by-step time tables, training schedules and project staffing don’t fit here— that’s at the project management level. Here, you’re accounting for everything that needs to be done, so your project manager knows what to accomplish via a more detailed project plan.

Three Roles of the Roadmap

The roadmap is a tool with three important uses. The first, most obviously, is planning. As we just discussed, it lays out the stages of work toward achieving the desired future state and for doing it in a way that keeps the business readiness and IT capabilities in sync. 

Secondly, it’s a tool for maintaining buy-in. IT transformation is slow and often expensive and most multiyear visions are held hostage by annual budget cycles. The roadmap is a statement of commitment that helps you keep business stakeholders literally on the same page. 

And thirdly, it serves a related function to help maintain priorities. Any long plan will face challenges when business leaders discover a new urgent need. Sometimes there’s a valid reason to rewrite a roadmap, sometimes there’s a route to compromise and sometimes long-term priorities must defeat the “shiny new object.” But it’s up to the roadmap to show how all the pieces fit together and the value delivered at each stage and by the full transformation.

Final Caveat: Revising as You Go Along

Because a roadmap is a living document never carved in stone, it’s important to review it every six months or so. Huge business/industry changes or new technology shifts might prompt changes to better maximize results.

A common question in the roadmapping process is how to determine the “ideal state” and adapt it to your organization and needs. But that’s a bigger discussion around architectural planning—which I’ll discuss in my next post.