Architecture Roadmap
A sequenced plan of architectural change expressed as capability outcomes and decision points rather than as a fixed timeline of projects.
Architecture roadmaps fail when they are Gantt charts of technical projects: they are obsolete within a quarter, they cannot be defended when priorities change, and they invite the question of why the business should fund a sequence of technical activities.
The framing that survives contact with reality:
Outcomes rather than activities. "Deployment lead time under two hours" rather than "migrate to Kubernetes" — which keeps the objective stable while allowing the approach to change, and allows the work to stop when the outcome is reached.
Horizons rather than dates. Now, next, later. Precision in the near term, direction beyond it. A date eighteen months out is fiction, and stating it as fact damages credibility when it moves.
Decision points marked explicitly, so the roadmap shows where a choice will be made and what evidence will inform it, rather than pretending the choice is already made.
Dependencies and enabling work visible, since the sequencing constraints are usually the reason a desirable item is not first.
Two things that get an architecture roadmap funded: tie each item to a business outcome or a named risk, and express enabling work in terms of the compounding cost of delay — every quarter without it, everything downstream is slower.