Kurz gesagt
Drift zeigt sich oft in veralteten Diagrammen, Services ohne Owner, doppelter Logik, versteckten manuellen Schritten oder Integrationen, die nur eine Person versteht.
Das Risiko ist nicht architektonische Unvollkommenheit. Das Risiko sind Entscheidungen auf Basis einer Karte, die das Gelände nicht mehr beschreibt.
Wo es wehtut
Architektur-Drift tut weh bei Incidents, Due Diligence, Migrationen oder Feature-Planung. Schätzungen werden unzuverlässig, weil das Team das echte System erst während der Arbeit entdeckt.
Was zu prüfen ist
- Passt das aktuelle Architekturdiagramm zu Production-Traffic, Datenflüssen und Ownership?
- Welche Integrationen oder Services existieren nur wegen eines dringenden Workarounds?
- Was würde eine neue Entwicklerin nach Lesen der Dokumentation falsch verstehen?
Häufige Fragen
Was ist Architektur-Drift?
Architektur-Drift ist die Lücke zwischen beabsichtigtem Systemdesign und der Art, wie das Production-System nach vielen kleinen Änderungen wirklich funktioniert.
Was verursacht Architektur-Drift?
Typische Ursachen sind Hotfixes, undokumentierte Integrationen, neue Vendors, Teamwechsel, fehlende Ownership und Architekturentscheidungen, die nie neu geprüft wurden.
Was sollten Sie bei Architektur-Drift zuerst prüfen?
Vergleichen Sie Diagramme, Code, Infrastruktur, Datenflüsse und Ownership mit Production. Die Abweichung zeigt meist das Risiko.