Ein Modell aktuell halten

Die übliche Erklärung ist Disziplin, und sie ist falsch. Dieselben Entwickler, die ein Modell zwei Jahre lang treiben lassen, halten ihre Testsuite jeden Tag grün, und der Unterschied liegt nicht daran, wie wichtig es ihnen ist - sondern daran, dass ein fehlgeschlagener Test die Pipeline anhält und ein falsches Diagramm gar nichts anhält.

Code ist von Maschinerie umgeben, die im Moment der Änderung Aufmerksamkeit auf ihn zwingt: ein Compiler, ein Testlauf, ein Reviewer, der zustimmen muss. Ein Modell im Wiki hat davon nichts. Nichts auf dem Weg vom Ticket zur Produktion verlangt von irgendwem, die Seite zu öffnen, also bringt nichts den Widerspruch je zum Vorschein. Das Modell wird nicht schlechter - das System bewegt sich, und das Modell bleibt genau dort, wo es war.

Jede Anordnung, die funktioniert, hat dieselbe Form: Das Modell liegt dort, wo ein bestehender Schritt darauf stösst.

Legen Sie die Sicht ins Repository. Ein als Mermaid neben dem Code eingecheckter Diagramm taucht im Diff auf, sobald seine Datei angefasst wird, und wird von dem gelesen, der die Änderung reviewt. Es ist der einzige Mechanismus auf dieser Liste, dessen Erhalt nichts kostet, weil das Review ohnehin stattfand.

Verweisen Sie aus Entscheidungsprotokollen auf Sichten. Ein kurzer Architecture Decision Record, der auf die Sicht mit der beschlossenen Struktur verlinkt, sorgt dafür, dass die Sicht jedes Mal geöffnet wird, wenn jemand fragt, warum die Struktur so ist - und genau dann würde es zählen, wenn sie falsch wäre.

Machen Sie das Modell zur Quelle von etwas, das gebraucht wird. Wenn die Deployment-Sicht das Diagramm im Runbook erzeugt oder das Domänenmodell das Glossar, in dem der Support sucht, dann fällt es jemandem binnen Tagen auf statt binnen Quartalen.

Die andere Hälfte der Antwort ist, dass die meisten Modelle zu gross sind, um gepflegt zu werden, und kein Prozess behebt das. Wenn die Pflege des Modells einen Tag im Monat kosten würde und das Team eine Stunde hat, veraltet das Modell unabhängig davon, wie das Review organisiert ist - der ehrliche Schritt ist also, es auf diese Stunde zurückzuschneiden.

Das ist derselbe Test wie beim Zuschnitt, nur später angewandt: Welche Sichten keine Entscheidung benennen können, sind die, die wegfallen, und ihr Wegfall ist kein Verlust, weil sie ohnehin nicht gelesen wurden. Was bleibt, ist klein genug, dass auffällt, wenn es falsch ist.

Und dann löschen Sie den Rest wirklich. Das ist der Schritt, den die Leute nicht gehen, und der mit der klarsten Rechnung. Ein fehlendes Diagramm kostet eine Leserin zehn Minuten Nachfragen; ein selbstbewusst falsches kostet sie einen Tag und, mit Pech, eine darauf gebaute Entscheidung. Dokumentation, die Sie nicht pflegen werden, ist nicht neutral, sie ist eine Falle mit dem Logo Ihres Teams darauf.