1. Docs
2. Concepts

Roadmap

Decisions and how far the estate has realised them, with the planned changes, conditions, end-of-support deadlines and expiring exceptions around them — laid into Now, Next, Later and Done by fixed rules, built from the records and never drawn.

#Why a Roadmap Built from Records

Hand-drawn architecture roadmaps go stale as soon as they are published, and they show intent, not progress. In Archigov the roadmap is derived, not authored, like the derived model: every item on it is a record Archigov already holds, so it moves when the records move. Because a decision with a checkable constraint can be measured against the estate, the roadmap can say how far a decision has been realised, not only that someone means to carry it out.

It also brings together the strands a head of architecture reports on:

• what was decided;
• what the delivery teams are doing about it;
• what the board made a condition;
• what the vendors' lifecycles force.

#What an Item Is

Every item is one of five kinds, and each comes from a record:

Every item sits in one of four lanes: Now, Next, Later or Done.

#Decision Realisation

Realisation applies to accepted decisions with a checkable constraint: the resource types the decision allows. In the decision's scope — its applications, or every application when it lists none — the roadmap counts two things:

• conforming resources: resources of an allowed type;
• drift: the open drift findings the decision raised (see Conformance).

Other decisions:

• An accepted decision with no constraint is not checkable. Its realisation is evidenced through reviews, not measured, so it is never shown as progressing and never estimated. It sits in Next, or in Now when a linked change is Active.
• A proposed decision sits in Next. Its realisation starts once it is accepted.

A decision that lists no applications applies to every application, and its card says so.

#Planned Changes

A planned change linked to a decision is nested under it: the decision's card lists each change with its id, title and state. A change that is not linked to a decision is placed by its state:

An unlinked epic, project, initiative or change that is still open and has no review says No architecture decision yet.

#Lanes by Date

Conditions, end-of-support deadlines and exceptions are placed by their date:

Done holds realised decisions, and conditions met and changes closed in the last 90 days. Within a lane, items are in date order, earliest first; items with no date follow.

#The Roadmap Page

Governance → Roadmap brings it together:

• Counts per lane in the hero band, for the chosen application.
• Filters: Application keeps that application's items and the decisions that apply to every application; Kind shows one kind of item, with the number of each. Each lane's heading counts what the filters leave.
• Four lanes, each naming its rule: four columns on a wide screen, two on a laptop and one on a phone.
• Cards, one per item, showing:
  • the kind, and a status tag (colour, icon and word) that explains itself on hover;
  • the title, linked to its record: the decision, the review a condition belongs to, Planned Changes, the Legacy Register, or the application an exception covers;
  • the code;
  • the due or ended date;
  • a progress bar labelled Realisation, for a measurable decision, with how many resources conform;
  • the applications;
  • the planned changes nested under a decision;
  • a one-line detail.

#How the Roadmap Moves

Nothing on the roadmap is edited there. An item changes lane, status or progress only when a record behind it changes:

• accepting a decision starts measuring its realisation;
• remediating drift resolves the findings at the next evaluation, so realisation rises, and a decision with no drift left moves to Done;
• closing a change moves it to Done for 90 days, or updates its state on its decision's card;
• meeting a condition moves it to Done for 90 days;
• upgrading a component takes its end-of-support item off once collection sees a supported version;
• an exception expiring takes its item off, and the finding it covered comes back.

#Who Can Do What

The roadmap is read-only. Everyone who can read the model can read it — authors, board seats, auditors, service accounts and the platform admin — and nobody can change it there.

#Evidence and Audit

The roadmap is computed when it is read. Nothing is written, so nothing is audited: the changes behind it are in the audit chain where they happen — the decision accepted, the condition met, the finding resolved. The roadmap is also available from the HTTP API. A board pack records the counts per lane and the Now lane as they stood when it was signed.

#Heuristics and AI

No AI. Every item, status and lane comes from fixed rules:

• Realisation counts resources of an allowed type and the open drift findings the decision raised.
• Lanes come from the status, the state of a change, or the date and today.
• A decision without a checkable constraint is not checkable, never a guess.

#What It Deliberately Does Not Do

• It does not accept hand-drawn items or target dates. A plan that is not a record is not on the roadmap.
• It does not estimate. A decision without a checkable constraint is not checkable, not 50 %.
• It does not reorder or prioritise items beyond their lane and date.

Note

Realisation counts the resources of an allowed type and the open findings against a decision. It shows how far the estate has moved and on what evidence; it never asserts that the estate complies with the decision or with anything else.

Something unclear or out of date? Write to hello@archigov.com or open an issue on GitHub.