Architecture Roadmap

The sequence of architectural change over time, grouped by theme, with dependencies visible and each bar tied to an outcome rather than a technology.

Technology Cloud-Agnostic
gantt
  title Target state — 18 months
  dateFormat YYYY-MM-DD
  axisFormat %b %y

  section Foundation
  Landing zone and connectivity      :done,   f1, 2026-01-01, 60d
  Identity federation                :done,   f2, after f1, 45d
  Observability baseline             :active, f3, after f1, 75d

  section Decouple
  Strangler facade at edge           :active, d1, 2026-03-15, 90d
  Extract order domain               :        d2, after d1, 120d
  Extract pricing domain             :        d3, after d2, 90d
  Retire shared order database       :crit,   d4, after d3, 60d

  section Data
  Ingest to raw zone                 :        a1, 2026-04-01, 75d
  Conformed customer entity          :        a2, after a1, 90d
  Retire nightly extract jobs        :        a3, after a2, 45d

  section Resilience
  Multi-zone for tier 0              :        r1, 2026-06-01, 60d
  Automated failover rehearsal       :        r2, after r1, 45d
  Second region for tier 0           :crit,   r3, after r2, 90d

What it is

Architectural change plotted against time, grouped into a small number of themes, with dependencies drawn as dependencies rather than implied by position. Each bar should be justifiable in terms of an outcome — a risk retired, a cost removed, a capability unlocked — because that is what the funding conversation is about.

When you produce it

When asking for multi-period funding, when a target state has been agreed and someone reasonably asks how you get there, and at the start of each planning cycle to re-cut it against what actually happened.

Who reads it

Executives and finance, who fund it. Delivery leadership, who resource it. Engineering teams, who need to see their work in a wider sequence. Vendors, who should see only the part relevant to them.

What good looks like

  • Four or five themes at most. A roadmap with eleven lanes is a backlog.
  • Dependencies are explicit, so the critical path is visible.
  • Retirement bars exist. A roadmap that only adds things is a wish list; the saving comes from the decommissioning.
  • Bars get vaguer further right, and the diagram admits it rather than implying the same confidence at month eighteen as at month two.
  • Each theme has an outcome sentence attached in the accompanying text.

Common mistakes

  • Technology names as bars. "Adopt Kubernetes" is not an outcome; "reduce environment provisioning from six weeks to one day" is.
  • No decommissioning. Then the estate only grows and the business case never lands.
  • False precision in the far future. Fixed-width bars in month twenty tell the reader you are guessing, but with confidence.
  • Ignoring the delivery capacity that has to run alongside the change.