Die Abhängigkeitskante, die Sie belügt

Fragen Sie ein Plattform-Team nach seinem Architekturdiagramm, und Sie bekommen eines von zwei Dingen: eine Confluence-Seite mit dem Stempel „zuletzt bearbeitet vor 14 Monaten" oder ein Schulterzucken und einen Slack-Thread, in dem drei Leute darüber streiten, ob der Payments-Service Inventory immer noch direkt aufruft oder in der Q3-Migration, die niemand fertig dokumentiert hat, über den Event-Bus lief. Beide Antworten sind richtig, in dem Sinne, dass beide das sind, was in den meisten Teams ab einer gewissen Größe tatsächlich passiert.

Das Diagramm ist nicht falsch, weil jemand faul war. Es ist falsch, weil ein Diagramm eine Behauptung über das System in dem Moment ist, in dem es jemand gezeichnet hat, und das System weiter ausgeliefert wurde. Jede Abhängigkeit, die Sie nicht entfernt haben, jeder neue Aufruf, den jemand unter Deadline-Druck hinzugefügt hat und später aufräumen wollte, jeder Fallback-Pfad, der nur in Produktion feuert — nichts davon taucht in einem Kästchen-und-Pfeile-Diagramm auf, es sei denn, jemand geht zurück und zeichnet es neu. Niemand zeichnet es neu. Diese Lücke zwischen dem System, wie es dokumentiert ist, und dem System, wie es läuft, ist das, was wir mit architektonischem Drift meinen, und es ist keine Hypothese: Es ist der Standardzustand jedes Systems, das alt genug ist, um von mehr als einem Ingenieur angefasst worden zu sein.

Zwei Quellen der Wahrheit, und keine reicht allein

Statische Analyse liest, was Sie geschrieben haben: den Quellcode parsen, die Imports auflösen, den HTTP-Clients und Kafka-Listenern folgen, und man erhält einen Graphen dessen, was der Code angibt, was was aufrufen sollte. Das ist präzise und billig zu berechnen, aber es kennt nur Pfade, die im Quellcode existieren — ein Feature-Flag, das seit acht Monaten bei 100 % steht und dessen alter Zweig nie gelöscht wurde, sieht für eine rein statische Lesung immer noch „benutzt" aus, und ein Aufruf, der nur über Reflection oder eine dynamisch gebaute URL erfolgt, taucht möglicherweise gar nicht auf.

Runtime-Beobachtung ist das genaue Gegenteil. Beobachten Sie tatsächlichen Traffic — welcher Port mit welchem Container gesprochen hat, wie oft, wie schnell — und Sie erhalten genau das, was gerade passiert, ohne Interpretation nötig. Aber Laufzeitdaten haben keine Erinnerung an Absicht. Sie können nicht sagen, ob ein Aufruf so gedacht war oder ein Überbleibsel ist, das niemand entfernen will, und wenn die Traffic-Stichprobe einen nächtlichen Batch-Job verpasst, der einmal am Tag läuft, ist diese Abhängigkeit für sie unsichtbar.

Keine der beiden lügt, genau genommen. Beide sagen die Wahrheit über eine jeweils andere Frage.

Was das Kennzeichnen jeder Kante wirklich bringt

Der nützliche Schritt ist nicht, eine Quelle der anderen vorzuziehen — es ist, beide zu behalten und sich zu weigern, sie zu einem einzigen unmarkierten Fakt zu verschmelzen. Jede Abhängigkeitskante im Graphen von Archynt trägt, woher sie stammt: static (im Quellcode gefunden, nie live beobachtet), runtime (im Traffic beobachtet, nirgendwo notiert), oder both. Dieser dritte Zustand, confirmed_by: both, ist der einzige, auf den Sie mit echter Zuversicht handeln können — er bedeutet, dass Code und Leitung übereinstimmen.

In den anderen beiden liegen die interessanten Befunde. Eine static-only-Kante ohne Laufzeit-Traffic seit Wochen ist ein Kandidat für toten Code — eine Abhängigkeit, die Sie wahrscheinlich löschen können, und jetzt haben Sie einen Beleg statt einer Vermutung. Eine runtime-only-Kante ist das Gegenteil und, unserer Erfahrung nach, die dringendere: eine lebende Abhängigkeit, die niemand notiert hat, was bedeutet, dass niemand sie besitzt, niemand darauf alarmiert, und die nächste Person, die den aufrufenden Service anfasst, keine Ahnung hat, dass er tragend ist, bis sie ihn kaputt macht.

Warum das ein Risikogespräch ist, kein Dokumentationsgespräch

Es ist verlockend, Drift unter „Doku aktuell halten" abzulegen, und genau deshalb beheben die meisten Teams es nie — Dokumentationsschulden verlieren jedes Priorisierungsmeeting gegen alles mit Ticket und Deadline. Die ehrlichere Einordnung ist, dass eine unbeaufsichtigte Laufzeitabhängigkeit gleichzeitig unüberwachte Angriffsfläche und ein ungeplanter Single Point of Failure ist. Niemand ist für eine Verbindung im Bereitschaftsdienst, von deren Existenz er nicht weiß. Das ist die Argumentation, mit der wir heute vorangehen, weil sie die einzige ist, die den Kontakt mit einer Roadmap-Review übersteht.