Bewertungsmatrix für Projekte
Diese Matrix dient nicht der Perfektion, sondern der transparenten Einordnung.
Ziel ist es, sichtbar zu machen:
- Wo stehen wir heute?
- Welche Abweichungen sind bewusst akzeptiert?
- Welche Lücken erzeugen echte Risiken?
Bewertung ist keine Kritik – sie ist eine Entscheidungsgrundlage.
Vorgehen
- Ist-Level bestimmen (0–5 je Dimension)
- Ziel-Level festlegen (basierend auf Risiko × Lebensdauer × Kritikalität)
- Abweichungen analysieren
- Konkrete nächste Schritte definieren
Wichtig:
Ein Projekt hat kein „Gesamtlabel“.
Es hat ein Profil.
Bewertungsmatrix
| Dimension | Ist-Level (0–5) | Ziel-Level | Abweichung | Nachweis / Evidenz | Risiken bei Abweichung | Nächster Schritt |
|---|---|---|---|---|---|---|
| Tests & Qualitätssicherung | ||||||
| CI/CD & Release Engineering | ||||||
| Codequalität & Standards | ||||||
| Architektur & Modularität | ||||||
| Security & Privacy | ||||||
| Observability & Betrieb | ||||||
| Dokumentation & Nachweisbarkeit | ||||||
| Data & Resilience | ||||||
| Team & Prozesse |
Hinweis:
Die Spalte „Abweichung“ = Ziel-Level – Ist-Level.
Nicht jede Abweichung ist kritisch. Relevant ist die Risikowirkung.
Bewertungsleitfragen (pro Dimension)
Die Fragen dienen als Orientierung – nicht als Checkliste zum Abhaken.
Tests & Qualitätssicherung
- Sind kritische Geschäftsflüsse automatisiert getestet?
- Sind Tests reproduzierbar und wartbar?
- Gibt es bekannte „untestable areas“?
CI/CD & Release Engineering
- Existieren echte Gates (nicht nur „Build grün“)?
- Ist ein Rollback innerhalb definierter Zeit möglich?
- Sind Releases nachvollziehbar versioniert?
Codequalität & Standards
- Sind Reviews substanziell oder formal?
- Gibt es klare Regeln für kritische Komponenten?
- Werden Linting/Static Analysis aktiv genutzt?
Architektur & Modularität
- Sind Verantwortlichkeiten klar?
- Sind Abhängigkeiten bewusst oder historisch gewachsen?
- Werden Architekturentscheidungen dokumentiert (ADRs)?
Security & Privacy
- Sind Daten klassifiziert?
- Existiert ein Threat Model (mindestens light)?
- Gibt es automatisierte Security-Checks in der Pipeline?
Observability & Betrieb
- Können Fehler schnell lokalisiert werden?
- Existieren SLOs oder zumindest implizite Erwartungen?
- Gibt es Alerts für geschäftskritische Ausfälle?
Dokumentation & Nachweisbarkeit
- Sind wesentliche Entscheidungen nachvollziehbar?
- Ist Traceability (Ticket → PR → Release) möglich?
- Gibt es Runbooks für Kernprozesse?
Data & Resilience
- Sind Backups vorhanden und getestet?
- Sind RTO/RPO definiert?
- Gibt es einen dokumentierten Restore-Prozess?
Team & Prozesse
- Gibt es klare Ownership?
- Existiert ein definierter Incident-Prozess?
- Werden Lessons Learned strukturiert umgesetzt?
Ergebnis interpretieren
1. Profil statt Durchschnitt
Ein arithmetischer Mittelwert ist irrelevant.
Entscheidend ist das Profil der Dimensionen.
Beispiel:
- Overall ≈ Level 2
- Security = 1
- Data & Resilience = 0
→ Das Risiko liegt nicht im Durchschnitt, sondern in der Schwachstelle.
2. Risiko vor Ideal
Nicht jede Lücke muss geschlossen werden.
Aber jede Lücke sollte bewusst akzeptiert sein.
Unbewusste Lücken sind gefährlicher als niedrige Level.
3. Gates als Risikoreduktion
Wenn ein möglicher Incident hohe Kosten hätte,
braucht diese Dimension ein Gate.
Beispiel:
- Wiederholte Produktionsfehler → Test-Gate verschärfen
- Unklare Releases → Traceability-Gate einführen
- Datenrisiko → Security-Gate ergänzen
Kurzbeispiel
| Dimension | Ist | Ziel | Abweichung | Risiko | Nächster Schritt |
|---|---|---|---|---|---|
| Tests & QS | 1 | 2 | +1 | Fehler in Kernflow | 3 automatisierte Tests |
| CI/CD | 2 | 2 | 0 | – | Kein Handlungsbedarf |
| Security | 1 | 3 | +2 | Unklare Datenrisiken | Datenklassifizierung + SAST |
Anwendung im Portfolio
Bei mehreren Systemen kann die Matrix genutzt werden für:
- Vergleich von Projekten
- Priorisierung von Verbesserungen
- Budgetargumentation
- Vorbereitung auf Audits
Die Matrix ersetzt keine Detailanalyse –
sie schafft Transparenz über Reife und Risiko.