12.4
12.4 Selvvurdering af modenhed
Hvert kapitel i denne guidebog slutter med en “Modenhedsmodel”, der beskriver, hvordan en praksis typisk udvikler sig. Dette bilag samler hvert kapitels modenhedsmodel i én reference, så I kan vurdere et team, et domæne eller en hel organisation med et blik.
Den fælles femtrinsskala
Alle kapitler beskriver den samme progression. Den præcise formulering varierer lidt mellem kapitler, men hensigten kortlægges rent på disse fem niveauer:
- Niveau 1, Opstart. Ad hoc, reaktivt og personafhængigt. Praksisser findes kun, hvor en enkeltperson vælger dem, så udfald afhænger af heltemod og held.
- Niveau 2, Udvikling. Grundlæggende praksisser findes, men de er inkonsistente på tværs af teams, delvis manuelle og ofte omgået under pres.
- Niveau 3, Standardisering. Praksisser er dokumenterede, standardiserede og håndhævet organisationsdækkende. Det er bunden for revision og compliance: det niveau, det meste virksomheds- og offentlige arbejde må nå for at være pålideligt og revisionsbart.
- Niveau 4, Styring. Praksisser måles og styres med data og målinger mod baselines. I ved kvantitativt, hvordan hver praksis præsterer, og I handler på tallene.
- Niveau 5, Orkestrering. Praksisser forbedres løbende, er integreret på tværs af organisationen og adaptive. Den sikre eller rigtige sti er standarden, og organisationen lærer og udvikler sig bevidst.
Sådan bruger I den til selvvurdering
- For hvert kapitel, der er relevant for jeres kontekst, så læs de fem celler nedenfor, og vælg det niveau, der ærligt beskriver jeres typiske adfærd, ikke jeres bedste team på dets bedste dag og ikke jeres skrevne politik, men hvad der faktisk sker.
- Score hvert kapitel fra 1 til 5. Rund ned i tvivlstilfælde; en praksis, der er inkonsistent, er niveau 2, ikke niveau 3.
- Beregn gennemsnittet af scorer inden for en del for at se, hvor et helt domæne står, og se så på spredningen: en del på “3 i gennemsnit”, der skjuler et niveau 1-kapitel, har stadig en niveau 1-risiko.
- Revurdér med jævne mellemrum, og følg trenden. Bevægelse betyder mere end noget enkelt øjebliksbillede.
Modenhed er et middel, ikke et mål
Højere modenhed er ikke automatisk bedre. Målet er pasform: nok stringens til at styre den risiko og skala, I faktisk står over for, og ikke mere. Et lille værktøj med lav indsats har ikke brug for niveau 5-kaosingeniørarbejde. At række efter et højt niveau som et trofæ frem for at løse et reelt problem producerer ceremoni uden værdi. Læs hvert “niveau 5” nedenfor som “passende, når indsatsen retfærdiggør det”, og lad risiko, skala og regulatorisk eksponering afgøre, hvor langt I klatrer.
Del 1. Mennesker
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Ingeniørkultur og værdier | Kultur er tilfældig og personafhængig; hændelser betyder skyld; viden bor i få hoveder. | Nogle teams kører postmortems og skriver dokumentation, men praksis er inkonsistent og uforstærket af ledelsen. | Skyldfri læring, ejerskabsmodeller og en skrivekultur er organisationsdækkende normer med klare forventninger og værktøj. | Kulturens sundhed måles (undersøgelser af psykologisk tryghed, hændelseslæringsrater, fastholdelse) og følges mod baselines og handles på. | Kultur forbedres løbende, og praksisser spreder sig mellem teams; ledelsen tilpasser normer, efterhånden som organisationen vokser og lærer. |
| Teamtopologier | Teams dannes ved et tilfælde eller af headcount; struktur spejler det ældre hierarki; afhængigheder overalt. | Nogle strømafstemte teams findes, men delte flaskehalse og funktionelle siloer består. | De fire teamtyper og eksplicitte samspilsformer bruges bevidst; platforme og InnerSource skærer afhængigheder. | Kognitiv belastning, flow og afhængighedsantal måles pr. team mod mål; grænser justeres, når tallene glider. | Organisationen omformer løbende teams og samspilsformer for at opretholde flow, efterhånden som produkter og platforme udvikler sig. |
| Roller, karrierestiger, vækst | Ingen skrevet stige; forfremmelser og løn er ad hoc og personafhængige. | En grundlæggende stige findes, men anvendes inkonsistent; ingen kalibrering; ansættelse er ustruktureret. | Dobbelte spor, en klar kompetencematrix, kalibrering og struktureret ansættelse er standard. | Progressionsrater, lønlighed og tid-på-niveau måles mod baselines; kalibreringsudfald analyseres for bias. | Rammeværket udvikler sig løbende med arbejdet; sponsorat og lærlingeforløb er bevidste og organisationsdækkende, efterhånden som roller ændrer sig. |
| Arbejdsformer | Proces er ad hoc eller cargo-kult; kommunikation er mødedrevet og udokumenteret; estimater behandles som løfter. | En metodologi følges konsekvent, men ceremonier er rutinemæssige, og koordinering på tværs af teams er tung. | Praksisser vælges, så de passer til konteksten; asynkron, dokumentation-først-kommunikation er normen; estimering informerer, styrer ikke. | Flowmålinger (ledetid, igangværende arbejde, gennemløb) følges mod baselines og gennemgås hver cyklus. | Teams tuner løbende deres arbejdsform ud fra disse målinger; koordineringsbehovet minimeres ved kilden, og god praksis spreder sig organisationsdækkende. |
| Beslutningstagning og styring | Beslutninger er ad hoc og uregistrerede; styring er fraværende eller en generel flaskehals; gæld er usynlig. | Nogle beslutninger er dokumenteret, og noget gennemgang findes, men processen er inkonsistent og ude af trit med beslutningens vægt. | ADR’er, en asfalteret vej, reversibilitetsbaseret delegation og en gældsopgørelse er standard og gennemsigtige. | Beslutningscyklustid, omgørelsesrater og gældsniveauer måles; granskning kalibreres efter beslutningens vægt mod disse tal. | Styring tunes løbende på tværs af organisationen; granskning rettes mod uigenkaldelige beslutninger; gæld og sourcing styres som udviklende porteføljer. |
Del 2. Softwareprogrammering
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Kodestandarder og stil | Stil er pr. forfatter; ingen fælles konfigurationer; formatering diskuteres i gennemgang. | Hvert team har en formatter og linter, men konfigurationer og regler varierer på tværs af teams. | Centrale fælles konfigurationer pr. sprog; CI-håndhævelse; nye repositories arver standarder via skabeloner. | Standardadoption, overtrædelsesrater og gennemgangstidspåvirkning måles mod baselines; konfigurationer er versionerede og styrede. | Standarder forfines løbende ud fra de data og deles organisationsdækkende; håndhævelse er næsten friktionsfri og tilpasser sig nye sprog. |
| Softwaredesignprincipper | Design er ad hoc; kobling ophobes; principper er ukendte eller påberåbes som slogans. | Teams kender principperne og anvender dem, men inkonsistent og ofte dogmatisk. | Fælles designordforråd, bevidst koblings-/kohæsionsanalyse og bounded contexts afstemt med teams. | Koblings-, kohæsions- og ændringsfejlmålinger informerer designgennemgange mod baselines; beslutninger registreres. | Designbeslutninger genbesøges, efterhånden som dokumentation ophobes; principper anvendes med nuance, og paradigmevalg tilpasser sig organisationsdækkende, efterhånden som domænet udvikler sig. |
| API’er og grænsefladedesign | API’er opstår af implementeringen; ingen fælles konventioner; brydende ændringer er almindelige og uanmeldte. | Teams følger grundlæggende REST-konventioner og versionerer uformelt, men ensartethed og dokumentation varierer. | Kontraktførst-design, maskinlæsbare specifikationer, en udfasningspolitik og ensartede fejl-/pagineringskonventioner. | Adoption, latens, fejlrater og hyppighed af brydende ændringer måles pr. API mod mål. | API’er er styrede produkter i et katalog med stærk DevEx; praksissen tilpasser sig løbende, og brud er sjældne og velstyrede organisationsdækkende. |
| Teststrategi | Test er manuel og ad hoc; automatiseret dækning er minimal; regressioner er hyppige. | Automatiserede enheds- og nogle integrationstests findes, men suiten er langsom eller ustabil, og tilliden er lav. | En afbalanceret, hurtig, pålidelig suite gater hver ændring; ustabilitet styres; ikke-funktionel test er integreret. | Dækning, ustabilitet, undsluppne defekter og suitevarighed følges mod baselines for at målrette indsatsen. | Avancerede teknikker (property, mutation, fuzz) målretter højværdi-kode; strategien forbedres løbende og spreder sig på tværs af teams. |
| Kodegennemgang og samarbejde | Gennemgang er inkonsistent eller sprunget over; mekaniske problemer dominerer; feedbacknormer er ikke sat. | Gennemgang er påkrævet, men langsom og varierende; automatisering er delvis; PR-størrelse og -kvalitet varierer meget. | Små PR’er, automatiserede mekaniske tjek, klare standarder og feedbacknormer og overvåget latens. | Gennemgangslatens, PR-størrelse og defektundslippelsesrater følges mod mål; dybde afstemmes efter målt risiko. | Organisationen forbedrer løbende gennemgang ud fra de data; parprogrammering og AI-assistance adopteres bevidst, og praksisser spreder sig mellem teams. |
| Versionsstyring og kildestyring | Ad hoc-forgrening; langlivede grene; dårlige meddelelser; ingen hemmelighedsscanning; hyppig flettesmerte. | En ensartet forgreningsmodel og meddelelseskonventioner findes, men grene lever for længe, og håndhævelsen er delvis. | Trunk-baseret udvikling, beskyttet hovedlinje, håndhævede commitkonventioner, hemmelighedsscanning, bevidst repositorystruktur. | Grenlevetid, fletningsfrekvens og tilbagerulningsrater måles mod leveringsmålinger og baselines. | Automatisering håndhæver hygiejne fra ende til anden; repositorystruktur og arbejdsgang udvikler sig løbende på tværs af organisationen, efterhånden som leveringsbehov ændrer sig. |
| Dokumentation | Dokumentation er sparsom, spredt og forældet; viden bor i folks hoveder. | Nøgledokumenter findes (README’er, nogle runbooks), men vedligeholdes inkonsistent og er svære at finde. | Docs-as-code med klar struktur, genererede API-dokumenter og changelogs, beslutningsregistre og opdateringsforventninger. | Dokumentationsdækning, friskhed og nøjagtighed måles mod baselines; forældelse flagges automatisk. | Dokumentation er levende, i vid udstrækning genereret eller testet mod systemet, ejet og kan findes; praksissen forbedres løbende organisationsdækkende. |
Del 3. Systemer
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Arkitekturgrundprincipper | Arkitektur er implicit og bor i hoveder; ingen kvalitetsegenskaber eller ADR’er; beslutninger dukker op under hændelser. | Nøglediagrammer findes, og større beslutninger registreres nogle gange; kvalitetsegenskaber er navngivet, men sjældent kvantificeret; dokumentation driver. | Kvalitetsegenskabsscenarier og ASR’er er specificeret; ADR’er er rutine; C4/arc42-dokumentation vedligeholdes tæt på koden; afvejningsgennemgange sker. | Fitness functions håndhæver kvalitetsegenskaber i CI og registrerer målte resultater mod baselines; afvejninger er kvantificeret. | Arkitekturen udvikler sig løbende med de data på tværs af organisationen; dokumentation forbliver troværdig nok til revisorer, efterhånden som systemet tilpasser sig. |
| Arkitekturstile og mønstre | Én sammenfiltret monolit eller et tilfældigt distribueret rod; grænser følger lag eller historie; stil valgt efter mode. | Bevidste modulære grænser eller nogle få grove tjenester; nogle tværgående anliggender er ensartede; opdelinger stadig ad hoc. | Tjenester afstemt med bounded contexts, der ejer deres data; gateway/BFF, hvor det passer; ren/hexagonal lagdeling er standard. | Stilbeslutninger er dokumentationsbaserede og bruger målt kobling, latens og ændringsomkostningsdata mod baselines. | En moden platform gør distribution billig; organisationen konsoliderer igen, når en opdeling holder op med at betale sig, og tilpasser stil, efterhånden som dokumentationen ændrer sig. |
| Distribuerede systemer | Fjernkald behandles som lokale; ingen/naive genforsøg; fejl kaskaderer; fejlfinding er log-udgravning pr. maskine. | Timeouts og grundlæggende genforsøg findes, men er inkonsistente; noget idempotens; logs centraliseret, men ukorrelerede. | Idempotens, backoff, circuit breakers og bulkheads via fælles biblioteker; sagas; distribueret tracing; dokumenteret konsistens pr. flow. | Robusthed måles mod SLO’er; fejlinjektionsresultater og fejlrater følges mod baselines. | Robusthed er platformens standard, løbende testet med fejlinjektion; yndefuld nedgradering er designet ind og udvikler sig organisationsdækkende. |
| Dataarkitektur og lagring | Én database til alle formål; ingen migreringsdisciplin; tilfældig caching; skalering ved større maskine. | Lagringsvalg er for det meste bevidste; en cache og måske et lager; versionerede migreringer kræver nogle gange nedetid. | Polyglot persistens tilpasset arbejdsbelastninger, hvert lager ejet; automatiserede migreringer uden nedetid; eksplicit caching og replikaer. | Lagringsvalg måles mod adgangsmønstre, latens og omkostningsbaselines; sharding- og cachebeslutninger er datadrevne. | Dataarkitektur gennemgås og udvikles løbende på tværs af organisationen; migreringer er automatiserede og reviderede, efterhånden som arbejdsbelastninger ændrer sig. |
| Skalerbarhed, ydeevne, robusthed | Enkelt instans eller lodret skaleret; tilstand på serversiden; ingen belastningstest eller budgetter; fejl forårsager fulde nedbrud. | Vandret skalerede tilstandsløse lag; grundlæggende autoskalering; nogle belastningstests før lancering; DR dokumenteret, men sjældent testet. | Kapacitet planlagt med ekstra plads; ydeevnebudgetter i CI; robusthedsmønstre er standard; RTO/RPO defineret og DR testet. | Kapacitet prognosticeres ud fra målt belastning; ydeevnebudgetter og RTO/RPO følges mod baselines. | Automatisk failover på tværs af regioner, kontinuerlig kaos og game days beviser og forbedrer genoprettelsesmål, efterhånden som systemet udvikler sig organisationsdækkende. |
| Modernisering af ældre systemer | Ældre systemer frygtes og er frosne; ingen opgørelse; modernisering er alt-eller-intet-omskrivning; viden i pensionerende hoveder. | En opgørelse findes, og noget risiko er forstået; ældre systemer omviklet med API’er; stadig big-bang-tænkning; migrering undervurderet. | Systemer prioriteret efter risiko og værdi; strangler-fig og branch-by-abstraction er standard; migrering afstemt med dobbeltkørsel. | Modernisering styres som portefølje med målt risiko, værdi og fremskridt mod baselines. | Modernisering er kontinuerlig på tværs af organisationen; trinvis udskiftning er rutine, reversibel og tilpasser sig, efterhånden som prioriteter skifter. |
Del 4. Sikkerhed
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Sikkerhedsgrundlag og kultur | Sikkerhed er reaktiv og centraliseret; gennemgange sent, hvis overhovedet; ingen trusselsmodellering; sikkerhed er “en andens problem.” | Et sikkerhedsteam definerer standarder; noget trusselsmodellering på større projekter; grundlæggende træning; sikkerhed ses som en port. | Sikkerhedsambassadører indlejret; trusselsmodellering er rutine; sikker SDLC dokumenteret; risikobaseret prioritering; skyldfri gennemgange. | Sikkerhedsmålinger (trusselsmodelleringsdækning, tid fra fund til rettelse, kontroladoption) følges mod baselines. | Sikkerhed er reelt alles opgave; trusselsmodellering er en vane; zero trust er i vid udstrækning realiseret, og praksissen forbedres løbende organisationsdækkende. |
| Applikationssikkerhed | Sikkerhed afhænger af individuel viden; ingen standardkontroller; hemmeligheder i kode; forældede afhængigheder; ad hoc-autentificering. | OWASP Top 10-bevidsthed; nogle rammeværksbeskyttelser; hemmelighedsstyring ujævnt brugt; lejlighedsvis afhængighedsscanning. | ASVS-baserede krav pr. niveau; parameteriserede forespørgsler; central identitet med MFA; administrerede hemmeligheder; SBOM’er og pipelinescanning. | Sårbarhedstæthed, gennemsnitlig tid til afhjælpning og kontroldækning måles mod baselines på tværs af tjenester. | Sikre standarder leveres i asfalterede rammeværker; kortlivede legitimationsoplysninger og fuld forsyningskædesikring (SLSA) verificeres løbende organisationsdækkende. |
| Infrastruktur- og cloudsikkerhed | Manuel provisionering; brede tilladelser og statiske nøgler; flade netværk; inkonsistent kryptering; ingen tilstandsstyring. | Nogle IAM-roller og MFA; grundlæggende netværkslag; kryptering i hvile for større lagre; periodiske manuelle gennemgange; delvis IaC. | Least-privilege RBAC/ABAC med kortlivede legitimationsoplysninger; default-deny-segmentering; kryptering som standard med KMS; CSPM med politik. | Tilstands-, afdrifts- og politikovertrædelsesmålinger følges mod baselines; rækværkets effektivitet måles. | Sikre standarder leveres i landing zones og IaC; mikrosegmentering og forebyggende rækværk udvikler sig løbende, og afdrift afhjælpes automatisk organisationsdækkende. |
| Sikkerhedsdrift | Sikkerhedstest manuel og sjælden; ingen central logning eller SIEM; ingen hændelsesplan; ad hoc-patching; aldrig testet fjendtligt. | Nogle scannere i pipelinen; central logning; en grundlæggende hændelsesplan; løse patchingtidslinjer; årlig pentest. | Fuld DevSecOps-scanning med risikobaserede porte; SIEM med noget SOAR; indøvet IR med tabletop-øvelser; afhjælpnings-SLA’er; red teaming. | MTTD og MTTR måles mod baselines; detektionsdækning kortlægges til modstandertekniker og følges. | Test og respons er højt automatiserede; purple teaming og detektionsudvikling forbedres løbende og tilpasser sig nye trusler organisationsdækkende. |
| Privatliv og databeskyttelse | Personoplysninger indsamles frit; ingen opgørelse, minimering eller opbevaring; samtykke en eftertanke; ingen rettighedsproces. | En privatlivspolitik og grundlæggende samtykke findes; noget opmærksomhed på opbevaring; rettighedsanmodninger håndteres manuelt og langsomt. | Privatliv gennem design med DPIA’er; data kortlagt og klassificeret; opbevaring håndhævet; lovligt grundlag dokumenteret; rettigheder opfyldt til tiden. | Privatlivstilstanden måles: dataopgørelsesdækning, opbevaringsoverholdelse og rettighedsanmodningers behandlingstid mod baselines. | Privatliv er en standardbegrænsning i ingeniørarbejdet; minimering og automatiseret opbevaring er standard; rettighedsanmodninger er selvbetjening, og praksissen tilpasser sig organisationsdækkende. |
| Compliance og styring | Compliance er reaktiv; ingen kontrolramme; dokumentation samlet manuelt under deadline; hyppige fund. | Nøglerammeværker identificeret; nogle dokumenterede kontroller; revisioner bestås med tungt manuelt arbejde; tilgængelighed overvejet sent. | En samlet kontrolramme krydskortlægger standarder; dokumentation delvis automatiseret; tilgængelighed testet; registre og tilladelser etableret. | Kontrolleffektivitet og dokumentationsdækning måles løbende mod baselines; fund trendes. | Compliance er kontinuerlig med altid-aktiv dokumentation og compliance-as-code; nye certificeringer er billige, og rammeværket tilpasser sig organisationsdækkende, revisionsklar til enhver tid. |
Del 5. UI/UX-design
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| UX-grundlag | Ingen dedikeret UX-praksis; beslutninger efter mening; forskning ad hoc; inkonsistente flow og terminologi. | Nogle designere og lejlighedsvis usability-test; personas uvedligeholdte; UX er en fase, ofte omgået. | Kontinuerlig blandet-metode-forskning fodrer prioritering; fælles personas, rejsekort og IA; UX-kvalitetsporte i DoD. | UX-målinger (opgavesucces, tilfredshed, usability-scorer) følges mod baselines ved siden af forretningsmålinger. | Forskning er kontinuerlig og udfaldskoblet; kontrollerede eksperimenter lukker løkken, og indsigter spreder sig på tværs af teams, efterhånden som produkter udvikler sig. |
| UI-design og designsystemer | Hvert team bygger sin egen UI; ingen fælles komponenter; inkonsistent udseende; hardkodede farver og afstande. | En delvis stilguide eller komponentbibliotek findes, men er valgfri og ofte ude af trit mellem design og kode. | Et tokeniseret designsystem med et vedligeholdt kodet bibliotek, dokumentation og styring bruges på tværs af teams; a11y bygget ind. | Design-kode-paritet, komponentadoption og afdrift måles mod baselines; versionering følges. | Systemet er et styret produkt med en køreplan; det forbedres løbende organisationsdækkende, og rebranding bliver token-ændringer. |
| Tilgængelighed | Ingen tilgængelighedspraksis; problemer findes via klage eller retssag; ikke-semantisk, utestet markup. | Bevidsthed findes; noget automatiseret scanning og en revision før lancering; a11y er en sen tjekliste, ofte nedprioriteret. | WCAG 2.2 AA er standarden; a11y bygget ind i designsystemet, testet og i DoD; teams trænet med en ejer. | Tilgængelighedskonformitet måles i CI mod WCAG-baselines; defektrater og revisionsresultater følges. | Tilgængelighed er kontinuerlig; mennesker med handicap deltager i forskning; den er indlejret i indkøb, tokens og CI og forbedres organisationsdækkende. |
| Indholds- og kommunikationsdesign | Ingen indholdspraksis; ord skrevet ad hoc; inkonsistent terminologi og tone; uhjælpsomme fejl og tomme tilstande. | En stilguide kan findes; noget bevidsthed om klart sprog; indhold stadig sent i forløbet og pr. team med lidt genbrug. | En indholdsstrategi, stemme-og-tone-guide og ordliste bruges på tværs af teams; klart sprog er standard; fælles mønstre. | Indhold måles mod udfald (forståelse, opgavegennemførelse, fejlrater) versus baselines. | Indhold forbedres løbende ud fra den dokumentation; mørke mønstre er forbudt og revideres; mønstre er lokaliserede og tilgængelige som standard organisationsdækkende. |
| Internationalisering og lokalisering | Ét sprog; hardkodede strenge; ikke-Unicode-antagelser; nye lokaliteter kræver kodeændringer. | Strenge eksternaliseret og Unicode brugt, men lokalisering er et manuelt parti før lancering; formatering og flertal inkonsistente. | Fælles i18n-arkitektur og lokalitetsbevidst formatering; en TMS og kontinuerlig pipeline; pseudolokalisering og multilokalitets-CI. | Lokaliseringsdækning, strengfriskhed og lokalitetsdefektrater måles mod baselines. | i18n håndhæves af værktøj og lint på tværs af teams; lokalisering er kontinuerlig, kulturel tilpasning er systematisk, og nye lokaliteter lanceres hurtigt. |
| Frontend-ingeniørarbejde | Ad hoc frontend pr. team; tung klientkode; ingen budgetter; kun testet på teamets enheder; rammeværk valgt efter hype. | Noget fælles værktøj og et komponentbibliotek; ydeevne måles lejlighedsvis, ikke budgetteret; begrænset test på tværs af enheder. | Rammeværk og rendering valgt bevidst pr. flade; budgetter håndhævet i CI med RUM; progressiv forbedring er standard. | Ydeevne, robusthed og rækkevidde måles mod baselines og budgetter fra rigtige brugere; regressioner fejler buildet. | Disse signaler knyttes til udfald og forbedres løbende på tværs af flader, efterhånden som frontenden og dens brugere udvikler sig. |
Del 6. Kunstig intelligens
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| AI-strategi og parathed | Ad hoc-eksperimenter; ingen fælles strategi; beslutninger drevet af hype og individuel begejstring. | Problemindramning på nogle projekter; en første platformsbaseline; bygge-versus-køb drøftet, men inkonsistent. | En portefølje af anvendelsestilfælde med klare målinger, et beslutningstræ, paratsvurderinger og indlåsnings-/TCO-analyse. | Anvendelsestilfældes værdi, adoption og parathed måles mod baselines; porteføljens ROI følges. | AI-strategien er integreret med forretnings- og risikoplanlægning; parathed vedligeholdes løbende, og systemer omafgrænses på dokumentation organisationsdækkende. |
| MLOps | Modeller bygget ad hoc i notebooks; manuel udrulning; ingen data-/modelversionering; ingen overvågning. | Noget eksperimentsporing og et modelregister; halvautomatiseret udrulning; grundlæggende overvågning for nogle få modeller. | Fælles platform med feature store, register, reproducerbare pipelines, afstamning; drift-/kvalitetsovervågning; styret promovering. | Modelkvalitet, drift og forretningspåvirkning måles mod baselines; gentræning udløses på tærskler med porte. | Livscyklussen er fuldt automatiseret og revisionsbar; selvbetjente asfalterede veje og kontinuerlig evaluering forbedrer modeller organisationsdækkende, efterhånden som data skifter. |
| Generativ AI og LLM-applikationer | Ad hoc-prompting i isolerede projekter; ingen forankring, rækværk eller evaluering; hallucinationer findes i produktion. | Noget RAG og promptversionering; grundlæggende outputvalidering; et lille manuelt evalueringssæt. | Fælles mønstre for RAG, rækværk og værktøjsbrug; automatiseret offline evaluering ved hver ændring; online målinger og menneskelig gennemgang. | Offline- og online-evalueringsscorer, hallucinations- og injektionsrater måles mod baselines. | Evaluering knyttes til udfald og forbedres løbende; injektionsforsvar, styrede observerbare agenter og afbødning tilpasser sig organisationsdækkende. |
| AI-assisteret softwareudvikling | Enkeltpersoner bruger assistenter ad hoc; ingen politik; ingen måling; hemmeligheder og IP i fare. | Grundlæggende brugsvejledning og dataregler; noget sikkerhedsscanning; anekdotiske produktivitetspåstande. | Klare normer efter risikoniveau; obligatorisk gennemgang og scanning; ærlige udfaldsmålinger; sikker udrulning og offentliggørelse. | Leverings- og kvalitetspåvirkningen af assistance måles mod baselines; verifikationsdækning følges. | Verifikation er stærk i pipelinen; kompetenceudvikling er bevidst, og politik tilpasser sig løbende, efterhånden som værktøj og dokumentation ændrer sig organisationsdækkende. |
| Ansvarlig og troværdig AI | Ingen retfærdighedstest, forklaringer eller styring; ansvar udefineret; problemer findes først efter skade. | Noget biastest og dokumentation; ad hoc-tilsyn; kendskab til rammeværker, men delvis adoption. | Styring kortlagt til anerkendte rammeværker; systematisk retfærdigheds-/sikkerheds-/privatlivstest; dokumenteret tilsyn og klagemuligheder; red teaming. | Retfærdigheds-, sikkerheds- og privatlivsmålinger overvåges i produktion mod baselines og tærskler. | Styring er integreret i leveringen; ansvar er alles opgave, og tilgangen forbedres løbende på tværs af organisationen. |
| AI-infrastruktur og drift | Ad hoc GPU-allokering; ingen batching eller caching; ingen omkostningssynlighed; uversionerede prompts; minimal overvågning. | Noget fælles skemalægning og caching; grundlæggende omkostningssporing; prompts i versionsstyring; ad hoc-evaluering. | Fælles platform med skemalægning, kvoter, batching, caching, rigtig dimensionering; vektorinfrastruktur; automatiseret evaluering; omkostningstilskrivning. | Udnyttelse, omkostning pr. udfald og latens måles mod baselines; budgetter og kvoter håndhæves. | Routing og skalering er automatiserede, LLMOps-observerbarhed er fuld, og udnyttelse og omkostning optimeres løbende med bevaret portabilitet organisationsdækkende. |
Del 7. Data, analyse og indsigt
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Datastrategi og styring | Data udokumenteret og uejet; modstridende definitioner; kvalitet opdages, når rapporter går i stykker; intet katalog eller afstamning. | Nogle datasæt har ejere og dokumentation; et delvist katalog; manuelle, reaktive kvalitetstjek; politik skrevet, men svagt håndhævet. | Kritiske dataprodukter har ejere, kontrakter, SLA’er; katalog med automatiseret afstamning; kontinuerlig kvalitet; fødereret styring. | Datakvalitet, kontraktoverholdelse og friskhed måles mod SLA’er og baselines. | Data-som-produkt er normen; kontrakter håndhæves automatisk, selvbetjent rækværk tilpasser sig, og definitioner er betroede virksomhedsdækkende. |
| Dataingeniørarbejde | Ad hoc-scripts, manuelle kørsler, ingen tests eller overvågning; fejl opdages af forbrugere; omkostninger ustyrede. | Noget orkestrering og skemalægning; grundlæggende transformationer i versionsstyring; lejlighedsvise tests; reaktiv brandslukning. | ELT med lagdelte, testede, versionerede modeller; orkestrerede afhængigheder med genforsøg/efterfyldning; observerbarhed; omkostninger følges. | Pipelinepålidelighed, friskhed og omkostning måles mod SLA’er; anomalier opdages mod baselines. | Pipelines er software med CI/CD, kontrakter og test; platformen forbedres løbende, og nye dataprodukter leveres hurtigt organisationsdækkende. |
| Analyse og business intelligence | Rapporter bygget ad hoc i regneark; inkonsistente målinger; vildledende diagrammer; ingen styring. | Et BI-værktøj med nogle fælles dashboards; målingsdefinitioner afviger stadig; ukontrolleret selvbetjening og vildtvækst begynder. | Et semantisk lag definerer kernemålinger én gang; certificeret versus eksperimentelt indhold; selvbetjening inden for rækværk; styret livscyklus. | Målingsbrug, friskhed og definitionsændringer følges mod baselines; certificeret indhold overvåges. | Målinger styres som API’er med ejere og changelogs; analyse spænder fra deskriptiv til præskriptiv og indlejres i beslutningspunkter på tværs af organisationen. |
| Produktanalyse og eksperimentering | Lidt/inkonsistent instrumentering; beslutninger efter mening; ingen eksperimenter; forfængelighedsmålinger; skødesløst samtykke. | Nogle hændelser spores, men taksonomien er inkonsistent; lejlighedsvise A/B-tests uden styrkeanalyse; north star foreslået, ikke indlejret. | En styret, valideret sporingsplan; tragte/kohorter/fastholdelse er rutine; eksperimenter på en fælles platform; samtykke håndteret korrekt. | Eksperimentvolumen, styrke og gevinstrater måles mod baselines; instrumenteringsdækning følges. | Eksperimentering er standarden; et fælles resultatarkiv og ejet instrumentering lader organisationen lære kumulativt og tilpasse sig. |
| Beslutningsvidenskab og datakultur | Beslutninger efter hierarki og intuition; korrelation behandlet som kausalitet; usikkerhed ignoreret; målinger overvåger og manipuleres. | Data konsulteres selektivt for at retfærdiggøre beslutninger; noget bevidsthed om kausale fælder; usikkerhed kommunikeres sjældent. | Analyser knyttet til beslutninger med foruddefinerede kriterier; korrelation skelnet fra kausalitet; usikkerhed kommunikeret; udfaldsfokus. | Beslutningskvalitet og prognosekalibrering følges mod udfald og baselines. | “Hvad ville ændre vores mening?” er rutine; kausal stringens og ærlig usikkerhed er normer, og ledere opdaterer synligt på dokumentation organisationsdækkende. |
Del 8. Automatisering
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| CI/CD og levering | Builds og udrulninger for det meste manuelle og inkonsistente; sen integration; sjældne, stressende releases; manuel tilbagerulning. | Automatiserede builds og enhedstests pr. commit; scriptede, men manuelt overvågede udrulninger; artefakter kan genbygges pr. trin. | En standardiseret pipeline promoverer ét uforanderligt artefakt gennem miljøer med automatiserede porte; canary/blue-green; automatiske ændringsregistre. | DORA-målinger (ledetid, udrulningsfrekvens, ændringsfejlrate, MTTR) følges mod baselines og gater tilbagerulninger. | Progressiv levering afkobler release via flag; pipelinen forbedrer sig selv, og compliancedokumentation er automatisk på tværs af organisationen. |
| Infrastruktur som kode og konfiguration | Infrastruktur provisioneres manuelt; inkonsistente, udokumenterede miljøer; langsom, usikker genoprettelse. | Noget infrastruktur scriptet, men praksisser varierer; inkonsistent tilstand; almindelig afdrift; politik håndhævet ved manuel gennemgang. | Deklarativ IaC er standard fra fælles versionerede moduler med fjerntilstand; policy-as-code-rækværk; regelmæssig afdriftsdetektion. | Afdrift, provisioneringstid og politikovertrædelsesrater måles mod baselines; compliancedokumentation er automatisk. | Infrastruktur er uforanderlig, GitOps-drevet og selvhelende; modul- og politikbiblioteket forbedres løbende og tilpasser sig organisationsdækkende. |
| Containere, orkestrering, cloud-native | Containere brugt ad hoc; håndbyggede uscannede images; manuel udrulning; ingen fælles platform eller isolationsmodel. | Teams containeriserer og bruger en orkestrator, men praksisser varierer; inkonsistent scanning og grænser; ustyret omkostning og tenancy. | En standardiseret platform med hærdede images, signerings-/scanningsporte, namespace-tenancy med kvoter og netværkspolitik, omkostningsallokering. | Udnyttelse, tæthed og omkostning pr. arbejdsbelastning måles mod baselines; FinOps-optimering er datadrevet. | En selvbetjent, selvhelende platform med stærk multi-tenancy forbliver portabel og hybrid-/suverænitetsparat og forbedres løbende organisationsdækkende. |
| Platformsingeniørarbejde og DevEx | Ingen platform; hvert team samler sit eget værktøj inkonsistent; ticketdrevne overdragelser; høj kognitiv belastning. | Noget fælles værktøj og skabeloner, men fragmenteret og delvis manuelt; begrænset selvbetjening; DevEx umålt. | Et platformsteam driver golden paths, selvbetjent provisionering, en udviklerportal og scorekort; rækværk i asfalterede veje; DevEx målt. | Adoption, DevEx-scorer og signaler om kognitiv belastning måles mod baselines og gennemgås. | Et modent platformsprodukt forbedres løbende ud fra den feedback; frivillig adoption er høj, og styring forbliver usynlig i arbejdsgangen organisationsdækkende. |
| Test- og procesautomatisering | Test og drift for det meste manuel; inkonsistent dækning; procedurer i hoveder eller forældede dokumenter; compliancedokumentation i hånden. | Automatiserede tests findes, men langsomme/ustabile og kørt inkonsistent; nogle driftsscripts; manuel afhjælpning; periodisk gennemgangsstyring. | Hurtig, parallel, pålidelig testinfrastruktur; kodificerede runbooks; ChatOps; autogenereret compliancedokumentation; styring som automatiserede tjek. | Automatiseringsdækning, falsk-positiv-rater og afhjælpningstider måles mod baselines. | Rutinehændelser afhjælpes automatisk med sikkerhedsforanstaltninger; compliance er kontinuerlig og revisionsklar, og mennesker fokuserer på dømmekraft organisationsdækkende. |
Del 9. Drift, pålidelighed og observerbarhed
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Site reliability engineering | Drift manuel og reaktiv; ingen SLO’er; pålidelighed er mening; de samme hændelser vender tilbage; brandslukning dominerer. | Nøgletjenester har grundlæggende SLI’er/SLO’er; noget overvågning og alarmering; toil anerkendt, men umålt; inkonsistente postmortems. | Fejlbudgetter påvirker prioritering; toil måles og begrænses; rutinemæssig kapacitetsplanlægning; finansieret automatisering; PRR og engagementsmodel. | Fejlbudgetter, toil og SLO-opnåelse måles mod baselines og driver prioritering. | Fejlbudgetpolitik er automatiseret og respekteret; selvbetjent drift og proaktiv kapacitet lader organisationen afveje velocity og stabilitet på data og tilpasse sig. |
| Observerbarhed og overvågning | Grundlæggende oppetidstjek og ustrukturerede logs pr. maskine; fejlfinding betyder SSH; støjende, ignorerede alarmer. | Centraliserede målinger og logaggregering; nogle dashboards og tærskelalarmer; delvise/fraværende traces; manuel korrelation. | OpenTelemetry-instrumentering med propagerede trace-ID’er; strukturerede logs, tracing, kuraterede dashboards, SLO-symptomalarmering; bæredygtig vagt. | Alarmkvalitet, MTTD og telemetriomkostning måles mod baselines; forbrændingsratealarmering er tunet til SLO’er. | Observerbarhed med høj kardinalitet og hændelsesrigdom understøtter ad hoc-undersøgelse; opbevaring er omkostningsoptimeret, og telemetri informerer beslutninger på tværs af organisationen. |
| Hændelsesstyring | Hændelser håndteret ad hoc af den, der opdager dem; ingen roller, alvorligheder eller postmortems; uformel vagt; fejl vender tilbage. | Grundlæggende vagtrotationer og alvorligheder; nogle postmortems, men uklare roller og inkonsistent sporede korrigerende handlinger. | Et formelt hændelseskommandosystem med klare roller og kriterier; skyldfri postmortems er standard; handlinger følges; vagt kompenseres. | Hændelsesfrekvens, MTTR og vagtbelastning måles mod baselines; tilbagevendende årsager trendes. | Respons indøves via game days; vagt forbliver bæredygtig og stille, og samlet analyse driver strukturel investering, efterhånden som organisationen lærer. |
| Omkostning, bæredygtighed, grøn software | Cloudomkostninger er en månedlig overraskelse; ingen mærkning, allokering eller CO2-bevidsthed; rigelig, urevideret provisionering. | Grundlæggende omkostningssynlighed og mærkning; noget reaktiv rigtig dimensionering og oprydning af ledige ressourcer; bæredygtighed anerkendt, men umålt. | En FinOps-praksis med tilskrivning, budgetter, prognoser, anomalialarmer, forpligtelser, rigtig dimensionering; CO2 målt for større tjenester. | Omkostning og CO2 måles pr. team mod budgetter og baselines; anomalier flagges. | Omkostning og CO2 er kontinuerlige, teamejede signaler; effektive standarder, automatiseret optimering og CO2-bevidst skemalægning forbedres løbende organisationsdækkende. |
Del 10. Projekt-, produkt- og programstyring
| Emne | Niveau 1 Opstart | Niveau 2 Udvikling | Niveau 3 Standardisering | Niveau 4 Styring | Niveau 5 Orkestrering |
|---|---|---|---|---|---|
| Portefølje- og programstyring | Prioriteter sat ad hoc af den, der beder højest; intet porteføljeoverblik; afhængigheder dukker op som kriser; årlige finansieringskampe. | En periodisk gennemgået porteføljeopgørelse; offentliggjorte mål svagt koblet til arbejdet; et afhængighedsregister; projektbaseret budgettering. | Strategi kaskaderer via OKR’er; en ensartet prioriteringsramme; planlægning på tværs af teams styrer afhængigheder; vedvarende teamfinansiering. | Porteføljeudfald, leveringsforudsigelighed og afhængighedsantal måles mod baselines. | Porteføljen rebalanceres løbende på udfaldsdokumentation; afhængigheder designes væk, og finansieringskadencen matcher læringskadencen organisationsdækkende. |
| Risiko, revision og assurance | Risiko håndteres reaktivt efter hændelser; ingen ramme eller register; udokumenterede kontroller; smertefulde manuelle revisioner. | Risikoregistre for større systemer; en kontrolramme adopteret, revisioner bestås, men manuelle og øjebliksbaserede; leverandører vurderet ved onboarding. | Tre-forsvarslinjer-model og fælles ramme organisationsdækkende; mange kontroller automatiseret; kontinuerlig overvågning; leverandør-/SBOM-opgørelser; planlagt DR. | Kontroleffektivitet, antal åbne risici og revisionsfund måles mod risikoappetit og baselines. | Assurance er kontinuerlig og i vid udstrækning automatiseret; revisorer udtager stikprøver af levende dokumentation, og forsyningskædeintegritet verificeres, efterhånden som risici udvikler sig organisationsdækkende. |
| Indkøb, open source, licenser | Open source tilføjes frit; ingen politik eller opgørelse; licenser uundersøgte; end-of-life opdages ved et tilfælde; ingen ejer. | En grundlæggende politik og godkendt licensliste; noget manuel/sen scanning; en opgørelse for større systemer; ad hoc-bidrag. | Et OSPO ejer strategi og værktøj; automatiseret licens-/sårbarhedsscanning og tilskrivning; SBOM’er; klart bidrag; EOL følges. | Licensoverholdelse, afhængighedsaktualitet og sårbarhedseksponering måles mod baselines. | Open source er et styret strategisk aktiv med fuldt automatiseret compliance; upstream-investering er bevidst, og aktualitet og EOL styres løbende organisationsdækkende. |
| Vedligeholdelse af store og langlivede systemer | Systemer afhænger af helte; ejerskab ud fra hukommelse; udokumenteret viden; systemer frosne, til de går i stykker; udfasninger afsluttes aldrig. | Ejerskab tildelt og registreret for større systemer; noget dokumentation og runbooks; åbenlyst kritiske funktioner har en reserveperson; reaktiv vedligeholdelse. | Ejerskab på teamniveau i et katalog, der overlever omorganiseringer; bus factor målt og afbødet; beslutningsregistre og runbooks; trinvis modernisering. | Bus factor, ejerskabsdækning og videnoverførselsfremskridt måles mod baselines. | Forvaltning er en finansieret disciplin; intet kritisk system er et enkelt menneskeligt fejlpunkt, og videnoverførsel og planlagte afslutninger fortsætter organisationsdækkende. |
| Etik, ansvarlighed, almenvellet | Etik uadresseret eller reaktiv efter skandale; tilgængelighed ignoreret; uigennemsigtige automatiserede beslutninger uden mulighed for klage; bias utestet. | En adfærdskodeks og noget (sen) tilgængelighed; højprofilerede automatiserede beslutninger får noget tilsyn; lejlighedsvise biastjek. | Etisk gennemgang er en del af processen; tilgængelighed designet ind og brugertestet; afgørende beslutninger bærer forklaring og klagemulighed. | Lighed, tilgængelighed og algoritmisk ansvarlighed overvåges mod baselines. | Ansvar er indlejret i, hvordan organisationen bygger; lighed er en ufravigelig standard, og algoritmisk ansvarlighed er standard og forbedres løbende organisationsdækkende. |
Samlet selvvurdering af modenhed
Brug matricerne ovenfor til at frembringe en let, ærlig score.
Scoringsrubrik
- Score hvert kapitel fra 1 til 5 ved hjælp af det niveau, hvis beskrivelse bedst matcher jeres typiske virkelighed. Når adfærd er inkonsistent, så score det lavere niveau.
- Beregn gennemsnit pr. del. Læg kapitelscorerne i en del sammen, og dividér med antallet af kapitler. Det giver en modenhed pr. del (f.eks. “Del IV har et gennemsnit på 2,5”).
- Registrér minimum, ikke blot gennemsnittet. En del, der har et gennemsnit på 3,0, men indeholder et niveau 1-kapitel, bærer det kapitels risiko uanset gennemsnittet.
- Afbild trenden. Scor igen hvert kvartal eller hvert andet, og se bevægelsesretningen. Et domæne, der bevæger sig 2 → 3, er sundere end et, der sidder fast på et statisk 3.
Et simpelt regneark pr. del:
| Del | Kapitler scoret | Gennemsnit (middel) | Laveste kapitel | Noter / prioritet |
|---|---|---|---|---|
| I-X | antal | middel | laveste niveau | … |
Prioritering af, hvad der skal forbedres
Prøv ikke at løfte alt på én gang, og jag ikke det højeste gennemsnit. Prioritér efter risikovægtet modenhedshul: angrib de domæner, hvor et lavt niveau møder høj konsekvens.
- Først: de kapitler med lavest modenhed i jeres højest risikobelagte domæner. For de fleste organisationer betyder det sikkerhed, privatliv, pålidelighed, compliance og ethvert system, hvis svigt skader mennesker eller overtræder loven. Et niveau 1 her er akut.
- Dernæst: grundlæggende muliggørere (kultur, arbejdsformer, CI/CD, IaC, observerbarhed), der hæver loftet for alle andre domæner. At forbedre disse gør senere gevinster billigere.
- Senere: domæner, der allerede er på niveau 3 og kunne klatre til niveau 4 eller 5. Skub kun ud over bunden, hvor indsats og skala retfærdiggør den ekstra investering.
Baseline for virksomheder og det offentlige
Virksomheds- og offentlige sammenhænge kan som regel ikke stoppe ved “det virker.” For at bestå revisioner, opretholde tilladelser og opfylde regulatoriske og offentlige ansvarlighedsforpligtelser må de fleste domæner nå mindst niveau 3 (Standardisering), det niveau, hvor praksisser er standardiserede, dokumenterede, håndhævet på tværs af teams og producerer dokumentation. Niveau 2 fejler typisk en revision, fordi det er inkonsistent og manuelt samlet under deadline; niveau 1 fejler direkte.
Læs niveau 3 som bunden for alt, der er revisionsbart eller sikkerhedsrelevant, og de højere niveauer (4 og 5) som mål kun, hvor kontinuerlig assurance, skala eller offentlig tillid gør den ekstra stringens umagen værd. Modenhed forbliver et middel: målet er et forsvarligt, proportionalt kontrolniveau for den risiko, I faktisk bærer, ikke en perfekt score.