Qualitätsstufen – Übersicht
Architektur beschreibt wie ein System strukturiert ist (Patterns, Modularität, Prinzipien).
Qualität beschreibt wie zuverlässig, sicher und beherrschbar diese Architektur umgesetzt wird.
Ein gutes Pattern auf Level 1 bleibt riskant.
Eine einfache Architektur auf Level 4 kann sehr robust sein.
Architektur und Qualität sind orthogonal – beide müssen bewusst entschieden werden.
Worum geht es hier?
Die Qualitätsstufen helfen, Engineering-Aufwand, Risiko und Nutzen bewusst zu balancieren.
Statt Qualität moralisch oder implizit zu behandeln, machen wir sie explizit entscheidbar:
Qualitätslevel = Risiko × Lebensdauer × Kritikalität
Basierend auf bewährten Modellen (CMMI, DORA, SAMM), aber pragmatisch formuliert für Teams, die eine konkrete Antwort brauchen auf:
„Welche Stufe sind wir – und welche sollten wir sein?“
Wenn du wenig Zeit hast
- Kontext klären: Risiko, Lebensdauer, Kritikalität
- Ziel-Level wählen: 0–5
- Gates prüfen: Welche Mindestkriterien gelten?
- Entscheidung dokumentieren
Qualität ist keine implizite Hoffnung – sie ist eine bewusste Wahl.
Ziele
- Gemeinsame Sprache für Qualität
- Transparente Trade-offs
- Passende Qualität je nach Kontext (Zeitdruck, Risiko, Lebensdauer)
- Klare Mindest-Gates pro Stufe (keine „Fluffy“-Bewertungen)
Überblick der 6 Qualitätsstufen
| Level | Leitmotiv | Typische Situation |
|---|---|---|
| 0 | Experiment | Demo, Prototyp, Throwaway |
| 1 | Speed | Kurzlebige Features, niedrige Risiken |
| 2 | Teamfähig | Nachhaltiges Standardprodukt |
| 3 | Produktionsreif | Mehrere Teams, regelmäßige Releases |
| 4 | Kritisch | Compliance, hohe Risiken, Governance |
| 5 | Reguliert | Audit-ready, Medizin, Finance, Safety |
Ein höheres Level ist kein Selbstzweck.
Ein zu hohes Level kann genauso ineffizient sein wie ein zu niedriges.
Ziel ist nicht „maximale Qualität“, sondern passende Qualität.
Kernidee: Level + Dimensionen + Gates
Statt „one-size-fits-all“ definieren wir:
- 6 Qualitätsstufen (0–5) mit klaren Zielen
- 8–10 Dimensionen, auf denen jedes System bewertet wird
(z. B. „Level 2 overall, aber Security Level 4“) - Minimale Gatekriterien pro Level (damit Qualität messbar bleibt)
Qualität wird damit:
- vergleichbar
- diskutierbar
- steuerbar
Die 6 Qualitätsstufen (0–5)
Level 0 — "Hero Mode / Throwaway"
Ziel: Demo, Prototyp, Ideenvalidierung
Charakteristiken:
- Keine Tests, kaum Standards
- "Works on my machine"
- Kaum Monitoring, keine SLAs
- Risiko akzeptiert, Lebensdauer sehr kurz
Exit-Kriterium: Wenn's live/produktiv gehen soll → mindestens Level 1.
Level 1 — "Delivery First"
Ziel: Schnell zum Kunden, überschaubare Lebensdauer (Wochen–Monate)
Charakteristiken:
- Minimaler Build (CI optional), manuelle Checks
- "Best effort"-Codequalität, rudimentäre Architektur
- Wenig/keine Unit Tests
- QA primär manuell
- Security nur Basics (keine Secrets im Repo, minimale Hardening)
Guardrail: Nur für low risk & kurzlebig einsetzen.
Level 2 — "Team-Standard"
Ziel: Nachhaltig lieferbar – Standard für "normale Produkte"
Charakteristiken:
- CI Pflicht, Build + Lint + Unit Tests
- Code Reviews Pflicht (mind. 1 Approver)
- Definierte "Definition of Done"
- Testpyramide beginnt (Unit-Tests stark, 1–2 E2E-Smoke-Tests)
- Observability basic (Logs, Error Tracking)
- Modularität: klare Struktur, klare Ownership
- Security: SAST/Dependency Scan im Pipeline-Gate
- Doku: Basics (API, Setup, Standard-ADRs)
Gate-Beispiel:
- ✓ CI läuft bei jedem Merge
- ✓ Code Review Pflicht
- ✓ Unit Test Coverage auf kritischen Modulen oder Diff-Coverage
- ✓ Linting/Formatting enforced
- ✓ Basis-Monitoring/Logging vorhanden
Level 3 — "Produktionsreife"
Ziel: Stabiler Betrieb, viele Releases, mehrere Teams möglich
Charakteristiken:
- Automatisierte Tests breit (Unit, Integration, E2E für kritische Flows)
- Feature Flags / Rollback-Strategien
- SLOs, Monitoring, Alerting, Incident-Prozess definiert
- Security-Checks erweitert: SAST, Dependency Scan, Threat Model light
- Architektur: DDD/SCS, klare APIs, ADRs, Tech-Radar
- Observability: strukturierte Logs, Tracing, Fehler-Analyse
- Doku: Entscheidungen dokumentiert (C4-Modell, ADRs, Betriebsdoku)
Gate-Beispiel:
- ✓ Automatisierte Tests für kritische Flows
- ✓ SLOs / Monitoring vorhanden
- ✓ Incident-Prozess dokumentiert und trainiert
- ✓ Tech-Radar / Architektur-Entscheidungen sichtbar
Level 4 — "High Assurance"
Ziel: Hohe Risiken / Compliance / kritische Systeme
Charakteristiken:
- Traceability: Requirements → Tests → Releases → Code
- Change-Management, auditable Pipelines, getrennte Environments (staging, prod, etc.)
- Security by Design (STRIDE o. ä.), regelmäßige Pen-Tests
- Strikte QA-Gates, regelmäßige Reviews, Architektur-Governance
- Doku: systematisch (C4, ADRs, Betriebsdoku, Runbooks)
- Runbooks für Kernprozesse, Incident Drills mind. quartalsweise
Gate-Beispiel:
- ✓ Threat Model vorhanden & aktualisiert bei Major Changes
- ✓ SBOM/Dependency Scans im Pipeline-Gate
- ✓ Traceability: Ticket → PR → Build → Release → Tests
- ✓ Runbooks für Kernprozesse existieren
- ✓ Incident Drills mind. quartalsweise durchgeführt
Level 5 — "Reguliert / Audit-ready"
Ziel: Medizin, Finance, Safety – prüfbar, wiederholbar, nachweisbar
Charakteristiken:
- Validierte Prozesse, formal nachweisbare Qualität
- Vollständige Traceability & Evidence (Audit-Trails)
- Strenge Zugriffskontrollen, Segregation of Duties
- Verifizierte Releases, signierte Artefakte
- Regelmäßige externe Audits, Compliance-Management
- Versioning & Change-Control auf allen Ebenen
Rollen je Qualitätsstufe
Die Rollen sind als Orientierung gedacht. In der Praxis können Personen mehrere Rollen abdecken.
Dimensionen zur Bewertung
Bewerte jedes System entlang dieser 8–10 Dimensionen, jeweils von Level 0–5:
- Tests & Qualitätssicherung (Unit, Integration, E2E, Testpyramide)
- CI/CD & Release Engineering (Automatisierung, Pipelines, Deployment)
- Codequalität & Standards (Linting, Code Reviews, Guidelines)
- Architektur & Modularität (DDD/SCS, Schnittstellen, ADRs)
- Security & Privacy (SAST, Secrets, Threat Modeling, GDPR)
- Observability & Betrieb (Logs, Metrics, Tracing, SLOs)
- Dokumentation & Nachweisbarkeit (C4, ADRs, Runbooks, Audit-Trails)
- Data & Resilience (Backups, Migrationen, DR, Chaos Engineering)
- Team & Prozesse (DoR/DoD, Incident Management, Ownership, Governance)
Ergebnis: Ein "Radar" oder "Profil": z. B. "Wir sind Level 2 overall, aber Ops nur Level 1, Security Level 3".
Die entscheidende Regel: Qualität ist eine Business-Entscheidung
Qualitätslevel = Risiko × Lebensdauer × Kritikalität
| Szenario | Empfohlenes Level |
|---|---|
| Demo, Prototyp, Proof-of-Concept | Level 0–1 |
| Niedriges Risiko + kurzlebig (Wochen/Monate) | Level 1–2 |
| Normales Produkt, längerfristig (> 1 Jahr) | Level 2–3 |
| Langlebiges Produkt + viele Releases/Teams | Level 3–4 |
| Kritische Daten / Compliance / Safety-kritisch | Level 4–5 |
| Externe Audits / Regulierung (Medizin, Finance) | Level 5 |
Wichtig: Dies verhindert das toxische Muster:
"Wir wollen Level 5 Qualität, aber mit Level 1 Budget & Timeline."
Wenn "niemand cares": Risiken, Kosten, Wahrscheinlichkeit
In der Praxis funktioniert vieles lange mit niedriger Qualitätsstufe. Das heißt nicht, dass kein Risiko da ist – sondern dass es selten oder verborgen ist. Typische Kosten entstehen nicht jeden Tag, sondern bei bestimmten Ereignissen. Diese Ereignisse sind nicht sicher, aber wahrscheinlich.
Beispiele (vereinfachte Heuristik):
- Datenverlust (Wahrscheinlichkeit: mittel, Kosten: hoch): Fehlende Backups oder ungetestete Restores.
- Ausfall im Betrieb (Wahrscheinlichkeit: mittel, Kosten: mittel–hoch): Fehlende Gates lassen Fehler live gehen.
- Schleichende Qualitätsschulden (Wahrscheinlichkeit: hoch, Kosten: mittel): Kleine Fehler summieren sich zu langen Durchlaufzeiten.
- Vertrauensverlust (Wahrscheinlichkeit: niedrig–mittel, Kosten: hoch): Ein Vorfall kann Jahre an Reputation kosten.
- Regulatorischer Druck (Wahrscheinlichkeit: niedrig–mittel, Kosten: sehr hoch): Plötzliches Audit oder Kundenforderung.
Die Frage ist selten „ob es knallt“, sondern „wann“ – und ob man bis dahin bewusst Risiken akzeptiert.
Warum Gates nicht optional sind
Gates sind kein Formalismus. Sie sind ein gezielter Kontrollpunkt, um bekannte Fehlerklassen zu stoppen, bevor sie teuer werden. Ohne Gate wird der Prozess zur Hoffnung.
Gute Gates sind:
- klar (welches Risiko wird reduziert?)
- pragmatisch (wenig Overhead, klare Definition)
- wirksam (messen Outcome, nicht nur Aktivität)
Beispiel: Ein reines „Coverage‑%“ kann trügerisch sein. 80% Abdeckung kann trotzdem kritische Pfade ungetestet lassen. Deshalb gilt: Coverage ist nur ein Indikator, kein Ziel.
Empfohlen:
- Unit Tests müssen Sinn ergeben, nicht nur Zahlen erfüllen.
- Kritische Pfade brauchen konkrete Tests, die nachvollziehbar sind.
- Gates prüfen Qualität, nicht den Prozess an sich (z. B. „Testfall existiert und ist reproduzierbar“).
Praxis-Regeln, die auch bei niedriger Stufe helfen
- Wenn ein Incident wirklich weh tut → Gate hinzufügen.
- Wenn mehrere Teams arbeiten → Reviews + CI als echte Entscheidungspunkte nutzen.
- Wenn niemand die Tests ernst nimmt → Gates auf kritische Flows statt Coverage legen.
Anwendung
- Kontext klären: Ziel, Risiken, Lebensdauer, Kosten, kritische Anforderungen
- Level wählen: Basierend auf obiger Regel (Risiko × Lebensdauer × Kritikalität)
- Kriterien explizit dokumentieren: Welche Dimensionen? Welche Gates sind Pflicht?
- Profile ggf. differenzieren: z. B. "Level 2 overall, aber Security Level 3" (höhere oder niedrigere Standards pro Dimension erlaubt)
- Regelmäßig überprüfen: Ändert sich Kontext, Level ändern? Macht Gates Sinn noch?
Detailübersicht
- ISO/IEC 25010 Mapping – Zuordnung der ISO-Qualitätsmerkmale auf die Stufen
- Level 0: Hero Mode – Experimente, kleine interne Tools, Throwaway-Code
- Level 1: Delivery First
- Level 2: Team-Standard
- Level 3: Produktionsreife
- Level 4: High Assurance
- Level 5: Reguliert / Audit-ready