Warum das in Ihrer Woche auftaucht
Architektur-Drift ist leise. Jede einzelne Änderung kann sinnvoll sein, aber das System passt langsam nicht mehr zum Modell im Kopf des Teams.
Klartext
Drift zeigt sich oft in veralteten Diagrammen, Services ohne Owner, doppelter Logik, versteckten manuellen Schritten oder Integrationen, die nur eine Person versteht.
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.