A3.6 · The roadmap layer
The program roadmap
A chapter roadmap orders rungs. One altitude up, the program roadmap orders whole chapters — the roadmap of roadmaps.
The Portal is one domain core behind one Portal facade, surfaced
through several adapters. The web chapter F6 and the Telegram-bot chapter F10
are parallel surfaces over that one facade, each a roadmap of its own, shipping on independent cadences. Switch
the planning level on the right to see what each level sequences.
Two levels of planning · pick one
Order the chapters, not the rungs
A backlog rolls up into a chapter roadmap; a set of chapter roadmaps rolls up into a program
roadmap. The unit changes with the altitude. At the program level the planning unit is the
chapter, and the artifact is portal.roadmap.md: it sequences whole
chapters — F4 store, F5 engine, F6 web, F10 bot, F7–F9 multi-runtime — into four program
milestones. At the chapter level the planning unit is the rung, and the artifact is
phoenix.roadmap.md: it sequences nine rungs f6.1…f6.9
into three milestones.
The Portal is one domain core behind one Portal facade, surfaced through several
adapters. The web (F6) and the bot (F10) are parallel surfaces over that one facade — neither depends on
the other for its core loop, so they are sequenced by product priority, not a hard dependency, and they ship on
independent cadences. The master invariant threads through every chapter: every surface calls only the facade
and renders only the closed error set, so adding a surface adds a roadmap of its own and never changes the core.
A program of many surfaces stays plannable when each surface's roadmap is independent of the others — sequenced by product priority, not by a hard dependency on a sibling.
“Call only the facade” — the master invariant. The web (F6) and bot (F10) each call only
the Portal facade, so each carries a roadmap of its own and ships on its own cadence.
The program roadmap orders chapters; the master invariant is the seam that keeps each surface's roadmap its own.
The three dives
Each dive takes one face of the program view, in the arc roadmap of roadmaps → one core, many surfaces → independent cadence: first the levels of planning, then the one-core-many-surfaces shape, then why each surface ships on its own schedule. Read them in order — A3.6.1 starts.
Roadmap of roadmaps
The program roadmap sequences whole chapters into program milestones, not rungs. The three levels of planning — program, chapter, rung — each with its own unit and artifact.
One core, many surfaces
One domain core behind one Portal facade, surfaced through several
adapters. The web (F6) and bot (F10) as parallel surfaces; the master invariant is what makes them
independent.
Independent cadence
Each surface ships on its own cadence, sequenced by product priority not a hard dependency. Shared core, separate delivery — reorder one surface and the other is untouched.
A3.6 sits above the chapter-level modules: A3.3 · Anatomy of a roadmap.md read one chapter roadmap part by part; here the program roadmap orders the chapters that own those roadmaps. Return to the A3 chapter navigation to continue.
References
The program-planning tradition this layer draws on, and where it connects in the course.
Sources
- Humble & Farley — Continuous Delivery — sequencing independent deliveries, each releasable on its own schedule.
- Beck, K. — Extreme Programming Explained — the planning game across releases, ordered by value and priority.
- Hunt & Thomas — The Pragmatic Programmer — orthogonality: a decoupling seam that lets one part change without disturbing another.
Related in this course
- A3.6.1 · Roadmap of roadmaps
- A3.6.2 · One core, many surfaces
- A3.6.3 · Independent cadence
- A3.3 · Anatomy of a roadmap.md — one chapter roadmap, read part by part.
- A1.04 · Two layers — the roadmap over the spec.
- A3 · The roadmap layer — the chapter navigation.
- F6 · The Portal on the web (Phoenix) — the web surface this program sequences.
- Companion · Functional Programming in Elixir