Advisor

Using Roadmaps Strategically

Posted February 1, 2017 | Leadership |
Figure 1 — Tracing a roadmap to projects.

One of the architect’s key roles is to proactively manage and architect change … and this requires some sense of future direction. So, in a recent Update, we explored some ways architects help key decision makers form, manage, and use their strategic knowledge in collaboration with enterprise architects. In this Advisor, we look at roadmaps, which are clearly an important technique to help the EA team deliver strategy.

Roadmaps have two key functions in strategy planning. The first is to outline planned architectural changes that will deliver the required strategies; the second is to outline alternative ways to achieve the same results.

EA roadmaps can show the intermediate states of the architecture in various ways, but I recommend the use of patterns. For high-level, enterprise- or strategy-level roadmaps, use enterprise patterns. For lower-level, more detailed roadmaps, use patterns that show the appropriate level of detail; for example, this might be an application pattern at a domain level or a solution pattern at the project level.

The number of alternative roadmaps presented to stakeholders and decision makers will vary depending on various factors, such as the importance of the changes, the priorities, the need to achieve results in differ­ent time frames, and so on. The important point here is that each alternative must include the information that stakeholders will need to select one approach over another. Enterprise patterns are good for showing the relative cost, risk, value, synergies, and future options for each architectural state. In addition, each roadmap alternative should include a summary of its benefits, risks, costs, value, and potential time frames.

It is also important to separate an “architecture” roadmap from detailed project plans. The architecture roadmap should be a lot simpler than the detail in most project plans. At the same time, it is crucial to trace the links, relationships, and dependencies between architectural states and the project that will deliver the elements of each state. Figure 1 illustrates this process; bear in mind that this shows a complete high-level EA roadmap, where there may be 250 or more projects!

 

Figure 1 — Tracing a roadmap to projects.

Figure 1 — Tracing a roadmap to projects.

 

Future Options

While roadmaps are good for the strategic discussion of alternative investment and change programs, there is another advantage offered by architectural thinking. Every architectural state contains the potential for future development. For example, if an organization develops a new data architecture that standardizes all data elements across the entire enterprise, this provides a very solid foundation for future options to rationalize processes, products, events, or business rules. A more fragmented architecture state would not provide these options without some intermediate states to improve necessary aspects of the architecture.

It is important for the EA team to spell out these future options. From my experience, most EA teams fail to discuss future options, which is a pity because it is so easy to describe the key benefits (and sometimes also the limitations) of any architectural state. Personally, I would include information about future options as part of the description of an enterprise pattern.

About The Author
Roger Evernden
Roger Evernden has been an enterprise architect since 1984, specializing in the highly practical use of EA to manage organizational transformation. Mr. Evernden acts as advisor, mentor, and coach on EA initiatives, leads training workshops, and writes regularly about strategy and architecture. He provides a unique combination of training and tools to help architects and their teams throughout an EA program and at each capability level. Mr.… Read More