Roadmap architecture

Roadmaps are unusually flexible. That makes them adaptable to products, policies, technologies, capabilities and whole systems, but it also creates a design burden. Phaal and Muller argue that a roadmap must be configured for its purpose and context. The architecture includes not only what appears on the page, but the process that generates it and the participation needed to make it credible. [1]

Begin with the decision the roadmap must support. “Align our battery technology investments with future vehicle platforms” suggests different layers, participants and evidence from “coordinate a regional transition to low-carbon heat.” Copying a familiar template before clarifying the decision can create an orderly map of the wrong system.

The horizontal dimension normally represents time: past or baseline, present, short term, medium term, long term and perhaps a vision. The vertical dimension represents the system’s perspectives. The generic why–what–how architecture asks why action is needed, what should change and how it can be achieved. Phaal, Chaskel and colleagues express the same canvas through six fundamental questions: where are we now, where do we want to go, how can we get there, why act, what should we do and how can we do it. [1][5]

The labels should use the organisation’s language. “Customer value / service / process / data / people” may be clearer for a transformation programme; “policy drivers / system outcomes / infrastructure / research / investment” may suit a public roadmap. Architecture is successful when participants know what belongs where and readers can reconstruct the strategic logic.

Layers are not valuable merely because they sort content. Explanatory power comes from relationships across layers and time: a regulation creates a performance need; the need changes a service; the service requires a capability; the capability depends on research and investment. A roadmap with hundreds of unconnected items may be a catalogue rather than a strategy. [4]

Use links selectively. Show dependencies, enabling relationships and important alternatives - the connections that change a decision. A dense web of lines can conceal rather than reveal. If a link needs explanation, attach a short rationale or evidence reference so later reviewers do not have to infer why it exists.

Time horizons should match the pace of the system. Software releases may need monthly precision; infrastructure or research capabilities may need multi-year bands. Precision should also decline with distance: a dated near-term commitment can coexist with a longer-term direction expressed as a range or milestone. False detail makes uncertainty look like certainty.

The working canvas and the communication view do not have to be identical. Kerr and Phaal distinguish the information needed from the visual form used for a particular audience. A delivery team may need detailed dependencies; an executive audience may need the few choices, risks and resource consequences that require attention. Both should be generated from the same strategic logic, not maintained as contradictory stories. [3]

Write a one-sentence purpose and identify the decisions, audience and system boundary. Sketch the minimum useful layers. Choose a time horizon and meaningful bands. Define the item types and links allowed in each layer. Test the canvas with a handful of real content before the workshop. Then adapt the prompts, participation and sequence. The classic market–product–technology form is a strong reference architecture, but the literature repeatedly treats it as a basis for customisation rather than a standard to copy blindly. [2][1]