Diskussionen über technische Schulden in Engineering-Teams konzentrieren sich fast immer auf Code-Level-Schulden: die unübersichtliche Klasse, die inkonsistente API. Diese sind sichtbar und schätzbar.
Architektur-Level-Schulden sind anders. Sie befinden sich nicht in einer Datei. Sie befinden sich in den Lücken zwischen Dateien — in den impliziten Abhängigkeiten, die sich über drei Jahre Feature-Sprints angesammelt haben.
Drei Formen unsichtbarer Architektur-Schulden
1. Ownership-Drift
Teams reorganisieren sich. Engineers gehen. Services werden neu zugewiesen oder fallen in eine Grauzone. Der Service läuft noch — bis er es nicht mehr tut, woraufhin die Incident-Response mit „Wer besitzt das?“ beginnt.
2. Veraltete Services mit aktiven Abhängigkeiten
Ein Service wird zur Deprecation markiert. Neue Services werden angewiesen, sich nicht auf ihn zu verlassen. Aber bestehende Abhängige werden nicht bereinigt. Ein Jahr später hat der veraltete Service drei aktive Aufrufer und wird in jedem Incident angetippt.
3. Unbekannte Critical-Path-Abhängigkeiten
Die teuerste Form: ein Service, der auf dem kritischen Pfad für Umsatz-Flows liegt, dessen Abhängigkeitsbeziehungen aber nicht kartiert wurden. Wenn er ausfällt, ist der Blast-Radius eine Überraschung.
Das Unsichtbare sichtbar machen
Eine Service-Map mit expliziter Eigentümerschaft und Abhängigkeitsdaten macht alle drei Formen sichtbar: Services ohne Eigentümer, veraltete Services mit aktiven eingehenden Abhängigkeiten und High-Fan-in-Nodes als kritische Pfadkandidaten.
Service Map liest Ihre YAML-Service-Definitionen und rendert einen interaktiven Abhängigkeitsgraphen, in dem Sie über jeden Service hovern können, um seine vollständige Upstream- und Downstream-Kette zu sehen — das Unsichtbare in Sekunden sichtbar gemacht.
