12.4
12.4 Reife-Selbsteinschätzung
Jedes Kapitel in diesem Handbuch endet mit einem “Reifegradmodell”, das beschreibt, wie sich eine Praxis typischerweise entwickelt. Dieser Anhang konsolidiert das Reifegradmodell jedes Kapitels in eine einzelne Referenz, damit Sie ein Team, eine Domäne, oder eine ganze Organisation auf einen Blick bewerten können.
Die geteilte Fünf-Stufen-Skala
Alle Kapitel beschreiben denselben Fortschritt. Der exakte Wortlaut variiert leicht zwischen Kapiteln, aber die Absicht bildet sich sauber auf diese fünf Stufen ab:
- Stufe 1, Initiieren. Ad hoc, reaktiv, und personenabhängig. Praktiken existieren nur, wo ein Individuum sie wählt, also hängen Ergebnisse von Heldentaten und Glück ab.
- Stufe 2, Entwickeln. Grundlegende Praktiken existieren, sind aber inkonsistent zwischen Teams, teilweise manuell, und werden oft unter Druck umgangen.
- Stufe 3, Standardisieren. Praktiken sind dokumentiert, standardisiert, und organisationsweit durchgesetzt. Dies ist der Audit- und Compliance-Boden: die Stufe, die die meiste Unternehmens- und Behördenarbeit erreichen muss, um verlässlich und überprüfbar zu sein.
- Stufe 4, Verwalten. Praktiken werden mit Daten und Metriken gegen Baselines gemessen und kontrolliert. Sie wissen quantitativ, wie jede Praxis performt, und handeln nach den Zahlen.
- Stufe 5, Orchestrieren. Praktiken werden kontinuierlich verbessert, über die Organisation integriert, und adaptiv. Der sichere oder korrekte Pfad ist der Standard, und die Organisation lernt und entwickelt sich absichtlich.
Wie sie für Selbsteinschätzung zu nutzen ist
- Lesen Sie für jedes für Ihren Kontext relevante Kapitel die fünf Zellen unten und wählen Sie die Stufe, die ehrlich Ihr typisches Verhalten beschreibt, nicht Ihr bestes Team an seinem besten Tag, und nicht Ihre geschriebene Richtlinie, sondern was tatsächlich passiert.
- Bewerten Sie jedes Kapitel von 1 bis 5. Runden Sie im Zweifel ab; eine Praxis, die inkonsistent ist, ist Stufe 2, nicht Stufe 3.
- Mitteln Sie Werte innerhalb eines Teils, um zu sehen, wo eine ganze Domäne steht, dann betrachten Sie die Streuung: ein Teil bei “durchschnittlich 3”, der ein Stufe-1-Kapitel versteckt, trägt trotzdem ein Stufe-1-Risiko.
- Bewerten Sie periodisch neu und verfolgen Sie den Trend. Bewegung ist wichtiger als jede einzelne Momentaufnahme.
Reife ist ein Mittel, kein Zweck
Höhere Reife ist nicht automatisch besser. Das Ziel ist Passung: genug Rigor, um das Risiko und die Skalierung zu verwalten, denen Sie tatsächlich begegnen, und nicht mehr. Ein kleines, wenig folgenreiches Werkzeug braucht keine Stufe-5-Chaos-Engineering. Nach einer hohen Stufe als Trophäe zu streben, statt ein echtes Problem zu lösen, produziert Zeremonie ohne Wert. Lesen Sie jede “Stufe 5” unten als “angemessen, wenn die Einsätze es rechtfertigen”, und lassen Sie Risiko, Skalierung, und regulatorische Exposition entscheiden, wie weit zu klettern ist.
Teil 1. Menschen
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Engineering-Kultur und Werte | Kultur ist zufällig und personenabhängig; Vorfälle bedeuten Schuld; Wissen lebt in wenigen Köpfen. | Manche Teams führen Postmortems durch und schreiben Dokumente, aber die Praxis ist inkonsistent und von der Führung unbestärkt. | Schuldfreies Lernen, Besitzmodelle, und eine Schreibkultur sind organisationsweite Normen mit klaren Erwartungen und Werkzeug. | Kulturgesundheit wird gemessen (Umfragen zu psychologischer Sicherheit, Vorfall-Lernraten, Bindung) und gegen Baselines verfolgt und danach gehandelt. | Kultur wird kontinuierlich verbessert und Praktiken verbreiten sich zwischen Teams; Führung passt Normen an, während die Organisation wächst und lernt. |
| Teamtopologien | Teams bilden sich zufällig oder nach Kopfzahl; Struktur spiegelt Legacy-Hierarchie; überall Abhängigkeiten. | Manche stream-ausgerichteten Teams existieren, aber geteilte Engstellen und funktionale Silos bestehen fort. | Die vier Teamtypen und explizite Interaktionsmodi werden absichtlich genutzt; Plattformen und InnerSource kürzen Abhängigkeiten. | Kognitive Last, Fluss, und Abhängigkeitszahlen werden pro Team gegen Ziele gemessen; Grenzen werden angepasst, wenn die Zahlen abrutschen. | Die Organisation formt Teams und Interaktionsmodi kontinuierlich um, um Fluss aufrechtzuerhalten, während sich Produkte und Plattformen entwickeln. |
| Rollen, Karriereleitern, Wachstum | Keine geschriebene Leiter; Beförderungen und Bezahlung sind ad hoc und personenabhängig. | Eine grundlegende Leiter existiert, wird aber inkonsistent angewandt; keine Kalibrierung; Einstellung ist unstrukturiert. | Duale Pfade, eine klare Kompetenzmatrix, Kalibrierung, und strukturierte Einstellung sind Standard. | Fortschrittsraten, Lohngerechtigkeit, und Zeit-in-Stufe werden gegen Baselines gemessen; Kalibrierungsergebnisse werden auf Bias analysiert. | Das Framework entwickelt sich kontinuierlich mit der Arbeit; Sponsoring und Ausbildung sind absichtlich und organisationsweit, während sich Rollen ändern. |
| Arbeitsweisen | Prozess ist ad hoc oder Cargo-Kult; Kommunikation ist meeting-getrieben und undokumentiert; Schätzungen werden als Versprechen behandelt. | Eine Methodik wird konsistent befolgt, aber Zeremonien sind routiniert und teamübergreifende Koordination ist schwer. | Praktiken werden zum Kontext passend gewählt; asynchrone, dokumentenerste Kommunikation ist die Norm; Schätzung informiert, kontrolliert nicht. | Flussmetriken (Durchlaufzeit, Work in Progress, Durchsatz) werden gegen Baselines verfolgt und jeden Zyklus überprüft. | Teams tunen ihre Arbeitsweise kontinuierlich aus diesen Metriken; Koordinationsbedarf wird an der Quelle minimiert und gute Praxis verbreitet sich organisationsweit. |
| Entscheidungsfindung und Governance | Entscheidungen sind ad hoc und unaufgezeichnet; Governance fehlt oder ist eine pauschale Engstelle; Schulden sind unsichtbar. | Manche Entscheidungen sind dokumentiert und manche Überprüfung existiert, aber der Prozess ist inkonsistent und dem Entscheidungsgewicht nicht angemessen. | ADRs, ein Golden Path, umkehrbarkeitsbasierte Delegation, und ein Schuldeninventar sind Standard und transparent. | Entscheidungszykluszeit, Umkehrraten, und Schuldenniveaus werden gemessen; Prüfung wird nach diesen Zahlen kalibriert nach Entscheidungsgewicht. | Governance wird organisationsweit kontinuierlich getunt; Prüfung zielt auf irreversible Entscheidungen; Schulden und Beschaffung werden als sich entwickelnde Portfolios verwaltet. |
Teil 2. Software-Programmierung
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Codierstandards und Stil | Stil ist pro Autorin; keine geteilten Konfigurationen; Formatierung wird in Überprüfung gestritten. | Jedes Team hat einen Formatierer und Linter, aber Konfigurationen und Regeln variieren zwischen Teams. | Zentrale geteilte Konfigurationen pro Sprache; CI-Durchsetzung; neue Repositories erben Standards via Vorlagen. | Standardübernahme, Verletzungsraten, und Überprüfungszeit-Auswirkung werden gegen Baselines gemessen; Konfigurationen sind versioniert und verwaltet. | Standards werden aus diesen Daten kontinuierlich verfeinert und organisationsweit geteilt; Durchsetzung ist nahezu reibungslos und passt sich neuen Sprachen an. |
| Softwaredesign-Prinzipien | Design ist ad hoc; Kopplung häuft sich an; Prinzipien sind unbekannt oder werden als Slogans zitiert. | Teams kennen die Prinzipien und wenden sie an, aber inkonsistent und oft dogmatisch. | Geteiltes Design-Vokabular, absichtliche Kopplungs-/Kohäsionsanalyse, und Bounded Contexts an Teams ausgerichtet. | Kopplungs-, Kohäsions-, und Änderungsfehlschlags-Metriken informieren Designüberprüfungen gegen Baselines; Entscheidungen werden erfasst. | Designentscheidungen werden überdacht, während Belege sich anhäufen; Prinzipien werden mit Nuance angewandt und Paradigmawahlen passen sich organisationsweit an, während sich die Domäne entwickelt. |
| APIs und Schnittstellendesign | APIs entstehen aus Implementierung; keine geteilten Konventionen; Breaking Changes sind häufig und unangekündigt. | Teams folgen grundlegenden REST-Konventionen und versionieren informell, aber Konsistenz und Dokumentation variieren. | Vertragserstes Design, maschinenlesbare Spezifikationen, eine Deprecation-Richtlinie, und konsistente Fehler-/Pagination-Konventionen. | Übernahme, Latenz, Fehlerraten, und Breaking-Change-Häufigkeit werden pro API gegen Ziele gemessen. | APIs sind verwaltete Produkte in einem Katalog mit starker DevEx; die Praxis passt sich kontinuierlich an und Breaks sind selten und organisationsweit gut verwaltet. |
| Teststrategie | Testen ist manuell und ad hoc; automatisierte Abdeckung ist minimal; Regressionen sind häufig. | Automatisierte Unit- und manche Integrationstests existieren, aber die Suite ist langsam oder flaky und Vertrauen ist niedrig. | Eine ausgewogene, schnelle, verlässliche Suite torhütet jede Änderung; Flakiness wird verwaltet; nicht-funktionales Testen ist integriert. | Abdeckungs-, Flakiness-, entkommene-Defekt-, und Suite-Dauer-Metriken werden gegen Baselines verfolgt, um Aufwand zu zielen. | Fortgeschrittene Techniken (Property, Mutation, Fuzz) zielen auf hochwertigen Code; die Strategie verbessert sich kontinuierlich und verbreitet sich über Teams. |
| Codeüberprüfung und Zusammenarbeit | Überprüfung ist inkonsistent oder übersprungen; mechanische Probleme dominieren; Rückmeldungsnormen sind ungesetzt. | Überprüfung ist gefordert, aber langsam und variabel; Automatisierung ist teilweise; PR-Größe und Qualität variieren stark. | Kleine PRs, automatisierte mechanische Prüfungen, klare Standards und Rückmeldungsnormen, und überwachte Latenz. | Überprüfungslatenz, PR-Größe, und Defekt-Entkommensraten werden gegen Ziele verfolgt; Tiefe wird an gemessenes Risiko angepasst. | Die Organisation verbessert Überprüfung kontinuierlich aus diesen Daten; Pairing und KI-Assistenz werden absichtlich übernommen und Praktiken verbreiten sich zwischen Teams. |
| Versionskontrolle und Quellverwaltung | Ad-hoc-Branching; langlebige Branches; schlechte Nachrichten; kein Geheimnisscanning; häufiger Merge-Schmerz. | Ein konsistentes Branching-Modell und Nachrichtenkonventionen existieren, aber Branches leben zu lange und Durchsetzung ist teilweise. | Trunk-basierte Entwicklung, geschützte Hauptlinie, durchgesetzte Commit-Konventionen, Geheimnisscanning, absichtliche Repository-Struktur. | Branch-Lebensdauer, Merge-Häufigkeit, und Revert-Raten werden gegen Liefermetriken und Baselines gemessen. | Automatisierung erzwingt Hygiene Ende zu Ende; Repository-Struktur und Workflow entwickeln sich kontinuierlich über die Organisation, während sich Lieferbedürfnisse ändern. |
| Dokumentation | Dokumentation ist spärlich, verstreut, und veraltet; Wissen lebt in den Köpfen der Menschen. | Schlüsseldokumente existieren (READMEs, manche Runbooks), werden aber inkonsistent gepflegt und sind schwer zu finden. | Docs-as-Code mit klarer Struktur, generierte API-Dokumentation und Changelogs, Entscheidungsaufzeichnungen, und Update-Erwartungen. | Dokumentationsabdeckung, Aktualität, und Genauigkeit werden gegen Baselines gemessen; Veraltung wird automatisch markiert. | Dokumentation ist lebendig, größtenteils generiert oder gegen das System getestet, besessen und auffindbar; die Praxis verbessert sich organisationsweit kontinuierlich. |
Teil 3. Systeme
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Architekturgrundlagen | Architektur ist implizit und lebt in Köpfen; keine Qualitätsattribute oder ADRs; Entscheidungen tauchen während Vorfällen auf. | Schlüsseldiagramme existieren und größere Entscheidungen werden manchmal erfasst; Qualitätsattribute benannt aber selten quantifiziert; Dokumentation driftet. | Qualitätsattribut-Szenarien und ASRs sind spezifiziert; ADRs routiniert; C4/arc42-Dokumentation nah am Code gepflegt; Abwägungsüberprüfungen finden statt. | Fitness-Funktionen erzwingen Qualitätsattribute in CI und erfassen gemessene Ergebnisse gegen Baselines; Abwägungen sind quantifiziert. | Architektur entwickelt sich kontinuierlich mit diesen Daten über die Organisation; Dokumentation bleibt vertrauenswürdig genug für Prüferinnen, während sich das System anpasst. |
| Architekturstile und -muster | Ein verstrickter Monolith oder zufälliges verteiltes Durcheinander; Grenzen folgen Schichten oder Geschichte; Stil nach Mode gewählt. | Absichtliche modulare Grenzen oder ein paar grobe Dienste; manche querschnittlichen Anliegen konsistent; Aufteilungen noch ad hoc. | Dienste an Bounded Contexts ausgerichtet, die ihre Daten besitzen; Gateway/BFF wo passend; sauberes/hexagonales Layering Standard. | Stilentscheidungen sind evidenzbasiert, gemessene Kopplungs-, Latenz-, und Änderungskosten-Daten gegen Baselines nutzend. | Eine reife Plattform macht Verteilung günstig; die Organisation konsolidiert erneut, wenn eine Aufteilung sich nicht mehr auszahlt, und passt Stil an, während sich Evidenz ändert. |
| Verteilte Systeme | Entfernte Aufrufe wie lokale behandelt; keine/naive Retries; Fehlschläge kaskadieren; Debugging ist Pro-Maschine-Protokoll-Höhlenforschung. | Timeouts und grundlegende Retries existieren aber inkonsistent; manche Idempotenz; Protokolle zentralisiert aber unkorreliert. | Idempotenz, Backoff, Circuit Breakers, Bulkheads via geteilter Bibliotheken; Sagas; verteiltes Tracing; dokumentierte Konsistenz pro Fluss. | Resilienz wird gegen SLOs gemessen; Fehlerinjektionsergebnisse und Fehlschlagsraten werden gegen Baselines verfolgt. | Resilienz ist der Plattform-Standard, kontinuierlich mit Fehlerinjektion getestet; anmutige Degradation ist eingebaut und entwickelt sich organisationsweit. |
| Datenarchitektur und Speicher | Eine Datenbank für jeden Zweck; keine Migrationsdisziplin; beiläufiges Caching; Skalierung durch größere Maschine. | Speicherwahlen größtenteils absichtlich; ein Cache und vielleicht ein Warehouse; versionierte Migrationen brauchen manchmal Ausfallzeit. | Polyglotte Persistenz zu Workloads passend, jeder Speicher besessen; automatisierte Null-Ausfallzeit-Migrationen; explizites Caching und Replikate. | Speicherwahlen werden gegen Zugriffsmuster-, Latenz-, und Kosten-Baselines gemessen; Sharding- und Caching-Entscheidungen sind datengetrieben. | Datenarchitektur wird organisationsweit kontinuierlich überprüft und entwickelt; Migrationen sind automatisiert und geprüft, während sich Workloads ändern. |
| Skalierbarkeit, Leistung, Resilienz | Einzelinstanz oder vertikal skaliert; serverseitiger Zustand; kein Lasttest oder Budgets; Fehlschläge verursachen komplette Ausfälle. | Horizontal skalierte zustandslose Ebenen; grundlegende Autoskalierung; manche Vorlaunch-Lasttests; DR dokumentiert aber selten getestet. | Kapazität mit Spielraum geplant; Leistungsbudgets in CI; Resilienzmuster Standard; RTO/RPO definiert und DR getestet. | Kapazität wird aus gemessener Last prognostiziert; Leistungsbudgets und RTO/RPO werden gegen Baselines verfolgt. | Multi-Region automatisiertes Failover, kontinuierliches Chaos, und Game Days beweisen und verbessern Erholungsziele, während sich das System organisationsweit entwickelt. |
| Legacy-Modernisierung | Legacy wird gefürchtet und eingefroren; kein Inventar; Modernisierung ist Alles-oder-nichts-Neuschreibung; Wissen in ausscheidenden Köpfen. | Ein Inventar existiert und manches Risiko verstanden; Legacy mit APIs umwickelt; noch Big-Bang-Denken; Migration unterschätzt. | Systeme nach Risiko und Wert priorisiert; Strangler-Fig und Branch-by-Abstraction Standard; Migration mit Dual-Running versöhnt. | Modernisierung wird als Portfolio mit gemessenem Risiko, Wert, und Fortschritt gegen Baselines verwaltet. | Modernisierung ist organisationsweit kontinuierlich; inkrementeller Ersatz ist routiniert, reversibel, und passt sich an, während sich Prioritäten verschieben. |
Teil 4. Sicherheit
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Sicherheitsgrundlagen und -kultur | Sicherheit ist reaktiv und zentralisiert; Überprüfungen spät, wenn überhaupt; keine Bedrohungsmodellierung; Sicherheit ist “jemand anderes Problem”. | Ein Sicherheitsteam definiert Standards; manche Bedrohungsmodellierung bei Großprojekten; grundlegendes Training; Sicherheit als Tor gesehen. | Security Champions eingebettet; Bedrohungsmodellierung routiniert; sicherer SDLC dokumentiert; risikobasierte Priorisierung; schuldfreie Überprüfungen. | Sicherheitsmetriken (Bedrohungsmodellierungsabdeckung, Fund-bis-Fix-Zeit, Kontrollübernahme) werden gegen Baselines verfolgt. | Sicherheit ist wirklich jedermanns Job; Bedrohungsmodellierung ist Gewohnheit; Zero Trust ist größtenteils realisiert und die Praxis verbessert sich organisationsweit kontinuierlich. |
| Anwendungssicherheit | Sicherheit hängt von individuellem Wissen ab; keine Standardkontrollen; Geheimnisse in Code; veraltete Abhängigkeiten; ad hoc Auth. | OWASP-Top-10-Bewusstsein; manche Framework-Schutzmaßnahmen; Secrets Manager ungleichmäßig genutzt; gelegentliches Abhängigkeitsscanning. | ASVS-basierte Anforderungen pro Stufe; parametrisierte Abfragen; zentrale Identität mit MFA; verwaltete Geheimnisse; SBOMs und Pipeline-Scanning. | Schwachstellendichte, mittlere Behebungszeit, und Kontrollabdeckung werden über Dienste gegen Baselines gemessen. | Sichere Standardeinstellungen kommen in Golden-Path-Frameworks; kurzlebige Anmeldedaten und volle Lieferketten-Zusicherung (SLSA) werden organisationsweit kontinuierlich verifiziert. |
| Infrastruktur- und Cloud-Sicherheit | Manuelle Bereitstellung; breite Berechtigungen und statische Schlüssel; flache Netzwerke; inkonsistente Verschlüsselung; kein Posture Management. | Manche IAM-Rollen und MFA; grundlegende Netzwerkebenen; Verschlüsselung im Ruhezustand für Hauptspeicher; periodische manuelle Überprüfungen; teilweise IaC. | Least-Privilege-RBAC/ABAC mit kurzlebigen Anmeldedaten; Default-Deny-Segmentierung; Verschlüsselung standardmäßig mit KMS; CSPM mit Richtlinie. | Posture-, Drift-, und Richtlinienverletzungs-Metriken werden gegen Baselines verfolgt; Guardrail-Effektivität wird gemessen. | Sichere Standardeinstellungen kommen in Landing Zones und IaC; Mikrosegmentierung und präventive Guardrails entwickeln sich kontinuierlich und Drift wird organisationsweit automatisch behoben. |
| Sicherheitsoperationen | Sicherheitstesten manuell und selten; keine zentrale Protokollierung oder SIEM; kein Vorfallplan; ad hoc Patching; nie gegnerisch getestet. | Manche Scanner in der Pipeline; zentrale Protokollierung; ein grundlegender Vorfallplan; lockere Patching-Zeitpläne; jährlicher Pentest. | Vollständiges DevSecOps-Scanning mit risikobasierten Toren; SIEM mit manchem SOAR; geprobte IR mit Tabletop-Übungen; Behebungs-SLAs; Red Teaming. | MTTD und MTTR werden gegen Baselines gemessen; Erkennungsabdeckung wird auf Gegnerintechniken abgebildet und verfolgt. | Testen und Reaktion sind hochgradig automatisiert; Purple Teaming und Erkennungsengineering verbessern sich kontinuierlich und passen sich organisationsweit neuen Bedrohungen an. |
| Datenschutz und Datenschutz | Persönliche Daten frei gesammelt; kein Inventar, Minimierung, oder Aufbewahrung; Einwilligung ein Nachgedanke; kein Rechteprozess. | Eine Datenschutzrichtlinie und grundlegende Einwilligung existieren; manches Aufbewahrungsbewusstsein; Rechteanfragen manuell und langsam gehandhabt. | Privacy by Design mit DPIAs; Daten abgebildet und klassifiziert; Aufbewahrung durchgesetzt; Rechtsgrundlage dokumentiert; Rechte fristgerecht erfüllt. | Datenschutzlage wird gemessen: Dateninventarabdeckung, Aufbewahrungs-Compliance, und Rechteanfrage-Durchlaufzeit gegen Baselines. | Datenschutz ist eine standardmäßige Engineering-Einschränkung; Minimierung und automatisierte Aufbewahrung sind Standard; Rechteanfragen sind Self-Service und die Praxis passt sich organisationsweit an. |
| Compliance und Governance | Compliance ist reaktiv; kein Kontrollframework; Nachweise manuell unter Zeitdruck zusammengestellt; häufige Befunde. | Schlüsselframeworks identifiziert; manche dokumentierte Kontrollen; Audits bestehen mit schwerem manuellen Aufwand; Barrierefreiheit spät bedacht. | Ein einheitliches Kontrollframework kreuzabbildet Standards; Nachweise teilweise automatisiert; Barrierefreiheit getestet; Aufzeichnungen und Autorisierungen etabliert. | Kontrolleffektivität und Nachweisabdeckung werden kontinuierlich gegen Baselines gemessen; Befunde werden getrendet. | Compliance ist kontinuierlich mit always-on Nachweisen und Compliance-as-Code; neue Zertifizierungen sind günstig und das Framework passt sich organisationsweit an, jederzeit audit-bereit. |
Teil 5. UI/UX-Design
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| UX-Grundlagen | Keine dedizierte UX-Praxis; Entscheidungen nach Meinung; Forschung ad hoc; inkonsistente Flüsse und Terminologie. | Manche Designerinnen und gelegentliche Nutzbarkeitstests; Personas ungepflegt; UX ist eine Phase, oft übersprungen. | Kontinuierliche Mixed-Method-Forschung speist Priorisierung; geteilte Personas, Journey Maps, und IA; UX-Qualitätstore in der DoD. | UX-Metriken (Aufgabenerfolg, Zufriedenheit, Nutzbarkeitswerte) werden neben Geschäftsmetriken gegen Baselines verfolgt. | Forschung ist kontinuierlich und ergebnisverbunden; kontrollierte Experimente schließen die Schleife und Erkenntnisse verbreiten sich über Teams, während sich Produkte entwickeln. |
| UI-Design und Designsysteme | Jedes Team baut seine eigene UI; keine geteilten Komponenten; inkonsistenter Look; hartcodierte Farben und Abstände. | Ein teilweiser Styleguide oder eine Komponentenbibliothek existiert, ist aber optional und oft zwischen Design und Code unsynchron. | Ein tokenisiertes Designsystem mit einer gepflegten codierten Bibliothek, Dokumentation, und Governance wird über Teams genutzt; a11y eingebaut. | Design-Code-Parität, Komponentenübernahme, und Drift werden gegen Baselines gemessen; Versionierung wird verfolgt. | Das System ist ein verwaltetes Produkt mit einer Roadmap; es verbessert sich organisationsweit kontinuierlich und Rebrandings werden Token-Änderungen. |
| Barrierefreiheit | Keine Barrierefreiheitspraxis; Probleme durch Beschwerde oder Klage gefunden; nicht-semantische, ungetestete Auszeichnung. | Bewusstsein existiert; manches automatisiertes Scanning und ein Vorlaunch-Audit; a11y ist eine späte Checkliste, oft deprioritisiert. | WCAG 2.2 AA ist der Standard; a11y ins Designsystem eingebaut, getestet, und in der DoD; Teams mit einer Besitzerin geschult. | Barrierefreiheitskonformität wird in CI gegen WCAG-Baselines gemessen; Defektraten und Auditergebnisse werden verfolgt. | Barrierefreiheit ist kontinuierlich; Menschen mit Behinderungen sind in Forschung eingebunden; sie ist in Beschaffung, Tokens, und CI eingebettet und verbessert sich organisationsweit. |
| Inhalt und Kommunikationsdesign | Keine Inhaltspraxis; Wörter ad hoc geschrieben; inkonsistente Terminologie und Ton; unhilfreiche Fehler und leere Zustände. | Ein Styleguide mag existieren; manches Klarsprache-Bewusstsein; Inhalt ist noch spätphasig und pro Team mit wenig Wiederverwendung. | Eine Inhaltsstrategie, Stimme-und-Ton-Leitfaden, und Glossar über Teams genutzt; Klarsprache Standard; geteilte Muster. | Inhalt wird gegen Ergebnisse gemessen (Verständnis, Aufgabenabschluss, Fehlerraten) versus Baselines. | Inhalt wird aus dieser Evidenz kontinuierlich verbessert; Dark Patterns sind verboten und geprüft; Muster sind organisationsweit lokalisiert und standardmäßig barrierefrei. |
| Internationalisierung und Lokalisierung | Einzelne Sprache; hartcodierte Strings; Nicht-Unicode-Annahmen; neue Locales fordern Codeänderungen. | Strings externalisiert und Unicode genutzt, aber Lokalisierung ist ein manueller Vorlaunch-Batch; Formatierung und Pluralformen inkonsistent. | Geteilte i18n-Architektur und locale-bewusste Formatierung; ein TMS und kontinuierliche Pipeline; Pseudo-Lokalisierung und Multi-Locale-CI. | Lokalisierungsabdeckung, String-Aktualität, und Locale-Defektraten werden gegen Baselines gemessen. | i18n wird durch Werkzeug und Lint über Teams durchgesetzt; Lokalisierung ist kontinuierlich, kulturelle Anpassung ist systematisch, und neue Locales starten schnell. |
| Frontend-Engineering | Ad hoc pro-Team-Frontend; schwerer Client-Code; keine Budgets; nur auf Team-Geräten getestet; Framework nach Hype. | Manches geteiltes Werkzeug und eine Komponentenbibliothek; Leistung gelegentlich gemessen, nicht budgetiert; begrenztes geräteübergreifendes Testen. | Framework und Rendering pro Oberfläche absichtlich gewählt; Budgets in CI mit RUM durchgesetzt; progressive Enhancement Standard. | Leistung, Resilienz, und Reichweite werden gegen Echt-Nutzerinnen-Baselines und Budgets gemessen; Regressionen scheitern den Build. | Diese Signale sind an Ergebnisse gebunden und verbessern sich kontinuierlich über Oberflächen, während sich das Frontend und seine Nutzerinnen entwickeln. |
Teil 6. Künstliche Intelligenz
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| KI-Strategie und -Bereitschaft | Ad-hoc-Experimente; keine geteilte Strategie; Entscheidungen von Hype und individueller Begeisterung getrieben. | Problem-Framing bei manchen Projekten; eine erste Plattform-Baseline; Bauen-versus-Kaufen besprochen aber inkonsistent. | Ein Portfolio von Use Cases mit klaren Metriken, einem Entscheidungsbaum, Bereitschaftsbewertungen, und Lock-in-/TCO-Analyse. | Use-Case-Wert, Übernahme, und Bereitschaft werden gegen Baselines gemessen; Portfolio-ROI wird verfolgt. | KI-Strategie ist mit Geschäfts- und Risikoplanung integriert; Bereitschaft wird kontinuierlich gepflegt und Systeme werden organisationsweit nach Evidenz neu umfangbestimmt. |
| MLOps | Modelle ad hoc in Notebooks gebaut; manuelle Bereitstellung; keine Daten-/Modellversionierung; keine Überwachung. | Manches Experiment-Tracking und eine Modellregistry; halbautomatisierte Bereitstellung; grundlegende Überwachung für ein paar Modelle. | Geteilte Plattform mit Feature Store, Registry, reproduzierbaren Pipelines, Herkunft; Drift-/Qualitätsüberwachung; verwaltete Beförderung. | Modellqualität, Drift, und Geschäftsauswirkung werden gegen Baselines gemessen; Retraining wird bei Schwellen mit Toren ausgelöst. | Der Lebenszyklus ist vollständig automatisiert und überprüfbar; Self-Service-Golden-Paths und kontinuierliche Evaluation verbessern Modelle organisationsweit, während sich Daten verschieben. |
| Generative KI und LLM-Anwendungen | Ad-hoc-Prompting in isolierten Projekten; keine Verankerung, Guardrails, oder Eval; Halluzinationen in Produktion gefunden. | Manches RAG und Prompt-Versionierung; grundlegende Ausgabevalidierung; ein kleines manuelles Evaluationsset. | Geteilte Muster für RAG, Guardrails, und Werkzeugnutzung; automatisierte Offline-Eval bei jeder Änderung; Online-Metriken und menschliche Überprüfung. | Offline- und Online-Eval-Werte, Halluzinations- und Injektionsraten werden gegen Baselines gemessen. | Evaluation ist an Ergebnisse gebunden und verbessert sich kontinuierlich; Injektionsabwehr, verwaltete beobachtbare Agenten, und Minderung passen sich organisationsweit an. |
| KI-unterstützte Softwareentwicklung | Individuen nutzen Assistentinnen ad hoc; keine Richtlinie; keine Messung; Geheimnisse und IP gefährdet. | Grundlegende Nutzungsanleitung und Datenregeln; manches Sicherheitsscanning; anekdotische Produktivitätsansprüche. | Klare Normen nach Risikoniveau; verpflichtende Überprüfung und Scanning; ehrliche Ergebnismetriken; sichere Bereitstellung und Offenlegung. | Liefer- und Qualitätsauswirkung der Assistenz werden gegen Baselines gemessen; Verifikationsabdeckung wird verfolgt. | Verifikation ist stark in der Pipeline; Kompetenzentwicklung ist absichtlich und Richtlinie passt sich organisationsweit kontinuierlich an, während sich Werkzeug und Evidenz ändern. |
| Verantwortungsvolle und vertrauenswürdige KI | Kein Fairness-Testen, Erklärungen, oder Governance; Verantwortung undefiniert; Probleme nur nach Schaden gefunden. | Manches Bias-Testen und Dokumentation; ad hoc Aufsicht; Framework-Bewusstsein aber teilweise Übernahme. | Governance auf anerkannte Frameworks abgebildet; systematisches Fairness-/Sicherheits-/Datenschutztesten; dokumentierte Aufsicht und Einspruch; Red Teaming. | Fairness-, Sicherheits-, und Datenschutzmetriken werden in Produktion gegen Baselines und Schwellen überwacht. | Governance ist in Lieferung integriert; Verantwortung ist jedermanns Job und der Ansatz verbessert sich organisationsweit kontinuierlich. |
| KI-Infrastruktur und -Betrieb | Ad-hoc-GPU-Zuweisung; kein Batching oder Caching; keine Kostentransparenz; unversionierte Prompts; minimale Überwachung. | Manches geteiltes Scheduling und Caching; grundlegendes Kosten-Tracking; Prompts in Versionskontrolle; ad hoc Evaluation. | Geteilte Plattform mit Scheduling, Kontingenten, Batching, Caching, Right-Sizing; Vektor-Infra; automatisierte Eval; Kostenzuordnung. | Auslastung, Kosten pro Ergebnis, und Latenz werden gegen Baselines gemessen; Budgets und Kontingente werden durchgesetzt. | Routing und Skalierung sind automatisiert, LLMOps-Beobachtbarkeit ist vollständig, und Auslastung und Kosten werden mit organisationsweit erhaltener Portabilität kontinuierlich optimiert. |
Teil 7. Daten, Analytik, und Einsicht
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Datenstrategie und -Governance | Daten undokumentiert und unbesessen; widersprüchliche Definitionen; Qualität gefunden, wenn Berichte brechen; kein Katalog oder Herkunft. | Manche Datensätze haben Besitzerinnen und Dokumentation; ein teilweiser Katalog; manuelle, reaktive Qualitätsprüfungen; Richtlinie geschrieben aber schwach durchgesetzt. | Kritische Datenprodukte haben Besitzerinnen, Verträge, SLAs; Katalog mit automatisierter Herkunft; kontinuierliche Qualität; föderierte Governance. | Datenqualität, Vertragskonformität, und Aktualität werden gegen SLAs und Baselines gemessen. | Data-as-Product ist die Norm; Verträge werden automatisch durchgesetzt, Self-Service-Guardrails passen sich an, und Definitionen sind unternehmensweit vertraut. |
| Data Engineering | Ad-hoc-Skripte, manuelle Läufe, keine Tests oder Überwachung; Fehlschläge von Konsumentinnen gefunden; Kosten unverwaltet. | Manche Orchestrierung und Scheduling; grundlegende Transformationen in Versionskontrolle; gelegentliche Tests; reaktives Feuerlöschen. | ELT mit geschichteten, getesteten, versionierten Modellen; orchestrierte Abhängigkeiten mit Retries/Backfills; Beobachtbarkeit; Kosten verfolgt. | Pipeline-Verlässlichkeit, Aktualität, und Kosten werden gegen SLAs gemessen; Anomalien werden gegen Baselines erkannt. | Pipelines sind Software mit CI/CD, Verträgen, und Testen; die Plattform verbessert sich kontinuierlich und neue Datenprodukte starten organisationsweit schnell. |
| Analytik und Business Intelligence | Berichte ad hoc in Tabellenkalkulationen gebaut; inkonsistente Metriken; irreführende Charts; keine Governance. | Ein BI-Werkzeug mit manchen geteilten Dashboards; Metrikdefinitionen divergieren noch; unkontrollierter Self-Service und Wucherung beginnt. | Eine semantische Schicht definiert Kernmetriken einmal; zertifizierter vs. experimenteller Inhalt; Self-Service innerhalb von Guardrails; verwalteter Lebenszyklus. | Metriknutzung, Aktualität, und Definitionsänderungen werden gegen Baselines verfolgt; zertifizierter Inhalt wird überwacht. | Metriken werden wie APIs mit Besitzerinnen und Changelogs verwaltet; Analytik spannt von deskriptiv bis präskriptiv und bettet sich an Entscheidungspunkten über die Organisation ein. |
| Produktanalytik und Experimentieren | Wenig/inkonsistente Instrumentierung; Entscheidungen nach Meinung; keine Experimente; Vanity-Metriken; nachlässige Einwilligung. | Manche Ereignisse verfolgt aber Taxonomie inkonsistent; gelegentliche A/B-Tests ohne Power-Analyse; Nordstern vorgeschlagen, nicht eingebettet. | Ein verwalteter, validierter Tracking-Plan; Funnels/Kohorten/Retention routiniert; Experimente auf geteilter Plattform; Einwilligung angemessen gehandhabt. | Experimentvolumen, Power, und Gewinnraten werden gegen Baselines gemessen; Instrumentierungsabdeckung wird verfolgt. | Experimentieren ist Standard; ein geteiltes Ergebnisrepository und besessene Instrumentierung lassen die Organisation kumulativ lernen und sich anpassen. |
| Entscheidungswissenschaft und Datenkultur | Entscheidungen nach Hierarchie und Intuition; Korrelation als Kausalität behandelt; Unsicherheit ignoriert; Metriken überwachen und werden getrickst. | Daten selektiv konsultiert, um Entscheidungen zu rechtfertigen; manches Bewusstsein für kausale Fallen; Unsicherheit selten kommuniziert. | Analysen an Entscheidungen mit vordefinierten Kriterien gebunden; Korrelation vs. Kausalität unterschieden; Unsicherheit kommuniziert; Ergebnisfokus. | Entscheidungsqualität und Prognosekalibrierung werden gegen Ergebnisse und Baselines verfolgt. | “Was würde unsere Meinung ändern?” ist Routine; kausaler Rigor und ehrliche Unsicherheit sind Normen und Führungskräfte aktualisieren organisationsweit sichtbar nach Evidenz. |
Teil 8. Automatisierung
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| CI/CD und Lieferung | Builds und Bereitstellungen größtenteils manuell und inkonsistent; späte Integration; seltene, stressige Veröffentlichungen; manueller Rollback. | Automatisierte Builds und Unit-Tests pro Commit; skriptbasierte aber manuell überwachte Bereitstellungen; Artefakte werden möglicherweise pro Stufe neu gebaut. | Eine standardisierte Pipeline befördert ein unveränderliches Artefakt durch Umgebungen mit automatisierten Toren; Kanarie/Blau-Grün; automatische Änderungsaufzeichnungen. | DORA-Metriken (Durchlaufzeit, Bereitstellungshäufigkeit, Änderungsfehlschlagsrate, MTTR) werden gegen Baselines verfolgt und torhüten Rollbacks. | Progressive Delivery entkoppelt Veröffentlichung via Flags; die Pipeline verbessert sich selbst und Compliance-Nachweise sind organisationsweit automatisch. |
| Infrastructure as Code und Konfiguration | Infrastruktur manuell bereitgestellt; inkonsistente, undokumentierte Umgebungen; langsame, unsichere Wiederherstellung. | Manche Infrastruktur skriptbasiert, aber Praktiken variieren; inkonsistenter Zustand; häufiger Drift; Richtlinie durch manuelle Überprüfung durchgesetzt. | Deklarative IaC Standard aus geteilten versionierten Modulen mit entferntem Zustand; Policy-as-Code-Guardrails; regelmäßige Drift-Erkennung. | Drift, Bereitstellungszeit, und Richtlinienverletzungsraten werden gegen Baselines gemessen; Compliance-Nachweise sind automatisch. | Infrastruktur ist unveränderlich, GitOps-getrieben, und selbstheilend; die Modul- und Richtlinienbibliothek verbessert sich organisationsweit kontinuierlich und passt sich an. |
| Container, Orchestrierung, Cloud-Native | Container ad hoc genutzt; handgebaute ungescannte Images; manuelle Bereitstellung; keine geteilte Plattform oder Isolationsmodell. | Teams containerisieren und nutzen einen Orchestrator, aber Praktiken variieren; inkonsistentes Scanning und Limits; unverwaltete Kosten und Mandantenschaft. | Eine standardisierte Plattform mit gehärteten Images, Signier-/Scanning-Toren, Namespace-Mandantenschaft mit Kontingenten und Netzwerkrichtlinie, Kostenzuordnung. | Auslastung, Dichte, und Kosten pro Workload werden gegen Baselines gemessen; FinOps-Optimierung ist datengetrieben. | Eine Self-Service, selbstheilende Plattform mit starker Multi-Mandantenschaft bleibt portabel und hybrid-/souveränitätsbereit und verbessert sich organisationsweit kontinuierlich. |
| Plattform-Engineering und DevEx | Keine Plattform; jedes Team montiert sein eigenes Werkzeug inkonsistent; ticketgetriebene Übergaben; hohe kognitive Last. | Manche geteilte Werkzeuge und Vorlagen, aber fragmentiert und teilweise manuell; begrenzter Self-Service; DevEx ungemessen. | Ein Plattformteam betreibt Golden Paths, Self-Service-Bereitstellung, ein Entwicklerinnenportal, und Scorecards; Guardrails in Golden Paths; DevEx gemessen. | Übernahme, DevEx-Werte, und kognitive-Last-Signale werden gegen Baselines gemessen und überprüft. | Ein reifes Plattformprodukt verbessert sich aus diesem Feedback kontinuierlich; freiwillige Übernahme ist hoch und Governance bleibt organisationsweit im Workflow unsichtbar. |
| Test- und Prozessautomatisierung | Testen und Betrieb größtenteils manuell; inkonsistente Abdeckung; Prozeduren in Köpfen oder veralteter Dokumentation; Compliance-Nachweise von Hand. | Automatisierte Tests existieren aber langsam/flaky und laufen inkonsistent; manche operative Skripte; manuelle Behebung; periodische-Überprüfung-Governance. | Schnelle, parallele, verlässliche Testinfra; kodifizierte Runbooks; ChatOps; auto-generierte Compliance-Nachweise; Governance als automatisierte Prüfungen. | Automatisierungsabdeckung, Falsch-Positiv-Raten, und Behebungszeiten werden gegen Baselines gemessen. | Routinevorfälle werden mit Sicherungen automatisch behoben; Compliance ist kontinuierlich und audit-bereit und Menschen fokussieren organisationsweit auf Urteilsvermögen. |
Teil 9. Betrieb, Zuverlässigkeit, und Beobachtbarkeit
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Site Reliability Engineering | Betrieb manuell und reaktiv; keine SLOs; Zuverlässigkeit ist Meinung; dieselben Vorfälle wiederholen sich; Feuerlöschen dominiert. | Schlüsseldienste haben grundlegende SLIs/SLOs; manche Überwachung und Alarmierung; Toil anerkannt aber ungemessen; inkonsistente Postmortems. | Fehlerbudgets beeinflussen Priorisierung; Toil gemessen und begrenzt; routinierte Kapazitätsplanung; finanzierte Automatisierung; PRR und Engagement-Modell. | Fehlerbudgets, Toil, und SLO-Erreichung werden gegen Baselines gemessen und treiben Priorisierung. | Fehlerbudget-Richtlinie ist automatisiert und respektiert; Self-Service-Ops und proaktive Kapazität lassen die Organisation Geschwindigkeit und Stabilität nach Daten tauschen und anpassen. |
| Beobachtbarkeit und Überwachung | Grundlegende Betriebszeitprüfungen und unstrukturierte Protokolle pro Maschine; Debugging bedeutet SSH; laute, ignorierte Alarme. | Zentralisierte Metriken und Protokollaggregation; manche Dashboards und Schwellenalarme; teilweise/fehlende Traces; manuelle Korrelation. | OpenTelemetry-Instrumentierung mit propagierten Trace-IDs; strukturierte Protokolle, Tracing, kuratierte Dashboards, SLO-Symptom-Alarmierung; nachhaltiger Bereitschaftsdienst. | Alarmqualität, MTTD, und Telemetriekosten werden gegen Baselines gemessen; Verbrauchsraten-Alarmierung ist auf SLOs getunt. | Hochkardinale, ereignisreiche Beobachtbarkeit unterstützt Ad-hoc-Untersuchung; Aufbewahrung ist kostenoptimiert und Telemetrie informiert Entscheidungen über die Organisation. |
| Vorfallmanagement | Vorfälle ad hoc von wer auch immer bemerkt gehandhabt; keine Rollen, Schweregrade, oder Postmortems; informeller Bereitschaftsdienst; Fehlschläge wiederholen sich. | Grundlegende Bereitschaftsdienstrotationen und Schweregrade; manche Postmortems, aber unklare Rollen und inkonsistent verfolgte Korrekturmaßnahmen. | Ein formelles Incident-Command-System mit klaren Rollen und Kriterien; schuldfreie Postmortems Standard; Aktionen verfolgt; Bereitschaftsdienst vergütet. | Vorfallhäufigkeit, MTTR, und Bereitschaftsdienstlast werden gegen Baselines gemessen; wiederkehrende Ursachen werden getrendet. | Reaktion wird über Game Days geprobt; Bereitschaftsdienst bleibt nachhaltig und ruhig und aggregierte Analyse treibt strukturelle Investition, während die Organisation lernt. |
| Kosten, Nachhaltigkeit, grüne Software | Cloud-Kosten sind eine monatliche Überraschung; kein Tagging, keine Zuordnung, oder Kohlenstoffbewusstsein; großzügige, unüberdachte Bereitstellung. | Grundlegende Kostentransparenz und Tagging; manches reaktives Right-Sizing und Idle-Bereinigung; Nachhaltigkeit anerkannt aber ungemessen. | Eine FinOps-Praxis mit Zuordnung, Budgets, Prognosen, Anomalie-Alarmen, Commitments, Right-Sizing; Kohlenstoff für Hauptdienste gemessen. | Kosten und Kohlenstoff werden pro Team gegen Budgets und Baselines gemessen; Anomalien werden markiert. | Kosten und Kohlenstoff sind kontinuierliche team-besessene Signale; effiziente Standardeinstellungen, automatisierte Optimierung, und kohlenstoffbewusstes Scheduling verbessern sich organisationsweit kontinuierlich. |
Teil 10. Projekt-/Produkt-/Programmmanagement
| Thema | Stufe 1 Initiieren | Stufe 2 Entwickeln | Stufe 3 Standardisieren | Stufe 4 Verwalten | Stufe 5 Orchestrieren |
|---|---|---|---|---|---|
| Portfolio- und Programmmanagement | Prioritäten ad hoc von wer auch immer am lautesten fragt gesetzt; keine Portfolio-Ansicht; Abhängigkeiten tauchen als Krisen auf; jährliches Finanzierungsgerangel. | Ein periodisch überprüftes Portfolio-Inventar; veröffentlichte Ziele schwach mit Arbeit verbunden; ein Abhängigkeitsregister; projektbasierte Budgetierung. | Strategie kaskadiert via OKRs; ein konsistentes Priorisierungsframework; teamübergreifende Planung verwaltet Abhängigkeiten; dauerhafte Teamfinanzierung. | Portfolio-Ergebnisse, Liefervorhersagbarkeit, und Abhängigkeitszahlen werden gegen Baselines gemessen. | Das Portfolio wird kontinuierlich nach Ergebnisevidenz neu ausbalanciert; Abhängigkeiten werden wegdesignt und Finanzierungstakt passt organisationsweit zu Lerntakt. |
| Risiko, Audit, und Zusicherung | Risiko reaktiv nach Vorfällen gehandhabt; kein Framework oder Register; undokumentierte Kontrollen; schmerzhafte manuelle Audits. | Risikoregister für Hauptsysteme; ein Kontrollframework übernommen, Audits bestehen aber manuell und Momentaufnahme; Anbieterinnen bei Onboarding bewertet. | Drei-Linien-Modell und gemeinsames Framework organisationsweit; viele Kontrollen automatisiert; kontinuierliche Überwachung; Anbieterinnen-/SBOM-Inventare; geplante DR. | Kontrolleffektivität, Anzahl offener Risiken, und Auditbefunde werden gegen Risikobereitschaft und Baselines gemessen. | Zusicherung ist kontinuierlich und größtenteils automatisiert; Prüferinnen stichproben Live-Nachweise und Lieferkettenintegrität wird organisationsweit verifiziert, während sich Risiken entwickeln. |
| Beschaffung, Open Source, Lizenzierung | Open Source frei hinzugefügt; keine Richtlinie oder Inventar; Lizenzen unexaminiert; End-of-Life zufällig gefunden; keine Besitzerin. | Eine grundlegende Richtlinie und genehmigte-Lizenz-Liste; manches manuelles/spätes Scanning; ein Inventar für Hauptsysteme; ad hoc Beitrag. | Ein OSPO besitzt Strategie und Werkzeug; automatisiertes Lizenz-/Schwachstellenscanning und Attribution; SBOMs; klarer Beitrag; EOL verfolgt. | Lizenz-Compliance, Abhängigkeitsaktualität, und Schwachstellenexposition werden gegen Baselines gemessen. | Open Source ist ein verwalteter strategischer Vermögenswert mit vollständig automatisierter Compliance; Upstream-Investition ist absichtlich und Aktualität und EOL werden organisationsweit kontinuierlich verwaltet. |
| Große und langlebige Systeme am Laufen halten | Systeme hängen von Heldinnen ab; Besitz durch Erinnerung; undokumentiertes Wissen; Systeme eingefroren bis sie brechen; Stilllegungen enden nie. | Besitz für Hauptsysteme zugewiesen und erfasst; manche Dokumentation und Runbooks; offensichtliche kritische Funktionen haben eine Vertretungsperson; reaktive Wartung. | Team-Ebene-Besitz in einem Katalog, der Umstrukturierungen überlebt; Bus-Faktor gemessen und gemindert; Entscheidungsaufzeichnungen und Runbooks; inkrementelle Modernisierung. | Bus-Faktor, Besitzabdeckung, und Wissenstransfer-Fortschritt werden gegen Baselines gemessen. | Stewardship ist eine finanzierte Disziplin; kein kritisches System ist ein einzelner Punkt menschlichen Fehlschlags und Wissenstransfer und geplante Enden setzen sich organisationsweit fort. |
| Ethik, Rechenschaftspflicht, öffentliches Interesse | Ethik unadressiert oder reaktiv nach Skandal; Barrierefreiheit ignoriert; undurchsichtige automatisierte Entscheidungen ohne Rechtsmittel; Bias ungetestet. | Ein Verhaltenskodex und manche (späte) Barrierefreiheit; hochprofilige automatisierte Entscheidungen bekommen manche Aufsicht; gelegentliche Bias-Prüfungen. | Ethische Überprüfung ist Teil des Prozesses; Barrierefreiheit eingebaut und nutzerinnengetestet; folgenreiche Entscheidungen tragen Erklärung und Rechtsmittel. | Gerechtigkeits-, Barrierefreiheits-, und algorithmische-Rechenschaftspflicht-Ergebnisse werden gegen Baselines überwacht. | Verantwortung ist eingebettet, wie die Organisation baut; Gerechtigkeit ist eine nicht verhandelbare Standardeinstellung und algorithmische Rechenschaftspflicht ist Standard und organisationsweit kontinuierlich verbessert. |
Gesamte Reife-Selbsteinschätzung
Nutzen Sie die obigen Matrizen, um eine leichtgewichtige, ehrliche Bewertung zu produzieren.
Bewertungsrubrik
- Bewerten Sie jedes Kapitel 1 bis 5 anhand der Stufe, deren Beschreibung am besten zu Ihrer typischen Realität passt. Wenn Verhalten inkonsistent ist, bewerten Sie die niedrigere Stufe.
- Mitteln Sie pro Teil. Summieren Sie die Kapitelwerte in einem Teil und teilen Sie durch die Anzahl der Kapitel. Dies gibt eine Reife pro Teil (z. B. “Teil IV mittelt 2,5”).
- Erfassen Sie das Minimum, nicht nur den Mittelwert. Ein Teil, der 3,0 mittelt, aber ein Stufe-1-Kapitel enthält, trägt trotzdem das Risiko dieses Kapitels, unabhängig vom Mittelwert.
- Zeichnen Sie den Trend. Bewerten Sie alle ein oder zwei Quartale neu und beobachten Sie die Bewegungsrichtung. Eine Domäne, die sich 2 → 3 bewegt, ist gesünder als eine, die bei einer statischen 3 feststeckt.
Ein einfaches Arbeitsblatt pro Teil:
| Teil | Bewertete Kapitel | Durchschnitt (Mittelwert) | Niedrigstes Kapitel | Notizen / Priorität |
|---|---|---|---|---|
| I-X | Anzahl | Mittelwert | Mindeststufe | … |
Priorisieren, was zu verbessern ist
Versuchen Sie nicht, alles gleichzeitig anzuheben, und jagen Sie nicht dem höchsten Durchschnitt nach. Priorisieren Sie nach risikogewichteter Reifelücke: greifen Sie die Domänen an, wo eine niedrige Stufe auf hohe Konsequenz trifft.
- Zuerst: die Kapitel niedrigster Reife in Ihren höchstrisikoreichen Domänen. Für die meisten Organisationen bedeutet das Sicherheit, Datenschutz, Zuverlässigkeit, Compliance, und jedes System, dessen Fehlschlag Menschen schadet oder Gesetz verletzt. Eine Stufe 1 hier ist dringend.
- Als nächstes: grundlegende Ermöglicher (Kultur, Arbeitsweisen, CI/CD, IaC, Beobachtbarkeit), die die Decke für jede andere Domäne anheben. Diese zu verbessern macht spätere Gewinne günstiger.
- Später: Domänen, die bereits auf Stufe 3 sind und zu Stufe 4 oder 5 aufsteigen könnten. Nur über den Boden hinausdrängen, wo Einsätze und Skalierung die zusätzliche Investition rechtfertigen.
Die Unternehmens- und Behördenbaseline
Unternehmens- und Behördenkontexte können meist nicht bei “es funktioniert” aufhören. Um Audits zu bestehen, Autorisierungen aufrechtzuerhalten, und regulatorische und öffentliche-Rechenschaftspflicht-Verpflichtungen zu erfüllen, müssen die meisten Domänen mindestens Stufe 3 (Standardisieren) erreichen, die Stufe, wo Praktiken standardisiert, dokumentiert, teamübergreifend durchgesetzt sind, und Nachweise produzieren. Stufe 2 fällt typischerweise durch Audits, weil sie inkonsistent und manuell unter Zeitdruck zusammengestellt ist; Stufe 1 fällt völlig durch.
Lesen Sie Stufe 3 als den Boden für alles Überprüfbare oder Sicherheitsrelevante, und die höheren Stufen (4 und 5) als Ziele nur dort, wo kontinuierliche Zusicherung, Skalierung, oder öffentliches Vertrauen den zusätzlichen Rigor lohnend machen. Reife bleibt ein Mittel: das Ziel ist ein verteidigbares, verhältnismäßiges Kontrollniveau für das Risiko, das Sie tatsächlich tragen, nicht eine perfekte Punktzahl.