Plattformgesundheit kann nicht nur durch Observability gemessen werden. Der Schlüssel ist die Entwicklererfahrung und die tatsächliche Akzeptanz der Plattform.
Das Problem zeigt sich nicht sofort. Die Plattform kann stabil erscheinen: die Metriken sind grün, (Uptime) hoch, Alarme unter Kontrolle. Aber irgendwann beginnen die Teams, sie zu umgehen. Es entstehen benutzerdefinierte Skripte, manuelle Prozesse und „schattenhafte“ Workflows. Das ist ein klassisches Signal für eine Geisterstadt-Plattform: das System ist technisch gesund, wird aber nicht genutzt. Observability beantwortet die Frage „Was ist kaputt?“, aber nicht „Warum wird es nicht genutzt?“. Hier beginnt die Diskrepanz zwischen Verfügbarkeit und echtem Wert.
Die Lösung liegt in der Änderung des Bewertungsmodells. Plattformgesundheit ist nicht Verfügbarkeit, sondern Nützlichkeit. Das entscheidende Signal ist Akzeptanz, nicht Nutzung. Nutzung kann durch Einschränkungen aufgezwungen werden. Akzeptanz muss verdient werden. Wenn Entwickler den „goldenen Weg“ wählen, bedeutet das, dass er schneller und sicherer ist als die Alternativen. Die Metriken verschieben sich: Einarbeitungszeit, Selbstbedienungsquote, organische Anbindung von Teams. Dabei ist es wichtig, den Trade-off zu berücksichtigen: hohe Akzeptanz garantiert keine Zufriedenheit. Wenn ein Werkzeug „weil man es musste“ verwendet wird, ist das eine versteckte Degeneration.
Die Umsetzung erfordert, dass eine menschliche Schicht in das Messsystem integriert wird. Technische Metriken werden durch Feedback ergänzt. Ein einfaches Werkzeug ist der regelmäßige Entwickler-NPS mit einem offenen Textfeld. Dort werden die Engpässe identifiziert: wiederkehrende manuelle Schritte, nicht offensichtliche Fehler, ineffiziente Szenarien. Ein besonderer Fokus liegt auf Feedback-Schleifen. DORA-Studien zeigen: Ein entscheidender Faktor für die Entwicklererfahrung ist klares Feedback über die Ergebnisse von Handlungen. Nicht die Komplexität der Werkzeuge, sondern die Vorhersehbarkeit des Systems. Wenn die Plattform den Ingenieur bei einem Ausfall in Ungewissheit lässt, ist das ein Problem der Interaktionsarchitektur und nicht nur der Zuverlässigkeit.
Zuverlässigkeit verschwindet dabei nicht, sondern verändert ihre Form. (Uptime) wird zur Basislinie und nicht zum Ziel. Wichtiger ist das Verhalten des Systems bei Ausfällen. Mean Time to Recovery (MTTR) und Change Failure Rate beginnen, die tatsächliche Erfahrung widerzuspiegeln. SLO verschieben sich ebenfalls: nicht „99,9 % Verfügbarkeit“, sondern „99 % der Deployments funktionieren beim ersten Mal“. Das verlagert die Zuverlässigkeit in die Dimension der Entwicklererfahrung. Zusätzlich entsteht ein weiteres starkes Signal – Toil. Manuelle Arbeit, die mit dem Wachstum skaliert, verringert direkt den Durchsatz. Wenn die Plattform gesund ist, absorbiert sie systematisch Toil.
Die Ergebnisse solcher Änderungen werden anders gemessen. Wenn keine Daten vorhanden sind, ist das bereits ein Signal für die Unreife der Plattform. Aber bei vorhandenen Metriken wird das Bild steuerbar. Verringerung der Einarbeitungszeit, Anstieg der Selbstbedienung, Rückgang des Anteils an Toil – das sind Kennzahlen, die mit dem Geschäftseffekt verknüpft werden können. DORA-Metriken wie Lead Time for Changes und Deployment Frequency ergänzen das Bild der Geschwindigkeit. Insgesamt bildet dies eine Sprache für den Dialog mit dem Geschäft, nicht nur einen technischen Status.
Der finale Wandel ist organisatorisch. Die Plattform wird zu einem Produkt. Das bedeutet einen Fahrplan basierend auf Entwickler-Feedback, regelmäßige Gesundheitsberichte und eine klare Verantwortung für die Verbesserung der Entwicklererfahrung. Ohne dies bleibt die Plattform ein Infrastrukturprojekt ohne nachweisbaren Wert. Und unter solchen Bedingungen verlieren Initiativen oft die Finanzierung, weil Observability allein nicht erklärt, „was daraus folgt“.