Abstract
Roadmaps are not new, but few companies have mastered this area. Product and Technology roadmaps are commonplace to guide a company as they decide on technologies, critical for their product development efforts. In this blog, we will start with an introduction to Roadmapping, then, in future blogs stay tuned for roadmapping for each of the domains for a consolidated architecture roadmap.
Introduction
Roadmaps are not new. Then, why are they not commonplace in most companies today? Roadmaps exist in most companies; they are used for Product Development and sometimes for Technology Planning, but they are seldom maintained consistently and they seldom are used to integrate from strategy to execution. There are many reasons for this. It is more important than ever to have an integrated roadmap to set out a well thought-out direction for both strategy and delivery. The main bottlenecks to efficient, scalable, and maintainable roadmapping are standards, content, and tools. In this blog, we will focus on standards. Eventually, we will set out a paradigm for the consolidated roadmap that builds from the existing industry standard, The Open Group Architecture Framework (TOGAF) and is vendor agnostic.
Why Roadmaps in a Nutshell
This is an apropos quote for the realistic achievement of a consolidated roadmap, "The test of a roadmap is not whether you follow it, but whether it is helpful in deciding what to do next.1" There are many outcomes that we would like to achieve for a roadmap, but this is the most succinct objective. It is not about detailed planning, it is about choosing the right direction from strategy to execution. Information Technology Departments are under pressure to respond to rapidly changing business models. According to one pharmaceutical company, the business cycle times have been reduced from 84 months to 6 months and the corresponding IT cycle time have decreased from 30 months to 3 months.
Figure 1 Example of Pharmaceutical Company IT Responding to Business Model Changes
As a result, setting the right direction for the business, processes, applications, and technology are even more critical to maintain that narrowing window from strategy to execution. Consolidated Roadmaps are an important tool to aim in the right direction as we try to hit that target of just 3 months.
Benefits of Roadmapping
For the readers, I wonder if it is necessary to summarize the benefits of roadmapping, but I want to include this, just in case you need to build a summary to your management about why you should do roadmapping.
- Roadmaps link business strategy and market data with product and technology decisions.
- Roadmaps reveal gaps in strategy, product and technology plans.
- Roadmaps prioritize investments based on business and technology drivers.
- Road mapping helps set better targets: more competitive and more realistic.
- Sharing roadmaps allows strategic use of technology across business units
- Roadmapping communicates business, technology and strategic plans to team members, management, customers and suppliers.
- Roadmaps provide a guidance, allowing you to recognize and act on events that require a change in direction.
Now, that we got that out of the way, let's get down to business.
How are Roadmaps Different than Project Plans
You will encounter this question, "We already have a PMO that manages projects, what is the difference with a Roadmap than a project plan? Isn't it the same thing?" The answer is that it should not be. If you find that it is the same thing, either rework what you are doing so you better align with roadmaps or you stop doing roadmaps and support the PMO for what they are doing.
Here are some aspects where a roadmap is different than a project plan:
- Generally concerned with longer timeframes than the project plans typically produced using project scheduling tools
- Deal with more strategic levels of information, and as such are often concerned with navigating through areas of high uncertainty.
- Multi-layered approach differentiates a roadmap from a project plan
- Helps to present information in a way that aids understanding of the linkages and dependencies between activities.
- Greater tolerance for the unknown - only sweat the big stuff
- Focus on key areas driven by business demand and uncertainty.
Figure 2 Roadmaps Deal With Levels of Uncertainty2
Conclusions
- Roadmaps are an important communication tool for companies including Architecture
- Roadmaps are the bridge from strategy to actionable Project Plans
- Bottlenecks to actionable and maintainable roadmaps are standards, re-usable content, and tools
- Standards should be developed for a roadmapping
- Standards will help build quality in architecture roadmapping, as well as help vendors to more effectively provide content and tools to build and maintain company-specific roadmaps
- Roadmapping is not a word, according to my dictionary......
References
1 Phaal, Dr. Robert: "Technology Roadmapping," University of Cambridge Centre for Technology Management, 2007.
2 House, Clay: "Architecture Roadmaps," ASUG Forum, 2004.
This blog is based on the ASUG Enterprise Architecture Roadmap Days. Be sure to attend one of the events coming to a city near you. The next even is in Atlanta on November 4th.
Also, there is a Roadmap Preconference Session at TechEd 2010 in Las Vegas. You will meet with more of the though leaders who have developed the SAP product roadmaps and meet with your colleagues who are developing best in class company architecture roadmaps.
