We’re on the Road(map) to Nowhere

The Talking Heads song about a journey to an uncertain destination is an appropriate title for this piece. Most of the Enterprise Architecture teams we work with incorporate roadmaps into their architecture and planning work. It is a sensible approach to help business and IT management quickly understand the state, scope, direction and risks associated with an existing or desired business capability, and to then facilitate rapid decision making to release funding and resources for execution. Because we know a key performance objective for enterprise architects is to help accelerate investment and implementation decisions.

So the point of the roadmap is to capturing the current state of a business capability, a desired future state and a set of actionable projects required to transition the capability to its desired state. We know that business is interested in earned value, and so at the conclusion of each transition project, the capability should be exist in a form that requires no further investment. This allows business to divert budgets to more pressing projects as needed.

So here are some problems that we often see when reviewing client roadmaps.

• The roadmap represents only a single architectural domain (such as the business layer or the systems layer) and therefore does not provide sufficient insight to business to facilitate rapid investment decisions. Management needs context, and so a well defined roadmap incorporates business, information and system models.
• There is no formal approach for the roadmap to be analysed in relationship to the rest of the project investment portfolio. This means that the transitional projects are viewed as isolated activities, and therefore business misses out on potential synergies with projects that have already secured funding.
• There is no continuity between the architects that developed the roadmaps and the architects responsible for execution. As the roadmaps are typically conceptual-level views, there exists considerable ambiguity as to how implementation should be pursued. We have only seen this work well when the roadmap contains considerable detail, including specific measurable objectives for success. These are rare cases, due to the perceived amount of effort involved in creating a roadmap of such detail. For the most part, the implementation team pursues what they perceive the roadmap to mean, and the end result diverges significantly from the original intent.

Roadmaps are a useful method for capturing the evolution of a business capability. Success comes from the creation of a holistic view of the capability, formal planning of the transitional activities, and ownership by the Enterprise Architecture team of the outcome, not the roadmap itself