Wie viel von einem System man modelliert

Bevor Sie irgendeine Sicht zeichnen, vervollständigen Sie diesen Satz: „Diese Sicht existiert, damit [Person] entscheiden kann [Sache].“ Wenn Sie nicht beide Lücken füllen können, zeichnen Sie sie nicht.

Der Test funktioniert, weil er widerlegbar ist, und genau das ist jeder andere Ratschlag zu diesem Thema nicht. „Modellieren Sie die wichtigen Teile“ kann keine Diskussion verlieren; „dieses Klassendiagramm existiert, damit das Plattformteam entscheiden kann, ob die Steuerberechnung zur Abrechnung gehört“ ist entweder wahr oder nicht, und man kann die genannte Person fragen.

Ehrlich angewendet entfernt er das meiste von dem, was modelliert wird. Ein Diagramm des aktuellen Systems, gezeichnet weil es jemand dokumentieren sollte, informiert über nichts. Eine Sicht, die jeden Dienst im Bestand zeigt, informiert über nichts, weil keine Entscheidung sie alle zugleich betrifft. Was übrig bleibt, ist eine kleine Zahl von Sichten, jede auf eine Auseinandersetzung gerichtet, die jemand gerade führt.

Es wird zur zweiten Implementierung. Jede Klasse, jedes Feld, jeder Aufruf - ein Modell in dieser Detailtiefe ist eine Kopie der Codebasis in einer Notation, und die Kopie ist immer die, die falsch ist. Das ist das Scheitern, das der Modellierung ihren Ruf eingebracht hat, und es kommt vollständig daher, dass niemand gefragt hat, wofür das Modell da ist.

Es wird zum Bild des Organigramms. Unzugeschnittene Modelle driften dahin, das System jedes Teams gleich stark zu zeigen, weil das politisch die einfachste Anordnung ist. Das Ergebnis ist ein Diagramm, in dem die zwei Komponenten, die tatsächlich miteinander sprechen, genauso gross sind wie zwanzig, die es nicht tun, und niemand findet darin die Frage.

Es wird auf ganz gewöhnliche Weise unpflegbar. Nicht dramatisch - einfach dadurch, dass es mehr Details enthält, als das Team zu aktualisieren bereit ist: ein paar Elemente veralten, dann ein paar mehr, und binnen zweier Quartale ist das Modell etwas, das man gegen den Code prüft, statt ihm zu trauen.

Ein Modell, mehrere kleine Sichten. Der Zuschnitt ist eine Eigenschaft der Sicht, nicht des Modells - das Modell darf alles enthalten, was jemand eingetragen hat, und jede Sicht zeigt die Handvoll Elemente, die eine Entscheidung braucht. Genau dafür ist der Sichten-Mechanismus von ArchiMate da, und er gilt für UML genauso.

Modellieren Sie eine Ebene unter der Entscheidung, nicht zwei. Geht der Streit darum, welcher Dienst eine Zuständigkeit besitzt, modellieren Sie die Dienste und ihre Abhängigkeiten. Modellieren Sie nicht die Klassen darin; dieses Detail kann die Antwort nicht ändern, und es ist genau das Detail, das verrottet.

Löschen Sie Sichten, die ihren Zweck erfüllt haben. Eine Sicht, die für eine erfolgte Migration gezeichnet wurde, ist fertig, und sie zu behalten heisst, dass eine spätere Leserin ein selbstbewusstes Diagramm einer Architektur findet, die es nicht mehr gibt. Dokumentation zu löschen fühlt sich falsch an und ist meist richtig.

Als Nächstes in dieser Reihe: Namenskonventionen, und dann ein Modell aktuell halten.