Ein Modell aktuell halten
Modelle verrotten nicht, weil Leute faul sind. Sie verrotten, weil im tatsächlichen Arbeitsfluss nichts jemanden zwingt, sie zu öffnen.
6 Min. LesezeitModelling practice3 von 3
01Why models rot
The usual explanation is discipline, and it is wrong. The same engineers who let a model drift for two years keep their test suite green every day, and the difference is not how much they care - it is that a failing test stops the pipeline and a wrong diagram does not stop anything.
Code is surrounded by machinery that forces attention onto it at the moment it changes: a compiler, a test run, a reviewer who has to approve. A model in a wiki has none of that. Nothing in the path from ticket to production ever requires anybody to open the page, so nothing ever surfaces the disagreement. The model does not get worse - the system moves, and the model stays exactly where it was.
02Attach it to something that already happens
Every arrangement that works has the same shape: the model is placed where an existing step will run into it.
Put the view in the repository. A diagram committed as Mermaid beside the code appears in the diff when its file is touched and gets read by whoever reviews the change. It is the only mechanism on this list that costs nothing to sustain, because the review was already happening.
Reference views from decision records. A short architecture decision record that links the view showing the structure it decided means the view gets opened every time somebody asks why the structure is that way - which is precisely when its being wrong would matter.
Make the model the source of a thing people need. If the deployment view generates the diagram in the runbook, or the domain model generates the glossary the support team searches, then somebody notices within days rather than quarters.
Reach for it when
- A view lives in the repository and changes in the same pull request as the code
- A decision record links the view that shows what it decided
- The model generates something a team already relies on
- One named person owns each view, and the list of views is short enough to name owners for
Reach for something else when
- A quarterly review nobody has scheduled
- A wiki page that only the author has ever opened
- An exported PNG sitting beside the source it was generated from
- Any arrangement that requires somebody to remember
03Shrink it, and delete the rest
The other half of the answer is that most models are too big to keep, and no process fixes that. If maintaining the model would take a day a month and the team has an hour, the model will go stale regardless of how the review is arranged - so the honest move is to cut it down to the hour.
That is the same test as scoping, applied later: whichever views cannot name a decision are the ones to drop, and dropping them is not a loss because they were not being read. What remains is small enough that its being wrong is noticed.
Then actually delete the rest. This is the step people will not take, and it is the one with the clearest arithmetic. A missing diagram costs a reader ten minutes of asking somebody; a confidently wrong diagram costs them a day and, if they are unlucky, a decision made on it. Documentation you will not maintain is not neutral, it is a trap with your team's logo on it.
In one line each
- 01Models rot because nothing in the delivery flow obliges anybody to open them.
- 02Attach each view to a step that already happens: a diff, a decision record, a generated artefact.
- 03Any process that depends on somebody remembering has already failed.
- 04Cut the model to the maintenance budget the team actually has, not the one it should have.
- 05Delete what is left, and date what you keep. A wrong diagram costs more than a missing one.
04Häufige Fragen
Warum veraltet Architekturdokumentation?
Weil im Lieferprozess nichts jemanden zwingt, sie zu öffnen. Code hat Tests und Review, die bei einer Änderung Aufmerksamkeit erzwingen; ein Modell im Wiki hat nichts Vergleichbares, driftet also lautlos - und es fällt niemandem auf, bis jemand ihm vertraut und sich irrt.
Wie hält man ein Modell aktuell?
Hängen Sie es an einen Schritt, der ohnehin stattfindet. Ein Diagramm im Repository erscheint im Diff eines Pull Requests; eine Sicht, auf die ein Entscheidungsprotokoll verweist, wird geöffnet, wenn die Entscheidung neu aufgerollt wird. Alles, was auf einem Review beruht, das niemand terminiert hat, übersteht das erste volle Quartal nicht.
Löschen oder stehen lassen, wenn ein Diagramm veraltet ist?
Löschen. Ein fehlendes Diagramm kostet einen Leser zehn Minuten Nachfragen; ein selbstbewusst falsches kostet ihn einen Tag und eine schlechte Entscheidung. Was Sie nicht pflegen werden, ist eine Verbindlichkeit und kein Vermögenswert, und es zu entfernen ist die billigste verfügbare Verbesserung.
Passend dazu