12.4
12.4 Zelfbeoordeling volwassenheid
Elk hoofdstuk in dit handboek eindigt met een “Volwassenheidsmodel” dat beschrijft hoe een praktijk zich doorgaans ontwikkelt. Deze bijlage consolideert het volwassenheidsmodel van elk hoofdstuk in één naslag zodat je een team, een domein of een hele organisatie in één oogopslag kunt beoordelen.
De gedeelde schaal met vijf niveaus
Alle hoofdstukken beschrijven dezelfde progressie. De exacte bewoording varieert licht tussen hoofdstukken, maar de bedoeling past schoon op deze vijf niveaus:
- Niveau 1, Initiëren. Ad hoc, reactief en persoonsgedreven. Praktijken bestaan alleen waar een individu ze kiest, dus uitkomsten hangen af van heldendaden en geluk.
- Niveau 2, Ontwikkelen. Basispraktijken bestaan, maar ze zijn inconsistent over teams, deels handmatig en worden onder druk vaak omzeild.
- Niveau 3, Standaardiseren. Praktijken zijn gedocumenteerd, gestandaardiseerd en organisatiebreed afgedwongen. Dit is de ondergrens voor audit en compliance: het niveau dat het meeste werk van onderneming en overheid moet bereiken om betrouwbaar en controleerbaar te zijn.
- Niveau 4, Beheersen. Praktijken worden gemeten en beheerst met data en statistieken tegen uitgangswaarden. Je weet kwantitatief hoe elke praktijk presteert en handelt op de getallen.
- Niveau 5, Orkestreren. Praktijken worden continu verbeterd, over de organisatie geïntegreerd en zijn adaptief. Het veilige of juiste pad is de standaard, en de organisatie leert en evolueert bewust.
Hoe je het voor zelfbeoordeling gebruikt
- Lees voor elk hoofdstuk dat voor jouw context relevant is de vijf cellen hieronder en kies het niveau dat je typische gedrag eerlijk beschrijft, niet je beste team op zijn beste dag en niet je geschreven beleid, maar wat er werkelijk gebeurt.
- Score elk hoofdstuk 1 tot 5. Rond af naar beneden bij twijfel: een praktijk die inconsistent is, is niveau 2, geen niveau 3.
- Neem het gemiddelde van de scores binnen een deel om te zien waar een heel domein staat en kijk dan naar de spreiding: een deel met gemiddeld “3” dat een hoofdstuk op niveau 1 verbergt, heeft nog steeds een risico van niveau 1.
- Beoordeel periodiek opnieuw en volg de trend. Beweging telt meer dan een enkele momentopname.
Volwassenheid is een middel, geen doel
Hogere volwassenheid is niet automatisch beter. Het doel is pasvorm: genoeg rigeur om het risico en de schaal te beheren waarmee je werkelijk te maken hebt, en niet meer. Een klein hulpmiddel met lage inzet heeft geen chaos engineering van niveau 5 nodig. Naar een hoog niveau grijpen als trofee, in plaats van om een echt probleem op te lossen, produceert ceremonie zonder waarde. Lees elk “Niveau 5” hieronder als “gepast wanneer de inzet het rechtvaardigt”, en laat risico, schaal en regelgevende blootstelling bepalen hoe ver je klimt.
Deel 1. Mensen
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Engineeringcultuur en waarden | Cultuur is toevallig en persoonsgedreven. Incidenten betekenen schuld. Kennis leeft in een paar hoofden. | Sommige teams houden nabeschouwingen en schrijven documentatie, maar de praktijk is inconsistent en niet versterkt door leiderschap. | Schuldvrij leren, eigenaarschapsmodellen en een schrijfcultuur zijn organisatiebrede normen met heldere verwachtingen en tooling. | Cultuurgezondheid wordt gemeten (enquêtes naar psychologische veiligheid, leerpercentages van incidenten, behoud) en gevolgd tegen uitgangswaarden en erop gehandeld. | Cultuur wordt continu verbeterd en praktijken verspreiden zich tussen teams. Leiderschap past normen aan naarmate de organisatie groeit en leert. |
| Teamtopologieën | Teams ontstaan toevallig of naar personeelsomvang. De structuur weerspiegelt de legacyhiërarchie. Overal afhankelijkheden. | Er bestaan enkele stroomgerichte teams, maar gedeelde knelpunten en functionele silo’s blijven. | De vier teamtypen en expliciete interactiemodi worden bewust gebruikt. Platformen en InnerSource snijden afhankelijkheden. | Cognitieve last, flow en aantallen afhankelijkheden worden per team gemeten tegen doelen. Grenzen worden bijgesteld wanneer de getallen afglijden. | De organisatie geeft teams en interactiemodi continu een nieuwe vorm om flow te behouden naarmate producten en platformen evolueren. |
| Rollen, loopbaanladders, groei | Geen geschreven ladder. Promoties en loon zijn ad hoc en persoonsgedreven. | Een basisladder bestaat maar wordt inconsistent toegepast. Geen kalibratie. Werving is ongestructureerd. | Dubbele sporen, een heldere competentiematrix, kalibratie en gestructureerde werving zijn standaard. | Doorstroompercentages, gelijke beloning en tijd-op-niveau worden gemeten tegen uitgangswaarden. Kalibratieuitkomsten worden op bias geanalyseerd. | Het kader evolueert continu met het werk. Sponsorschap en meester-gezelleerschap zijn bewust en organisatiebreed naarmate rollen veranderen. |
| Werkwijzen | Proces is ad hoc of cargocult. Communicatie is vergaderingsgedreven en ongedocumenteerd. Schattingen worden als beloftes behandeld. | Een methodologie wordt consistent gevolgd, maar ceremonies zijn routine en coördinatie tussen teams is zwaar. | Praktijken worden gekozen om bij de context te passen. Asynchrone, documentatie-eerst-communicatie is de norm. Schatten informeert, stuurt niet. | Flowstatistieken (doorlooptijd, werk in uitvoering, doorvoer) worden gevolgd tegen uitgangswaarden en elke cyclus beoordeeld. | Teams stemmen hun werkwijze continu af op die statistieken. Coördinatiebehoefte wordt aan de bron geminimaliseerd en goede praktijk verspreidt zich organisatiebreed. |
| Besluitvorming en governance | Beslissingen zijn ad hoc en niet vastgelegd. Governance is afwezig of een algemeen knelpunt. Schuld is onzichtbaar. | Sommige beslissingen zijn gedocumenteerd en enige review bestaat, maar het proces is inconsistent en past niet bij het gewicht van de beslissing. | ADR’s, een gebaande weg, delegatie op omkeerbaarheid en een schuldinventaris zijn standaard en transparant. | Doorlooptijd van beslissingen, omkeringspercentages en schuldniveaus worden gemeten. Toetsing wordt gekalibreerd naar beslissingsgewicht tegen die getallen. | Governance wordt continu over de organisatie afgestemd. Toetsing richt zich op onomkeerbare beslissingen. Schuld en sourcing worden beheerd als evoluerende portfolio’s. |
Deel 2. Softwareprogrammeren
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Codeerstandaarden en stijl | Stijl is per auteur. Geen gedeelde configuraties. Opmaak wordt in review betwist. | Elk team heeft een formatter en linter, maar configuraties en regels variëren per team. | Centrale gedeelde configuraties per taal. CI-afdwinging. Nieuwe repositories erven standaarden via sjablonen. | Adoptie van standaarden, schendingspercentages en impact op reviewtijd worden gemeten tegen uitgangswaarden. Configuraties zijn geversioneerd en bestuurd. | Standaarden worden continu verfijnd uit die data en organisatiebreed gedeeld. Afdwinging is bijna wrijvingloos en past zich aan nieuwe talen aan. |
| Softwareontwerpprincipes | Ontwerp is ad hoc. Koppeling stapelt op. Principes zijn onbekend of worden als slogans aangeroepen. | Teams kennen de principes en passen ze toe, maar inconsistent en vaak dogmatisch. | Gedeeld ontwerpvocabulaire, bewuste analyse van koppeling/cohesie en afgebakende contexten afgestemd op teams. | Metrieken voor koppeling, cohesie en wijzigingsfalen informeren ontwerpreviews tegen uitgangswaarden. Beslissingen worden vastgelegd. | Ontwerpbeslissingen worden herzien naarmate bewijs zich ophoopt. Principes worden met nuance toegepast en paradigmakeuzes passen zich organisatiebreed aan naarmate het domein evolueert. |
| API’s en interfaceontwerp | API’s ontstaan uit implementatie. Geen gedeelde conventies. Brekende wijzigingen zijn gangbaar en onaangekondigd. | Teams volgen basis-REST-conventies en versioneren informeel, maar consistentie en documentatie variëren. | Contract-first-ontwerp, machineleesbare specificaties, een uitfaseringsbeleid en consistente conventies voor fouten/paginering. | Adoptie, latentie, foutpercentages en frequentie van brekende wijzigingen worden per API gemeten tegen doelen. | API’s zijn bestuurde producten in een catalogus met sterke DevEx. De praktijk past zich continu aan en breuken zijn zeldzaam en goed beheerd organisatiebreed. |
| Teststrategie | Testen is handmatig en ad hoc. Geautomatiseerde dekking is minimaal. Regressies zijn frequent. | Geautomatiseerde unit- en enige integratietests bestaan, maar de suite is traag of onbetrouwbaar en vertrouwen is laag. | Een gebalanceerde, snelle, betrouwbare suite poort elke wijziging. Onbetrouwbaarheid wordt beheerd. Niet-functioneel testen is geïntegreerd. | Dekking, onbetrouwbaarheid, ontsnapte defecten en suiteduur worden gevolgd tegen uitgangswaarden om inspanning te richten. | Geavanceerde technieken (property, mutatie, fuzz) richten zich op waardevolle code. De strategie verbetert continu en verspreidt zich over teams. |
| Codereview en samenwerking | Review is inconsistent of overgeslagen. Mechanische kwesties domineren. Feedbacknormen zijn niet gesteld. | Review is vereist maar traag en wisselend. Automatisering is gedeeltelijk. PR-omvang en -kwaliteit variëren sterk. | Kleine PR’s, geautomatiseerde mechanische controles, heldere standaarden en feedbacknormen en bewaakte latentie. | Reviewlatentie, PR-omvang en ontsnappingspercentages van defecten worden gevolgd tegen doelen. Diepte wordt afgestemd op gemeten risico. | De organisatie verbetert review continu uit die data. Pairing en AI-ondersteuning worden bewust ingevoerd en praktijken verspreiden zich tussen teams. |
| Versiebeheer en broncodebeheer | Ad hoc branching. Langlevende branches. Slechte berichten. Geen scannen op geheimen. Frequente samenvoegpijn. | Een consistent branchingmodel en berichtconventies bestaan, maar branches leven te lang en afdwinging is gedeeltelijk. | Trunk-based development, beschermde hoofdlijn, afgedwongen commitconventies, scannen op geheimen, bewuste repositorystructuur. | Levensduur van branches, samenvoegfrequentie en terugdraaipercentages worden gemeten tegen leveringsstatistieken en uitgangswaarden. | Automatisering dwingt hygiëne van begin tot eind af. Repositorystructuur en workflow evolueren continu over de organisatie naarmate leveringsbehoeften veranderen. |
| Documentatie | Documentatie is schaars, verspreid en verouderd. Kennis leeft in de hoofden van mensen. | Sleuteldocumenten bestaan (README’s, enige runbooks) maar worden inconsistent onderhouden en zijn moeilijk te vinden. | Docs-as-code met heldere structuur, gegenereerde API-documentatie en changelogs, beslissingsrecords en updateverwachtingen. | Documentatiedekking, versheid en nauwkeurigheid worden gemeten tegen uitgangswaarden. Veroudering wordt automatisch gemarkeerd. | Documentatie is levend, grotendeels gegenereerd of tegen het systeem getest, bezeten en vindbaar. De praktijk verbetert continu organisatiebreed. |
Deel 3. Systemen
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Architectuurfundamenten | Architectuur is impliciet en leeft in hoofden. Geen kwaliteitsattributen of ADR’s. Beslissingen verschijnen tijdens incidenten. | Sleuteldiagrammen bestaan en grote beslissingen worden soms vastgelegd. Kwaliteitsattributen zijn benoemd maar zelden gekwantificeerd. Documentatie drijft af. | Kwaliteitsattribuutscenario’s en ASR’s zijn gespecificeerd. ADR’s zijn routine. C4-/arc42-documentatie wordt dicht bij de code onderhouden. Afwegingsreviews gebeuren. | Fitnessfuncties dwingen kwaliteitsattributen af in CI en leggen gemeten resultaten vast tegen uitgangswaarden. Afwegingen zijn gekwantificeerd. | Architectuur evolueert continu met die data over de organisatie. Documentatie blijft betrouwbaar genoeg voor auditors terwijl het systeem zich aanpast. |
| Architectuurstijlen en patronen | Eén verwarde monoliet of toevallige gedistribueerde rommel. Grenzen volgen lagen of geschiedenis. Stijl gekozen naar mode. | Bewuste modulaire grenzen of een paar grove services. Enkele transversale zorgen zijn consistent. Splitsingen nog ad hoc. | Services afgestemd op afgebakende contexten die hun eigen data bezitten. Gateway/BFF waar passend. Schone/hexagonale gelaagdheid is standaard. | Stijlbeslissingen zijn op bewijs gebaseerd, met gemeten koppeling, latentie en wijzigingskostendata tegen uitgangswaarden. | Een volwassen platform maakt distributie goedkoop. De organisatie consolideert opnieuw wanneer een splitsing niet meer loont en past stijl aan naarmate bewijs verandert. |
| Gedistribueerde systemen | Externe aanroepen behandeld als lokaal. Geen/naïeve herhalingen. Falen cascaderen. Debuggen is per machine in logs spitten. | Timeouts en basale herhalingen bestaan maar inconsistent. Enige idempotentie. Logs gecentraliseerd maar niet gecorreleerd. | Idempotentie, backoff, circuit breakers, bulkheads via gedeelde bibliotheken. Sagas. Gedistribueerde tracing. Gedocumenteerde consistentie per stroom. | Veerkracht wordt gemeten tegen SLO’s. Resultaten van foutinjectie en faalpercentages worden gevolgd tegen uitgangswaarden. | Veerkracht is de platformstandaard, continu getest met foutinjectie. Soepele degradatie is ingebouwd en evolueert organisatiebreed. |
| Dataarchitectuur en opslag | Eén database voor elk doel. Geen migratiediscipline. Toevallig cachen. Schalen met een grotere machine. | Opslagkeuzes meestal bewust. Een cache en misschien een warehouse. Geversioneerde migraties vragen soms downtime. | Polyglotte persistentie afgestemd op workloads, elke store bezeten. Geautomatiseerde zero-downtimemigraties. Expliciete caching en replica’s. | Opslagkeuzes worden gemeten tegen toegangspatronen, latentie en kostenuitgangswaarden. Beslissingen over sharding en caching zijn datagedreven. | Dataarchitectuur wordt continu over de organisatie beoordeeld en geëvolueerd. Migraties zijn geautomatiseerd en geaudit naarmate workloads veranderen. |
| Schaalbaarheid, prestaties, veerkracht | Enkele instantie of verticaal geschaald. Serverkant-toestand. Geen belastingtests of budgetten. Falen veroorzaken volledige uitval. | Horizontaal geschaalde stateless lagen. Basale autoscaling. Enige belastingtests vóór lancering. DR gedocumenteerd maar zelden getest. | Capaciteit gepland met ruimte. Prestatiebudgetten in CI. Veerkrachtpatronen zijn standaard. RTO/RPO gedefinieerd en DR getest. | Capaciteit wordt voorspeld uit gemeten belasting. Prestatiebudgetten en RTO/RPO worden gevolgd tegen uitgangswaarden. | Geautomatiseerde failover over meerdere regio’s, continue chaos en game days bewijzen en verbeteren hersteldoelstellingen naarmate het systeem organisatiebreed evolueert. |
| Legacymodernisering | Legacy wordt gevreesd en bevroren. Geen inventaris. Modernisering is alles-of-niets herschrijven. Kennis in vertrekkende hoofden. | Een inventaris bestaat en enig risico is begrepen. Legacy omwikkeld met API’s. Nog big-bangdenken. Migratie onderschat. | Systemen geprioriteerd naar risico en waarde. Strangler-fig en branch-by-abstraction zijn standaard. Migratie verzoend met dubbel draaien. | Modernisering wordt als portfolio beheerd met gemeten risico, waarde en voortgang tegen uitgangswaarden. | Modernisering is continu over de organisatie. Incrementele vervanging is routine, omkeerbaar en past zich aan naarmate prioriteiten verschuiven. |
Deel 4. Beveiliging
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Beveiligingsfundamenten en cultuur | Beveiliging is reactief en gecentraliseerd. Reviews laat, als al. Geen dreigingsmodellering. Beveiliging is “het probleem van iemand anders.” | Een beveiligingsteam definieert standaarden. Enige dreigingsmodellering op grote projecten. Basistraining. Beveiliging gezien als poort. | Beveiligingskampioenen ingebed. Dreigingsmodellering is routine. Veilige SDLC gedocumenteerd. Risicogebaseerde prioritering. Schuldvrije reviews. | Beveiligingsstatistieken (dekking dreigingsmodellering, tijd van bevinding tot reparatie, adoptie van maatregelen) worden gevolgd tegen uitgangswaarden. | Beveiliging is werkelijk ieders taak. Dreigingsmodellering is gewoonte. Zero-trust is grotendeels gerealiseerd en de praktijk verbetert continu organisatiebreed. |
| Applicatiebeveiliging | Beveiliging hangt af van individuele kennis. Geen standaardmaatregelen. Geheimen in code. Verouderde afhankelijkheden. Ad hoc authenticatie. | Bekendheid met OWASP Top 10. Enige frameworkbeveiligingen. Geheimenbeheer ongelijk gebruikt. Incidenteel scannen van afhankelijkheden. | Op ASVS gebaseerde eisen per laag. Geparametriseerde queries. Centrale identiteit met MFA. Beheerde geheimen. SBOM’s en pijplijnscannen. | Kwetsbaarheidsdichtheid, gemiddelde tijd tot herstel en maatregeldekking worden gemeten tegen uitgangswaarden over services. | Veilige standaarden worden meegeleverd in frameworks op de gebaande weg. Kortlevende inloggegevens en volledige zekerheid over de toeleveringsketen (SLSA) worden continu organisatiebreed geverifieerd. |
| Infrastructuur- en cloudbeveiliging | Handmatige provisioning. Brede rechten en statische sleutels. Vlakke netwerken. Inconsistente versleuteling. Geen posturebeheer. | Enige IAM-rollen en MFA. Basale netwerklagen. Versleuteling in rust voor grote stores. Periodieke handmatige reviews. Gedeeltelijke IaC. | RBAC/ABAC met minimale rechten en kortlevende inloggegevens. Segmentatie met standaard weigeren. Versleuteling standaard met KMS. CSPM met beleid. | Posture, drift en beleidsschendingsstatistieken worden gevolgd tegen uitgangswaarden. Effectiviteit van vangrails wordt gemeten. | Veilige standaarden worden meegeleverd in landing zones en IaC. Microsegmentatie en preventieve vangrails evolueren continu en drift wordt organisatiebreed automatisch hersteld. |
| Beveiligingsoperaties | Beveiligingstesten handmatig en zeldzaam. Geen centrale logging of SIEM. Geen incidentplan. Ad hoc patchen. Nooit adversarieel getest. | Enige scanners in de pijplijn. Centrale logging. Een basaal incidentplan. Losse patchtermijnen. Jaarlijkse pentest. | Volledig DevSecOps-scannen met risicogebaseerde poorten. SIEM met enige SOAR. Gerepeteerde IR met tabletops. Herstel-SLA’s. Red teaming. | MTTD en MTTR worden gemeten tegen uitgangswaarden. Detectiedekking is gekoppeld aan tegenstandertechnieken en gevolgd. | Testen en respons zijn sterk geautomatiseerd. Purple teaming en detectie-engineering verbeteren continu en passen zich organisatiebreed aan nieuwe dreigingen aan. |
| Privacy en gegevensbescherming | Persoonsgegevens vrij verzameld. Geen inventaris, minimalisatie of bewaring. Toestemming een bijzaak. Geen rechtenproces. | Een privacybeleid en basale toestemming bestaan. Enig bewustzijn van bewaring. Rechtenverzoeken handmatig en traag afgehandeld. | Privacy by design met DPIA’s. Data in kaart gebracht en geclassificeerd. Bewaring afgedwongen. Rechtsgrond gedocumenteerd. Rechten binnen de termijn vervuld. | Privacyhouding wordt gemeten: dekking van data-inventaris, naleving van bewaring en doorlooptijd van rechtenverzoeken tegen uitgangswaarden. | Privacy is een standaard engineeringbeperking. Minimalisatie en geautomatiseerde bewaring zijn standaard. Rechtenverzoeken zijn self-service en de praktijk past zich organisatiebreed aan. |
| Compliance en governance | Compliance is reactief. Geen maatregelenkader. Bewijs handmatig samengesteld onder deadline. Frequente bevindingen. | Sleutelkaders geïdentificeerd. Enige gedocumenteerde maatregelen. Audits slagen met zware handmatige inspanning. Toegankelijkheid laat overwogen. | Een uniform maatregelenkader koppelt standaarden kruislings. Bewijs deels geautomatiseerd. Toegankelijkheid getest. Records en autorisaties ingericht. | Effectiviteit van maatregelen en bewijsdekking worden continu gemeten tegen uitgangswaarden. Bevindingen worden getrend. | Compliance is continu met altijd-aan-bewijs en compliance-as-code. Nieuwe certificeringen zijn goedkoop en het kader past zich organisatiebreed aan, op elk moment auditklaar. |
Deel 5. UI-/UX-ontwerp
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| UX-fundamenten | Geen speciale UX-praktijk. Beslissingen op mening. Onderzoek ad hoc. Inconsistente stromen en terminologie. | Enige ontwerpers en incidenteel usabilitytesten. Persona’s onderhouden niet. UX is een fase, vaak omzeild. | Continu onderzoek met gemengde methoden voedt prioritering. Gedeelde persona’s, journey maps en IA. UX-kwaliteitspoorten in de DoD. | UX-statistieken (taaksucces, tevredenheid, bruikbaarheidsscores) worden gevolgd tegen uitgangswaarden naast bedrijfsstatistieken. | Onderzoek is continu en aan uitkomsten gekoppeld. Gecontroleerde experimenten sluiten de lus en inzichten verspreiden zich over teams naarmate producten evolueren. |
| UI-ontwerp en designsystemen | Elk team bouwt zijn eigen UI. Geen gedeelde componenten. Inconsistent uiterlijk. Hardgecodeerde kleuren en spatiëring. | Een gedeeltelijke stijlgids of componentenbibliotheek bestaat maar is optioneel en vaak niet gesynchroniseerd tussen ontwerp en code. | Een designsysteem met tokens, een onderhouden gecodeerde bibliotheek, documentatie en governance wordt over teams gebruikt. Toegankelijkheid ingebouwd. | Pariteit tussen ontwerp en code, componentadoptie en drift worden gemeten tegen uitgangswaarden. Versionering wordt gevolgd. | Het systeem is een bestuurd product met een roadmap. Het verbetert continu organisatiebreed en rebranding wordt een tokenwijziging. |
| Toegankelijkheid | Geen toegankelijkheidspraktijk. Problemen gevonden via klacht of rechtszaak. Niet-semantische, ongeteste opmaak. | Bewustzijn bestaat. Enig geautomatiseerd scannen en een audit vóór lancering. Toegankelijkheid is een late checklist, vaak gedeprioriteerd. | WCAG 2.2 AA is de standaard. Toegankelijkheid ingebouwd in het designsysteem, getest en in de DoD. Teams getraind met een eigenaar. | Toegankelijkheidsconformiteit wordt in CI gemeten tegen WCAG-uitgangswaarden. Defectpercentages en auditresultaten worden gevolgd. | Toegankelijkheid is continu. Mensen met een beperking worden bij onderzoek betrokken. Het is ingebed in inkoop, tokens en CI en verbetert organisatiebreed. |
| Content- en communicatieontwerp | Geen contentpraktijk. Woorden ad hoc geschreven. Inconsistente terminologie en toon. Nutteloze fouten en lege toestanden. | Een stijlgids kan bestaan. Enig bewustzijn van gewone taal. Content is nog laat in het proces en per team met weinig hergebruik. | Een contentstrategie, gids voor stem en toon en woordenlijst worden over teams gebruikt. Gewone taal is standaard. Gedeelde patronen. | Content wordt gemeten tegen uitkomsten (begrip, taakvoltooiing, foutpercentages) versus uitgangswaarden. | Content wordt continu uit dat bewijs verbeterd. Dark patterns zijn verboden en geaudit. Patronen zijn organisatiebreed standaard gelokaliseerd en toegankelijk. |
| Internationalisering en lokalisatie | Eén taal. Hardgecodeerde strings. Niet-Unicodeaannames. Nieuwe locales vragen codewijzigingen. | Strings geëxternaliseerd en Unicode gebruikt, maar lokalisatie is een handmatige batch vóór lancering. Opmaak en meervouden inconsistent. | Gedeelde i18n-architectuur en locale-bewuste opmaak. Een TMS en continue pijplijn. Pseudolokalisatie en multi-locale CI. | Lokalisatiedekking, versheid van strings en defectpercentages per locale worden gemeten tegen uitgangswaarden. | i18n wordt over teams afgedwongen door tooling en lint. Lokalisatie is continu, culturele aanpassing is systematisch en nieuwe locales lanceren snel. |
| Frontendengineering | Ad hoc frontend per team. Zware clientcode. Geen budgetten. Alleen getest op apparaten van het team. Framework naar hype. | Enige gedeelde tooling en een componentenbibliotheek. Prestaties incidenteel gemeten, niet begroot. Beperkt testen over apparaten. | Framework en rendering bewust gekozen per oppervlak. Budgetten afgedwongen in CI met RUM. Progressive enhancement is standaard. | Prestaties, veerkracht en bereik worden gemeten tegen uitgangswaarden en budgetten van echte gebruikers. Regressies laten de build falen. | Die signalen zijn gekoppeld aan uitkomsten en worden continu verbeterd over oppervlakken naarmate de frontend en haar gebruikers evolueren. |
Deel 6. Kunstmatige intelligentie
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| AI-strategie en gereedheid | Ad hoc experimenten. Geen gedeelde strategie. Beslissingen gedreven door hype en individueel enthousiasme. | Probleemkadering op enige projecten. Een eerste platformbasislijn. Bouwen-tegenover-kopen besproken maar inconsistent. | Een portfolio van toepassingsgevallen met heldere statistieken, een beslisboom, gereedheidsbeoordelingen en afhankelijkheids-/TCO-analyse. | Waarde, adoptie en gereedheid van toepassingsgevallen worden gemeten tegen uitgangswaarden. Portfolio-ROI wordt gevolgd. | AI-strategie is geïntegreerd met bedrijfs- en risicoplanning. Gereedheid wordt continu onderhouden en systemen worden organisatiebreed op bewijs herafgebakend. |
| MLOps | Modellen ad hoc in notebooks gebouwd. Handmatige deployment. Geen data-/modelversionering. Geen bewaking. | Enige experimentvolging en een modelregister. Half geautomatiseerde deployment. Basale bewaking voor een paar modellen. | Gedeeld platform met feature store, register, reproduceerbare pijplijnen, herkomst. Drift-/kwaliteitsbewaking. Bestuurde promotie. | Modelkwaliteit, drift en bedrijfsimpact worden gemeten tegen uitgangswaarden. Hertraining wordt op drempels met poorten getriggerd. | De levenscyclus is volledig geautomatiseerd en controleerbaar. Self-service gebaande wegen en continue evaluatie verbeteren modellen organisatiebreed naarmate data verschuift. |
| Generatieve AI en LLM-toepassingen | Ad hoc prompten in geïsoleerde projecten. Geen grondslag, vangrails of evaluatie. Hallucinaties in productie gevonden. | Enige RAG en promptversionering. Basale uitvoervalidatie. Een kleine handmatige evaluatieset. | Gedeelde patronen voor RAG, vangrails en toolgebruik. Geautomatiseerde offline evaluatie bij elke wijziging. Online statistieken en menselijke review. | Scores van offline en online evaluatie, hallucinatie- en injectiepercentages worden gemeten tegen uitgangswaarden. | Evaluatie is aan uitkomsten gekoppeld en verbetert continu. Injectieverdediging, bestuurde observeerbare agents en beperking passen zich organisatiebreed aan. |
| AI-ondersteunde softwareontwikkeling | Individuen gebruiken assistenten ad hoc. Geen beleid. Geen meting. Geheimen en IE lopen risico. | Basisrichtlijnen en dataregels. Enig beveiligingsscannen. Anekdotische productiviteitsclaims. | Heldere normen per risiconiveau. Verplichte review en scannen. Eerlijke uitkomststatistieken. Veilige deployment en openbaarmaking. | Lever- en kwaliteitsimpact van ondersteuning wordt gemeten tegen uitgangswaarden. Verificatiedekking wordt gevolgd. | Verificatie is sterk in de pijplijn. Vaardigheidsontwikkeling is bewust en beleid past zich continu organisatiebreed aan naarmate tools en bewijs veranderen. |
| Verantwoorde en betrouwbare AI | Geen eerlijkheidstesten, uitleg of governance. Verantwoordelijkheid ongedefinieerd. Problemen pas na schade gevonden. | Enig biastesten en documentatie. Ad hoc toezicht. Bewustzijn van kaders maar gedeeltelijke adoptie. | Governance afgestemd op erkende kaders. Systematisch testen van eerlijkheid/veiligheid/privacy. Gedocumenteerd toezicht en beroep. Red teaming. | Eerlijkheids-, veiligheids- en privacystatistieken worden in productie bewaakt tegen uitgangswaarden en drempels. | Governance is geïntegreerd in oplevering. Verantwoordelijkheid is ieders taak en de aanpak verbetert continu over de organisatie. |
| AI-infrastructuur en beheer | Ad hoc GPU-toewijzing. Geen batching of caching. Geen kostenzicht. Ongeversioneerde prompts. Minimale bewaking. | Enige gedeelde planning en caching. Basale kostenvolging. Prompts in versiebeheer. Ad hoc evaluatie. | Gedeeld platform met planning, quota, batching, caching, dimensionering op maat. Vectorinfrastructuur. Geautomatiseerde evaluatie. Kostentoewijzing. | Benutting, kosten per uitkomst en latentie worden gemeten tegen uitgangswaarden. Budgetten en quota worden afgedwongen. | Routering en schaling zijn geautomatiseerd, LLMOps-observeerbaarheid is volledig en benutting en kosten worden continu geoptimaliseerd met behoud van overdraagbaarheid organisatiebreed. |
Deel 7. Data, analytics en inzicht
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Datastrategie en datagovernance | Data ongedocumenteerd en onbezeten. Conflicterende definities. Kwaliteit gevonden wanneer rapporten breken. Geen catalogus of herkomst. | Enige datasets hebben eigenaren en documentatie. Een gedeeltelijke catalogus. Handmatige, reactieve kwaliteitscontroles. Beleid geschreven maar zwak afgedwongen. | Kritieke dataproducten hebben eigenaren, contracten, SLA’s. Catalogus met geautomatiseerde herkomst. Continue kwaliteit. Gefedereerde governance. | Datakwaliteit, contractnaleving en versheid worden gemeten tegen SLA’s en uitgangswaarden. | Data-als-product is de norm. Contracten worden automatisch afgedwongen, self-servicevangrails passen zich aan en definities worden ondernemingsbreed vertrouwd. |
| Data-engineering | Ad hoc scripts, handmatige runs, geen tests of bewaking. Falen door afnemers gevonden. Kosten onbeheerd. | Enige orkestratie en planning. Basale transformaties in versiebeheer. Incidentele tests. Reactief brandjes blussen. | ELT met gelaagde, geteste, geversioneerde modellen. Georkestreerde afhankelijkheden met herhalingen/backfills. Observeerbaarheid. Kosten gevolgd. | Pijplijnbetrouwbaarheid, versheid en kosten worden gemeten tegen SLA’s. Anomalieën worden gedetecteerd tegen uitgangswaarden. | Pijplijnen zijn software met CI/CD, contracten en testen. Het platform verbetert continu en nieuwe dataproducten worden organisatiebreed snel uitgeleverd. |
| Analytics en business intelligence | Rapporten ad hoc in spreadsheets gebouwd. Inconsistente statistieken. Misleidende grafieken. Geen governance. | Een BI-tool met enige gedeelde dashboards. Statistiekdefinities lopen nog uiteen. Ongecontroleerde self-service en wildgroei begint. | Een semantische laag definieert kernstatistieken eenmaal. Gecertificeerde tegenover experimentele content. Self-service binnen vangrails. Beheerde levenscyclus. | Statistiekgebruik, versheid en definitiewijzigingen worden gevolgd tegen uitgangswaarden. Gecertificeerde content wordt bewaakt. | Statistieken worden bestuurd als API’s met eigenaren en changelogs. Analytics reikt van beschrijvend tot voorschrijvend en bedt zich in op beslismomenten over de organisatie. |
| Productanalytics en experimenteren | Weinig/inconsistente instrumentatie. Beslissingen op mening. Geen experimenten. Ijdele statistieken. Onzorgvuldige toestemming. | Enige gebeurtenissen gevolgd maar taxonomie inconsistent. Incidentele A/B-tests zonder vermogensanalyse. Noordster voorgesteld, niet ingebed. | Een bestuurd, gevalideerd trackingplan. Funnels/cohorten/retentie zijn routine. Experimenten op een gedeeld platform. Toestemming correct afgehandeld. | Experimentvolume, onderscheidend vermogen en winstpercentages worden gemeten tegen uitgangswaarden. Instrumentatiedekking wordt gevolgd. | Experimenteren is de standaard. Een gedeelde resultatenrepository en bezeten instrumentatie laten de organisatie cumulatief leren en zich aanpassen. |
| Beslissingswetenschap en datacultuur | Beslissingen door hiërarchie en intuïtie. Correlatie behandeld als causaliteit. Onzekerheid genegeerd. Statistieken surveilleren en worden bespeeld. | Data selectief geraadpleegd om beslissingen te rechtvaardigen. Enig bewustzijn van causale valkuilen. Onzekerheid zelden gecommuniceerd. | Analyses gekoppeld aan beslissingen met vooraf bepaalde criteria. Correlatie en causaliteit onderscheiden. Onzekerheid gecommuniceerd. Uitkomstgerichtheid. | Beslissingskwaliteit en kalibratie van voorspellingen worden gevolgd tegen uitkomsten en uitgangswaarden. | “Wat zou ons van gedachten doen veranderen?” is routine. Causale rigeur en eerlijke onzekerheid zijn normen en leiders werken zichtbaar bij op bewijs, organisatiebreed. |
Deel 8. Automatisering
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| CI/CD en oplevering | Builds en deploys grotendeels handmatig en inconsistent. Late integratie. Zeldzame, stressvolle releases. Handmatige rollback. | Geautomatiseerde builds en unittests per commit. Gescripte maar handmatig begeleide deploys. Artefacten kunnen per fase opnieuw gebouwd worden. | Een gestandaardiseerde pijplijn promoveert één onveranderlijk artefact door omgevingen met geautomatiseerde poorten. Canary/blue-green. Automatische wijzigingsrecords. | DORA-statistieken (doorlooptijd, deployfrequentie, wijzigingsfaalpercentage, MTTR) worden gevolgd tegen uitgangswaarden en poorten rollbacks. | Progressieve oplevering ontkoppelt release via flags. De pijplijn verbetert zichzelf en compliancebewijs is automatisch over de organisatie. |
| Infrastructure as code en configuratie | Infrastructuur handmatig ingericht. Inconsistente, ongedocumenteerde omgevingen. Traag, onzeker herstel. | Enige infrastructuur gescript, maar praktijken variëren. Inconsistente toestand. Gangbare drift. Beleid afgedwongen via handmatige review. | Declaratieve IaC is standaard uit gedeelde geversioneerde modules met externe toestand. Vangrails als policy-as-code. Regelmatige driftdetectie. | Drift, provisioningtijd en beleidsschendingspercentages worden gemeten tegen uitgangswaarden. Compliancebewijs is automatisch. | Infrastructuur is onveranderlijk, GitOps-gedreven en zelfherstellend. De module- en beleidsbibliotheek verbetert continu en past zich organisatiebreed aan. |
| Containers, orkestratie, cloudnative | Containers ad hoc gebruikt. Met de hand gebouwde ongescande images. Handmatige deploy. Geen gedeeld platform of isolatiemodel. | Teams containeriseren en gebruiken een orkestrator, maar praktijken variëren. Inconsistent scannen en limieten. Onbestuurde kosten en tenancy. | Een gestandaardiseerd platform met geharde images, ondertekenings-/scanpoorten, namespace-tenancy met quota en netwerkbeleid, kostentoewijzing. | Benutting, dichtheid en kosten per workload worden gemeten tegen uitgangswaarden. FinOps-optimalisatie is datagedreven. | Een self-service, zelfherstellend platform met sterke multi-tenancy blijft overdraagbaar en hybride-/soeverein-gereed en verbetert continu organisatiebreed. |
| Platformengineering en DevEx | Geen platform. Elk team stelt zijn eigen tooling inconsistent samen. Ticketgedreven overdrachten. Hoge cognitieve last. | Enige gedeelde tools en sjablonen, maar gefragmenteerd en deels handmatig. Beperkte self-service. DevEx ongemeten. | Een platformteam draait gouden paden, self-serviceprovisioning, een ontwikkelaarsportaal en scorekaarten. Vangrails in gebaande wegen. DevEx gemeten. | Adoptie, DevEx-scores en signalen van cognitieve last worden gemeten tegen uitgangswaarden en beoordeeld. | Een volwassen platformproduct verbetert continu uit die feedback. Vrijwillige adoptie is hoog en governance blijft organisatiebreed onzichtbaar in de workflow. |
| Test- en procesautomatisering | Testen en beheer grotendeels handmatig. Inconsistente dekking. Procedures in hoofden of verouderde documenten. Compliancebewijs met de hand. | Geautomatiseerde tests bestaan maar traag/onbetrouwbaar en inconsistent gedraaid. Enige operationele scripts. Handmatig herstel. Governance via periodieke review. | Snelle, parallelle, betrouwbare testinfrastructuur. Gecodificeerde runbooks. ChatOps. Automatisch gegenereerd compliancebewijs. Governance als geautomatiseerde controles. | Automatiseringsdekking, percentages valse positieven en hersteltijden worden gemeten tegen uitgangswaarden. | Routine-incidenten worden met waarborgen automatisch hersteld. Compliance is continu en auditklaar en mensen richten zich organisatiebreed op oordeel. |
Deel 9. Beheer, betrouwbaarheid en observeerbaarheid
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Site reliability engineering | Beheer handmatig en reactief. Geen SLO’s. Betrouwbaarheid is mening. Dezelfde incidenten keren terug. Brandjes blussen domineert. | Sleutelservices hebben basis-SLI’s/SLO’s. Enige bewaking en alarmering. Sleurwerk erkend maar ongemeten. Inconsistente nabeschouwingen. | Foutbudgetten beïnvloeden prioritering. Sleurwerk gemeten en begrensd. Routinematige capaciteitsplanning. Gefinancierde automatisering. PRR en engagementmodel. | Foutbudgetten, sleurwerk en SLO-behaling worden gemeten tegen uitgangswaarden en sturen prioritering. | Foutbudgetbeleid is geautomatiseerd en gerespecteerd. Self-servicebeheer en proactieve capaciteit laten de organisatie snelheid en stabiliteit op data afwegen en zich aanpassen. |
| Observeerbaarheid en bewaking | Basale uptimecontroles en ongestructureerde logs per machine. Debuggen betekent SSH. Lawaaierige, genegeerde alarmen. | Gecentraliseerde statistieken en logaggregatie. Enige dashboards en drempelalarmen. Gedeeltelijke/afwezige traces. Handmatige correlatie. | OpenTelemetry-instrumentatie met doorgegeven trace-ID’s. Gestructureerde logs, tracing, gecureerde dashboards, SLO-symptoomalarmering. Houdbare bereikbaarheid. | Alarmkwaliteit, MTTD en telemetriekosten worden gemeten tegen uitgangswaarden. Alarmering op verbrandingssnelheid is op SLO’s afgestemd. | Observeerbaarheid met hoge kardinaliteit en rijk aan gebeurtenissen ondersteunt ad-hoconderzoek. Bewaring is kostengeoptimaliseerd en telemetrie informeert beslissingen over de organisatie. |
| Incidentmanagement | Incidenten ad hoc afgehandeld door wie het merkt. Geen rollen, ernstniveaus of nabeschouwingen. Informele bereikbaarheid. Falen keren terug. | Basale bereikbaarheidsroosters en ernstniveaus. Enige nabeschouwingen, maar onduidelijke rollen en inconsistent gevolgde corrigerende acties. | Een formeel incidentcommandosysteem met heldere rollen en criteria. Schuldvrije nabeschouwingen zijn standaard. Acties gevolgd. Bereikbaarheid vergoed. | Incidentfrequentie, MTTR en bereikbaarheidsbelasting worden gemeten tegen uitgangswaarden. Terugkerende oorzaken worden getrend. | Respons wordt gerepeteerd via game days. Bereikbaarheid blijft houdbaar en rustig en geaggregeerde analyse drijft structurele investering naarmate de organisatie leert. |
| Kosten, duurzaamheid, groene software | Cloudkosten zijn een maandelijkse verrassing. Geen tagging, toewijzing of koolstofbewustzijn. Ruimhartige, onherziene provisioning. | Basaal kostenzicht en tagging. Enige reactieve dimensionering op maat en opruiming van ongebruikt. Duurzaamheid erkend maar ongemeten. | Een FinOps-praktijk met toewijzing, budgetten, voorspellingen, anomaliealarmen, verbintenissen, dimensionering op maat. Koolstof gemeten voor grote services. | Kosten en koolstof worden per team gemeten tegen budgetten en uitgangswaarden. Anomalieën worden gemarkeerd. | Kosten en koolstof zijn continue, door teams bezeten signalen. Efficiënte standaarden, geautomatiseerde optimalisatie en koolstofbewuste planning verbeteren continu organisatiebreed. |
Deel 10. Project-, product- en programmamanagement
| Onderwerp | Niveau 1 Initiëren | Niveau 2 Ontwikkelen | Niveau 3 Standaardiseren | Niveau 4 Beheersen | Niveau 5 Orkestreren |
|---|---|---|---|---|---|
| Portfolio- en programmamanagement | Prioriteiten ad hoc gesteld door wie het hardst vraagt. Geen portfolioblik. Afhankelijkheden verschijnen als crises. Jaarlijkse financieringswedlopen. | Een periodiek beoordeelde portfolio-inventaris. Gepubliceerde doelstellingen zwak aan werk gekoppeld. Een afhankelijkhedenregister. Projectgebaseerde begroting. | Strategie cascadeert via OKR’s. Een consistent prioriteringskader. Planning over teams beheert afhankelijkheden. Aanhoudende teamfinanciering. | Portfoliouitkomsten, leveringsvoorspelbaarheid en aantallen afhankelijkheden worden gemeten tegen uitgangswaarden. | Het portfolio wordt continu herbalanceerd op uitkomstbewijs. Afhankelijkheden worden weg ontworpen en financieringsritme past bij leerritme organisatiebreed. |
| Risico, audit en assurance | Risico reactief afgehandeld na incidenten. Geen kader of register. Ongedocumenteerde maatregelen. Pijnlijke handmatige audits. | Risicoregisters voor grote systemen. Een maatregelenkader aangenomen, audits slagen maar handmatig en op momentopnames. Leveranciers bij onboarding beoordeeld. | Drielijnenmodel en gemeenschappelijk kader organisatiebreed. Veel maatregelen geautomatiseerd. Continue bewaking. Leveranciers-/SBOM-inventarissen. Geplande DR. | Effectiviteit van maatregelen, aantallen open risico’s en auditbevindingen worden gemeten tegen risicobereidheid en uitgangswaarden. | Assurance is continu en grotendeels geautomatiseerd. Auditors nemen steekproeven uit live bewijs en integriteit van de toeleveringsketen wordt geverifieerd naarmate risico’s organisatiebreed evolueren. |
| Inkoop, open source, licenties | Open source vrij toegevoegd. Geen beleid of inventaris. Licenties onbeproefd. Einde levensduur per ongeluk gevonden. Geen eigenaar. | Een basisbeleid en goedgekeurde licentielijst. Handmatig/laat scannen. Een inventaris voor grote systemen. Ad hoc bijdragen. | Een OSPO bezit strategie en tooling. Geautomatiseerd licentie-/kwetsbaarheidsscannen en naamsvermelding. SBOM’s. Heldere bijdragen. Einde levensduur gevolgd. | Licentienaleving, actualiteit van afhankelijkheden en kwetsbaarheidsblootstelling worden gemeten tegen uitgangswaarden. | Open source is een beheerd strategisch bezit met volledig geautomatiseerde compliance. Investering in upstream is bewust en actualiteit en einde levensduur worden continu organisatiebreed beheerd. |
| Grote en langlevende systemen in stand houden | Systemen hangen af van helden. Eigenaarschap uit geheugen. Ongedocumenteerde kennis. Systemen bevroren tot ze breken. Uitfaseringen nooit afgemaakt. | Eigenaarschap toegewezen en vastgelegd voor grote systemen. Enige documentatie en runbooks. Voor de hand liggende kritieke functies hebben een back-uppersoon. Reactief onderhoud. | Eigenaarschap op teamniveau in een catalogus die reorganisaties overleeft. Bus factor gemeten en beperkt. Beslissingsrecords en runbooks. Incrementele modernisering. | Bus factor, eigenaarschapsdekking en voortgang van kennisoverdracht worden gemeten tegen uitgangswaarden. | Rentmeesterschap is een gefinancierde discipline. Geen enkel kritiek systeem is een menselijke single point of failure en kennisoverdracht en geplande einden gaan organisatiebreed door. |
| Ethiek, verantwoording, publiek belang | Ethiek onbehandeld of reactief na schandaal. Toegankelijkheid genegeerd. Ondoorzichtige geautomatiseerde beslissingen zonder verhaal. Bias ongetest. | Een gedragscode en enige (late) toegankelijkheid. Opzienbarende geautomatiseerde beslissingen krijgen enig toezicht. Incidentele biascontroles. | Ethische review maakt deel uit van het proces. Toegankelijkheid ingebouwd en door gebruikers getest. Ingrijpende beslissingen dragen uitleg en verhaal. | Uitkomsten voor gelijkheid, toegankelijkheid en algoritmische verantwoording worden bewaakt tegen uitgangswaarden. | Verantwoordelijkheid is ingebed in hoe de organisatie bouwt. Gelijkheid is een onbetwistbare standaard en algoritmische verantwoording is standaard en wordt organisatiebreed continu verbeterd. |
Algemene zelfbeoordeling van volwassenheid
Gebruik de bovenstaande matrices om een lichte, eerlijke score te produceren.
Scoringsrubriek
- Score elk hoofdstuk 1 tot 5 met het niveau waarvan de beschrijving het best past bij je typische werkelijkheid. Wanneer gedrag inconsistent is, score het lagere niveau.
- Neem het gemiddelde per deel. Tel de hoofdstukscores in een deel op en deel door het aantal hoofdstukken. Dit geeft een volwassenheid per deel (bijv. “Deel IV gemiddeld 2,5”).
- Leg het minimum vast, niet alleen het gemiddelde. Een deel dat gemiddeld 3,0 scoort maar een hoofdstuk op niveau 1 bevat, draagt het risico van dat hoofdstuk ongeacht het gemiddelde.
- Zet de trend uit. Score elk kwartaal of elke twee kwartalen opnieuw en let op de richting van beweging. Een domein dat van 2 naar 3 beweegt is gezonder dan een dat vastzit op een statische 3.
Een eenvoudig werkblad per deel:
| Deel | Gescoorde hoofdstukken | Gemiddelde | Laagste hoofdstuk | Notities / prioriteit |
|---|---|---|---|---|
| I-X | aantal | gemiddelde | laagste niveau | … |
Prioriteren wat te verbeteren
Probeer niet alles tegelijk te verhogen en jaag niet het hoogste gemiddelde na. Prioriteer op risicogewogen volwassenheidsgat: val de domeinen aan waar een laag niveau hoge gevolgen ontmoet.
- Eerst: de hoofdstukken met de laagste volwassenheid in je domeinen met het hoogste risico. Voor de meeste organisaties betekent dat beveiliging, privacy, betrouwbaarheid, compliance en elk systeem waarvan falen mensen schaadt of de wet schendt. Een niveau 1 hier is urgent.
- Daarna: fundamentele versnellers (cultuur, werkwijzen, CI/CD, IaC, observeerbaarheid) die het plafond voor elk ander domein verhogen. Deze verbeteren maakt latere winst goedkoper.
- Later: domeinen die al op niveau 3 zitten en naar niveau 4 of 5 kunnen klimmen. Duw alleen voorbij de ondergrens waar de inzet en schaal de extra investering rechtvaardigen.
De basislijn voor onderneming en overheid
Contexten van onderneming en overheid kunnen meestal niet stoppen bij “het werkt.” Om audits te doorstaan, autorisaties te behouden en aan regelgevende en publieke verantwoordingsverplichtingen te voldoen, moeten de meeste domeinen minstens niveau 3 (Standaardiseren) bereiken, het niveau waar praktijken zijn gestandaardiseerd, gedocumenteerd, over teams afgedwongen en bewijs produceren. Niveau 2 faalt doorgaans voor audit omdat het inconsistent is en onder deadline met de hand wordt samengesteld. Niveau 1 faalt direct.
Lees niveau 3 als de ondergrens voor alles wat controleerbaar of veiligheidsrelevant is, en de hogere niveaus (4 en 5) als doelen alleen waar continue assurance, schaal of publiek vertrouwen de extra rigeur de moeite waard maken. Volwassenheid blijft een middel: het doel is een verdedigbaar, evenredig niveau van beheersing voor het risico dat je werkelijk draagt, geen perfecte score.