Die DORA-Studie gilt als umfassendste empirische Untersuchung zur Leistungsfähigkeit von Software-Teams. Ihre vier zentralen Metriken – Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Restore – haben die Art und Weise, wie Unternehmen Softwareentwicklung bewerten, nachhaltig geprägt. Doch während diese Kennzahlen in cloud-nativen Unternehmen mit flexiblen Release-Prozessen funktionieren, stoßen sie in regulierten Branchen an klare Grenzen. Warum? Weil sie die spezifischen Herausforderungen dieser Umgebungen nicht abbilden.
Banken, Krankenhäuser, Energieversorger oder staatliche Institutionen unterliegen strengen regulatorischen Vorgaben. Hier entscheiden nicht nur technische, sondern auch rechtliche und prozessuale Faktoren über den Erfolg von SRE-Programmen. Ein Team, das die DORA-Metriken perfekt erfüllt, kann dennoch scheitern – weil es die operative Nachhaltigkeit seiner Infrastruktur vernachlässigt. Genau hier setzt die Idee einer fünften Metrik an: einer Kennzahl, die die Lücken der DORA-Metriken schließt und regulierten Unternehmen eine realistischere Einschätzung ihrer SRE-Reife ermöglicht.
Warum die DORA-Metriken allein nicht ausreichen
Die vier DORA-Kennzahlen liefern wertvolle Einblicke in die Effizienz von Softwarebereitstellungsprozessen. Doch sie messen vor allem die technische Leistung – nicht die Rahmenbedingungen, unter denen regulierte Unternehmen arbeiten. Diese Unterschiede sind nicht auf mangelnde Engineering-Kompetenzen zurückzuführen, sondern auf strukturelle Vorgaben, die außerhalb der Kontrolle der Teams liegen.
Ein zentrales Beispiel ist die Deployment Frequency. In DORA gilt eine tägliche oder sogar mehrfache Bereitstellung pro Tag als Elite-Leistung. Doch in regulierten Unternehmen müssen Änderungen oft über Change Advisory Boards (CABs) abgesegnet werden. Finanzinstitute frieren Änderungen während der Quartalsberichterstattung ein, während Krankenhäuser ihre Systeme vor Zertifizierungsaudits stilllegen. Ein Unternehmen, das innerhalb der erlaubten Fenster jede Woche ein Deployment durchführt, würde nach DORA als „Low Performer“ eingestuft – obwohl es seine Möglichkeiten optimal ausschöpft.
Die eigentliche Frage lautet daher: Wie oft gelingt ein Deployment im Verhältnis zu den verfügbaren Zeitfenstern? Eine Metrik, die diese Relation abbildet, würde eine fairere Bewertung der tatsächlichen SRE-Reife ermöglichen.
Lead Time: Wo regulatorische Prozesse die Pipeline bremsen
Die Lead Time for Changes misst, wie lange es vom Code-Commit bis zur Produktionsbereitstellung dauert. In cloud-nativen Umgebungen wird diese Zeit hauptsächlich durch die CI/CD-Pipeline bestimmt. In regulierten Unternehmen kommt jedoch ein weiterer Faktor hinzu: die Dauer von CAB-Prüfungen, regulatorischen Genehmigungen und Dokumentationspflichten.
Ein Team mit einer zweitägigen CI/CD-Pipeline und einer fünfägigen CAB-Prüfung hat eine Gesamt-Lead Time von sieben Tagen. Eine Optimierung der CI/CD auf einen Tag würde die Gesamtzeit nur um 14 % verkürzen. Eine Halbierung der CAB-Prüfung hingegen brächte eine Reduktion um 36 %. Doch die DORA-Metriken geben keinen Aufschluss darüber, wo das größte Potenzial für Verbesserungen liegt. Sie aggregieren technische und prozessuale Verzögerungen – und verschleiern damit, wo der Hebel für echten Fortschritt angesetzt werden muss.
Change Failure Rate: Wenn Compliance-Fehler teurer sind als technische
Die Change Failure Rate erfasst, wie viele Änderungen nach der Bereitstellung Korrekturen erfordern. Doch in regulierten Umgebungen entsteht ein weiteres Risiko: Compliance-Fehler. Eine Änderung, die technisch einwandfrei funktioniert, aber gegen Datenschutzbestimmungen verstößt, Daten in falschen Regionen speichert oder Meldepflichten auslöst, ist ein schwerwiegender Vorfall. Solche Compliance-Verstöße ziehen oft höhere Kosten nach sich als reine technische Fehler – etwa durch Regulierungsstrafen, Audits oder notwendige Nachbesserungen.
Die DORA-Metriken erfassen diese Compliance-Fehler nicht. Für regulierte Unternehmen ist es daher entscheidend, eine zusätzliche Kennzahl einzuführen, die sowohl technische als auch regulatorische Misserfolge abbildet. Nur so lässt sich das volle Risiko einer Änderung realistisch einschätzen.
Mean Time to Restore: Wenn die schnellste Lösung nicht immer die richtige ist
Die Mean Time to Restore (MTTR) misst, wie lange es dauert, bis ein Service nach einem Ausfall wiederhergestellt ist. Doch in regulierten Unternehmen endet die Arbeit nach der Wiederherstellung oft erst: Finanzinstitute müssen Ausfälle innerhalb von zwei Stunden bei der Aufsichtsbehörde melden, während Krankenhäuser innerhalb von zehn Tagen eine detaillierte Ursachenanalyse vorlegen müssen. Zudem ist die schnellste technische Lösung nicht immer die zulässige. Ein Rollback einer Datenbankänderung mag in Minuten erfolgen, könnte aber gleichzeitig Compliance-Lücken hinterlassen.
Die DORA-Metriken spiegeln damit nicht die tatsächliche operative Belastung wider. Sie zeigen zwar, wie schnell ein Team einen Service wiederherstellt – aber nicht, ob diese Lösung nachhaltig ist oder zusätzliche Compliance-Risiken birgt.
Die fünfte Metrik: Operative Nachhaltigkeit als Schlüssel zum Erfolg
Die DORA-Metriken sind notwendig, aber nicht hinreichend für den Erfolg von SRE-Programmen in regulierten Umgebungen. Um die operative Nachhaltigkeit zu bewerten, braucht es eine zusätzliche Kennzahl: den Operational Sustainability Index (OSI). Diese Metrik setzt die technischen Leistungsdaten in Relation zu den regulatorischen und prozessualen Rahmenbedingungen.
Der OSI könnte beispielsweise folgende Faktoren berücksichtigen:
- Compliance Overhead: Anteil der Zeit, die Teams mit regulatorischen Pflichten verbringen, im Verhältnis zur reinen Engineering-Arbeit.
- Change Window Utilization: Wie effizient werden die verfügbaren Deployment-Fenster genutzt?
- Incident Remediation Compliance: Wie viele Ausfälle führen zu Compliance-Verstößen oder Meldepflichten?
- Team Burnout Rate: Wie hoch ist die Fluktuation oder Krankheitsquote im Team aufgrund operativer Überlastung?
Ein hoher OSI-Wert würde anzeigen, dass ein SRE-Programm nicht nur technisch leistungsfähig ist, sondern auch unter den gegebenen Rahmenbedingungen nachhaltig betrieben werden kann. Ein niedriger Wert hingegen wäre ein frühes Warnsignal für drohende Programmstagnation.
Fazit: Messbarkeit anpassen, Nachhaltigkeit sichern
Die Einführung einer fünften Metrik wie dem Operational Sustainability Index ist kein Angriff auf die DORA-Studie. Vielmehr ist sie eine notwendige Ergänzung, um die Realität regulierter Unternehmen abzubilden. Nur wer die technischen und regulatorischen Herausforderungen gleichermaßen berücksichtigt, kann SRE-Programme langfristig erfolgreich gestalten.
Regulierte Unternehmen stehen vor einer doppelten Herausforderung: Sie müssen sowohl die Effizienz ihrer Softwarebereitstellung steigern als auch die Compliance-Anforderungen erfüllen. Eine erweiterte Metrikpalette ermöglicht es ihnen, ihre Fortschritte objektiv zu messen – und rechtzeitig gegensteuern, bevor operative Überlastung zum Stillstand führt.
KI-Zusammenfassung
DORA’nın dört temel metriği yazılım dağıtım performansını ölçmede etkili olsa da, bankalar ve sağlık sistemleri gibi sıkı düzenlemelere tabi sektörlerde yeterli değildir. Operasyonel sürdürülebilirliği ölçmek için beşinci bir metrik öneriyoruz.
