How to track architecture work next to the model
Put the work that concerns an architecture on a board next to it: cards that link to the diagram, page or entity they are about, with the exports and documents each piece of work produced collected against the card.
When this is useful
- A review produced eleven follow-up actions and they are currently a bullet list in somebody’s notes.
- A decision was made, a diagram was changed, and nothing connects the two.
- You are asked what happened to an action from the last review and the honest answer is that you would have to go and look in three places.
Before you start
- The diagrams the work concerns. A card is most useful when it can point at the thing it is about, which means the thing has to exist.
- A realistic scope. This tracks the work that benefits from sitting next to the model — it is not a replacement for a project tracker, and using it as one makes it worse at the thing it is good at.
Step 1: Create a workboard
Create a workboard from the home screen. It opens as a board of columns, which is deliberately familiar — the value here is not the board mechanics but what a card can point at.
Step 2: Add a card and link it to the model
Create a card for the piece of work, then link it to the diagram, page or model element it concerns. The link is the whole point: from the card you reach the architecture, and from the architecture you can see what work is outstanding against it.
Write the card as the thing to be decided or changed, not as a category. "Decide whether orders and fulfilment share a database" is a card; "database work" is a label.
Step 3: Let artefacts collect against the card
Exports, generated scripts and attached documents collect against the card that produced them. This is how a piece of work ends with a record instead of with somebody’s memory of having done it.
Diagram ▸ DocumentsDiagram ▸ Export Center
Step 4: Close the loop with review
Because the approval workflow, version history and audit log run over the same model, a card, the change it caused and the review that accepted it are all part of one trail. Put the resulting change through approval and the card has an outcome that can be pointed at.
Diagram ▸ Approval workflowDiagram ▸ Version history
What happens next
The next review starts from evidence rather than recollection: here is what was raised, here is what changed, here is the version that was approved.
Cards that have been open for months are their own finding. An architecture backlog that never moves usually means the work is not really owned.
Example
A design review that produced eleven actions. Each became a card linked to the page it concerned; four generated migration scripts that landed against their cards; the resulting diagram version went through approval. At the follow-up review the question "what happened to action seven" took one click instead of one email thread.
Tips
- Link every card to something. An unlinked card is a to-do item that could have lived anywhere, and it will drift back to wherever your to-do items normally live.
- Keep the board to architecture work. Delivery tickets belong in the delivery tracker; mixing them buries the four cards that actually concern the model.
- Close cards with the artefact, not with a comment. "Done" is not a record; the generated script is.
Limitations
- This is not a project tracker and does not try to be. There is no sprint, velocity or delivery reporting.
- Versioning, comments and the document centre are separately enabled, so parts of the trail described here depend on what your organisation has turned on.