12.4
12.4 Mognadsbedömning
Varje kapitel i den här boken avslutas med en “Mognadsmodell” som beskriver hur en praxis typiskt utvecklas. Den här bilagan samlar varje kapitels mognadsmodell i en enda referens så att ni kan bedöma ett team, en domän eller en hel organisation med en blick.
Den gemensamma femnivåskalan
Alla kapitel beskriver samma progression. Den exakta formuleringen varierar något mellan kapitel, men avsikten kartläggs rent mot dessa fem nivåer:
- Nivå 1, Initiera. Ad hoc, reaktiv och personlighetsdriven. Praxis finns bara där en individ väljer den, så utfallen beror på hjältedåd och tur.
- Nivå 2, Utveckla. Grundläggande praxis finns, men den är inkonsekvent över team, delvis manuell och ofta förbigången under press.
- Nivå 3, Standardisera. Praxis är dokumenterad, standardiserad och upprätthållen i hela organisationen. Detta är golvet för revision och efterlevnad: den nivå de flesta företags- och myndighetsarbeten måste nå för att vara pålitliga och granskningsbara.
- Nivå 4, Hantera. Praxis mäts och styrs med data och mått mot utgångslägen. Ni vet kvantitativt hur varje praxis presterar, och ni agerar på talen.
- Nivå 5, Orkestrera. Praxis förbättras kontinuerligt, är integrerad i hela organisationen och adaptiv. Den säkra eller korrekta vägen är standard, och organisationen lär sig och utvecklas medvetet.
Så använder ni den för självbedömning
- För varje kapitel som är relevant för ert sammanhang, läs de fem cellerna nedan och välj den nivå som ärligt beskriver ert typiska beteende, inte ert bästa team en bra dag och inte er skrivna policy, utan det som faktiskt sker.
- Poängsätt varje kapitel 1 till 5. Avrunda nedåt vid tvekan. En praxis som är inkonsekvent är nivå 2, inte nivå 3.
- Medelvärdesbilda poängen inom en del för att se var en hel domän står, och titta sedan på spridningen: en del på “3 i snitt” som döljer ett kapitel på nivå 1 har fortfarande en nivå 1-risk.
- Bedöm om periodvis och följ trenden. Rörelse betyder mer än någon enskild ögonblicksbild.
Mognad är ett medel, inte ett mål
Högre mognad är inte automatiskt bättre. Målet är passform: tillräcklig stringens för att hantera den risk och skala ni faktiskt möter, och inte mer. Ett litet verktyg med låga insatser behöver inte kaosteknik på nivå 5. Att sträcka sig efter en hög nivå som en trofé, snarare än för att lösa ett verkligt problem, ger ceremoni utan värde. Läs varje “Nivå 5” nedan som “lämplig när insatserna motiverar det”, och låt risk, skala och regulatorisk exponering avgöra hur långt ni klättrar.
Del 1. Människor
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Ingenjörskultur och värderingar | Kulturen är tillfällig och personlighetsdriven. Incidenter betyder skuldbeläggning. Kunskap bor i några få huvuden. | Vissa team kör efterhandsgranskningar och skriver dokument, men praxisen är inkonsekvent och inte förstärkt av ledningen. | Skuldfritt lärande, ägarskapsmodeller och en skrivkultur är organisationsnormer med tydliga förväntningar och verktyg. | Kulturens hälsa mäts (enkäter om psykologisk trygghet, incidentlärandegrad, personalbehållning) och följs mot utgångslägen och agerar på. | Kulturen förbättras kontinuerligt och praxis sprids mellan team. Ledningen anpassar normer när organisationen växer och lär sig. |
| Teamtopologier | Team bildas av en slump eller efter antal anställda. Strukturen speglar den äldre hierarkin. Beroenden överallt. | Vissa strömlinjerade team finns, men delade flaskhalsar och funktionella silor består. | De fyra teamtyperna och uttryckliga interaktionslägen används medvetet. Plattformar och InnerSource skär ned beroenden. | Kognitiv belastning, flöde och antal beroenden mäts per team mot mål. Gränser justeras när talen sviktar. | Organisationen formar kontinuerligt om team och interaktionslägen för att vidmakthålla flöde när produkter och plattformar utvecklas. |
| Roller, karriärstegar, utveckling | Ingen skriven stege. Befordringar och lön är ad hoc och personlighetsdrivna. | En grundläggande stege finns men tillämpas inkonsekvent. Ingen kalibrering. Rekrytering är ostrukturerad. | Dubbla spår, en tydlig kompetensmatris, kalibrering och strukturerad rekrytering är standard. | Progressionstakt, löneskillnader och tid på nivå mäts mot utgångslägen. Kalibreringsutfall analyseras för bias. | Ramverket utvecklas kontinuerligt med arbetet. Sponsring och lärlingskap är medvetna och organisationsövergripande när roller förändras. |
| Arbetssätt | Processen är ad hoc eller kargokult. Kommunikationen är mötesdriven och odokumenterad. Estimat behandlas som löften. | En metodik följs konsekvent, men ceremonier är mekaniska och samordning över team är tung. | Praxis väljs för att passa sammanhanget. Asynkron, dokumentförst-kommunikation är normen. Uppskattning informerar, styr inte. | Flödesmått (ledtid, pågående arbete, genomströmning) följs mot utgångslägen och granskas varje cykel. | Team trimmar kontinuerligt sitt arbetssätt utifrån dessa mått. Samordningsbehovet minimeras vid källan och god praxis sprids i hela organisationen. |
| Beslutsfattande och styrning | Beslut är ad hoc och oregistrerade. Styrning saknas eller är en generell flaskhals. Skuld är osynlig. | Vissa beslut är dokumenterade och viss granskning finns, men processen är inkonsekvent och inte anpassad till beslutets tyngd. | ADR, en upptrampad stig, reversibilitetsbaserad delegering och en skuldinventering är standard och transparenta. | Beslutscykeltid, omvändningsfrekvenser och skuldnivåer mäts. Granskning kalibreras efter beslutets tyngd mot dessa tal. | Styrning trimmas kontinuerligt i hela organisationen. Granskning riktas mot oåterkalleliga beslut. Skuld och sourcing hanteras som utvecklande portföljer. |
Del 2. Programmering
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Kodstandarder och stil | Stilen är per författare. Inga delade konfigurationer. Formatering diskuteras i granskning. | Varje team har en formaterare och en linter, men konfigurationer och regler varierar mellan team. | Centrala delade konfigurationer per språk. CI-upprätthållande. Nya förvar ärver standarder via mallar. | Standardadoption, överträdelsefrekvens och effekt på granskningstid mäts mot utgångslägen. Konfigurationer är versionshanterade och styrda. | Standarder förfinas kontinuerligt utifrån dessa data och delas i hela organisationen. Upprätthållandet är nästan friktionsfritt och anpassas till nya språk. |
| Principer för programvarudesign | Design är ad hoc. Koppling ackumuleras. Principer är okända eller åberopas som slagord. | Team känner principerna och tillämpar dem, men inkonsekvent och ofta dogmatiskt. | Delat designordförråd, medveten kopplings-/sammanhållningsanalys och avgränsade kontexter linjerade mot team. | Koppling, sammanhållning och ändringsmisslyckandemått informerar designgranskningar mot utgångslägen. Beslut registreras. | Designbeslut omprövas när belägg ackumuleras. Principer tillämpas med nyans och paradigmval anpassas i hela organisationen när domänen utvecklas. |
| API:er och gränssnittsdesign | API:er uppstår ur implementationen. Inga delade konventioner. Brytande ändringar är vanliga och oannonserade. | Team följer grundläggande REST-konventioner och versionshanterar informellt, men konsekvens och dokumentation varierar. | Kontraktsförst-design, maskinläsbara specifikationer, en utfasningspolicy och konsekventa konventioner för fel och paginering. | Adoption, latens, felfrekvens och frekvens av brytande ändringar mäts per API mot mål. | API:er är styrda produkter i en katalog med stark utvecklarupplevelse. Praxisen anpassas kontinuerligt och avbrott är sällsynta och väl hanterade i hela organisationen. |
| Teststrategi | Testning är manuell och ad hoc. Automatiserad täckning är minimal. Regressioner är frekventa. | Automatiserade enhetstester och vissa integrationstester finns, men sviten är långsam eller opålitlig och förtroendet är lågt. | En balanserad, snabb, pålitlig svit grindar varje ändring. Opålitlighet hanteras. Icke-funktionell testning är integrerad. | Täckning, opålitlighet, undsluppna defekter och svitens varaktighet följs mot utgångslägen för att rikta insats. | Avancerade tekniker (egenskaps-, mutations-, fuzz-) riktas mot högvärdig kod. Strategin förbättras kontinuerligt och sprids över team. |
| Kodgranskning och samarbete | Granskning är inkonsekvent eller överhoppad. Mekaniska frågor dominerar. Återkopplingsnormer är osatta. | Granskning krävs men är långsam och varierande. Automation är partiell. PR-storlek och kvalitet varierar kraftigt. | Små PR, automatiserade mekaniska kontroller, tydliga standarder och återkopplingsnormer samt övervakad latens. | Granskningslatens, PR-storlek och andel undsluppna defekter följs mot mål. Djupet matchas mot uppmätt risk. | Organisationen förbättrar kontinuerligt granskning utifrån dessa data. Parprogrammering och AI-stöd adopteras medvetet och praxis sprids mellan team. |
| Versionshantering och källkodshantering | Ad hoc-förgrening. Långlivade grenar. Dåliga meddelanden. Ingen hemlighetsskanning. Frekvent sammanslagningssmärta. | En konsekvent förgreningsmodell och meddelandekonventioner finns, men grenar lever för länge och upprätthållandet är partiellt. | Trunk-baserad utveckling, skyddad huvudgren, upprätthållna incheckningskonventioner, hemlighetsskanning, medveten förvarsstruktur. | Grenens livslängd, sammanslagningsfrekvens och återställningsfrekvenser mäts mot leveransmått och utgångslägen. | Automation upprätthåller hygien från början till slut. Förvarsstruktur och arbetsflöde utvecklas kontinuerligt i organisationen när leveransbehov förändras. |
| Dokumentation | Dokumentation är gles, spridd och föråldrad. Kunskap bor i människors huvuden. | Nyckeldokument finns (README, vissa körböcker) men underhålls inkonsekvent och är svåra att hitta. | Dokument som kod med tydlig struktur, genererade API-dokument och ändringsloggar, beslutsloggar och uppdateringsförväntningar. | Dokumentationstäckning, färskhet och noggrannhet mäts mot utgångslägen. Föråldring flaggas automatiskt. | Dokument är levande, till stor del genererade eller testade mot systemet, ägda och sökbara. Praxisen förbättras kontinuerligt i hela organisationen. |
Del 3. System
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Arkitekturgrunder | Arkitekturen är implicit och bor i huvuden. Inga kvalitetsegenskaper eller ADR. Beslut dyker upp under incidenter. | Nyckeldiagram finns och större beslut registreras ibland. Kvalitetsegenskaper namnges men kvantifieras sällan. Dokument driver. | Kvalitetsegenskapsscenarier och ASR är specificerade. ADR är rutin. C4/arc42-dokument underhålls nära koden. Avvägningsgranskningar sker. | Anpassningsfunktioner upprätthåller kvalitetsegenskaper i CI och registrerar uppmätta resultat mot utgångslägen. Avvägningar kvantifieras. | Arkitekturen utvecklas kontinuerligt med dessa data i hela organisationen. Dokument förblir tillräckligt pålitliga för revisorer när systemet anpassas. |
| Arkitekturstilar och mönster | En trasslig monolit eller ett oavsiktligt distribuerat kaos. Gränser följer lager eller historia. Stil väljs efter mode. | Medveten modulär gränsdragning eller några grova tjänster. Vissa övergripande angelägenheter är konsekventa. Uppdelningar är fortfarande ad hoc. | Tjänster linjerade mot avgränsade kontexter som äger sina data. Gateway/BFF där det passar. Ren/hexagonal lagerindelning är standard. | Stilbeslut är belägg-baserade och använder uppmätt koppling, latens och ändringskostnad mot utgångslägen. | En mogen plattform gör distribution billig. Organisationen återkonsoliderar när en uppdelning slutar löna sig och anpassar stil när belägg förändras. |
| Distribuerade system | Fjärranrop behandlas som lokala. Inga/naiva omförsök. Fel kaskaderar. Felsökning är loggletande maskin för maskin. | Timeouter och grundläggande omförsök finns men är inkonsekventa. Viss idempotens. Loggar är centraliserade men okorrelerade. | Idempotens, backoff, kretsbrytare och skott via delade bibliotek. Sagor. Distribuerad spårning. Dokumenterad konsistens per flöde. | Motståndskraft mäts mot SLO:er. Resultat från felinjektion och felfrekvenser följs mot utgångslägen. | Motståndskraft är plattformens standard, kontinuerligt testad med felinjektion. Elegant degradering är inbyggd och utvecklas i hela organisationen. |
| Dataarkitektur och lagring | En databas för alla ändamål. Ingen migreringsdisciplin. Tillfällig cachning. Skala med en större maskin. | Lagringsval är mestadels medvetna. En cache och kanske ett lager. Versionshanterade migreringar kräver ibland driftstopp. | Polyglot persistens matchad mot arbetslaster, varje lager ägt. Automatiserade migreringar utan driftstopp. Uttrycklig cachning och repliker. | Lagringsval mäts mot åtkomstmönster, latens och kostnadsutgångslägen. Beslut om sharding och cachning är datadrivna. | Dataarkitekturen granskas och utvecklas kontinuerligt i hela organisationen. Migreringar är automatiserade och granskade när arbetslaster förändras. |
| Skalbarhet, prestanda, motståndskraft | En instans eller vertikalt skalad. Tillstånd på serversidan. Ingen belastningstestning eller budgetar. Fel orsakar fullständiga avbrott. | Horisontellt skalade tillståndslösa nivåer. Grundläggande automatisk skalning. Viss belastningstestning före lansering. DR dokumenterad men sällan testad. | Kapacitet planeras med marginal. Prestandabudgetar i CI. Motståndskraftsmönster är standard. RTO/RPO definierade och DR testad. | Kapacitet prognostiseras från uppmätt last. Prestandabudgetar och RTO/RPO följs mot utgångslägen. | Automatisk redundansväxling över flera regioner, kontinuerligt kaos och spelövningar bevisar och förbättrar återställningsmål när systemet utvecklas i hela organisationen. |
| Modernisering av äldre system | Äldre system fruktas och fryses. Ingen inventering. Modernisering är allt-eller-inget-omskrivning. Kunskap i pensionerade huvuden. | En inventering finns och viss risk förstås. Äldre system lindas in med API:er. Fortfarande big bang-tänkande. Migrering underskattas. | System prioriteras efter risk och värde. Kvävarfikon och gren-via-abstraktion är standard. Migrering avstäms med parallellkörning. | Modernisering portföljstyrs med uppmätt risk, värde och framsteg mot utgångslägen. | Modernisering är kontinuerlig i hela organisationen. Stegvis ersättning är rutin, reversibel och anpassas när prioriteringar skiftar. |
Del 4. Säkerhet
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Säkerhetsgrunder och kultur | Säkerhet är reaktiv och centraliserad. Granskningar kommer sent om alls. Ingen hotmodellering. Säkerhet är “någon annans problem.” | Ett säkerhetsteam definierar standarder. Viss hotmodellering på större projekt. Grundläggande utbildning. Säkerhet ses som en grind. | Säkerhetsambassadörer inbäddade. Hotmodellering är rutin. Säker SDLC dokumenterad. Riskbaserad prioritering. Skuldfria granskningar. | Säkerhetsmått (täckning av hotmodellering, tid från fynd till rättelse, kontrolladoption) följs mot utgångslägen. | Säkerhet är genuint allas jobb. Hotmodellering är en vana. Nolltillit är till stor del realiserad och praxisen förbättras kontinuerligt i hela organisationen. |
| Applikationssäkerhet | Säkerhet beror på individuell kunskap. Inga standardkontroller. Hemligheter i kod. Föråldrade beroenden. Ad hoc-autentisering. | Medvetenhet om OWASP Top 10. Vissa ramverksskydd. Hemlighetshanterare ojämnt använd. Enstaka beroendeskanning. | ASVS-baserade krav per nivå. Parametriserade frågor. Central identitet med MFA. Hanterade hemligheter. SBOM och flödesskanning. | Sårbarhetstäthet, genomsnittlig tid till åtgärd och kontrolltäckning mäts mot utgångslägen över tjänster. | Säkra standardval levereras i ramverk på upptrampad stig. Kortlivade inloggningsuppgifter och full leveranskedjegaranti (SLSA) verifieras kontinuerligt i hela organisationen. |
| Infrastruktur- och molnsäkerhet | Manuell provisionering. Breda behörigheter och statiska nycklar. Platta nätverk. Inkonsekvent kryptering. Ingen lägeshantering. | Vissa IAM-roller och MFA. Grundläggande nätverksnivåer. Kryptering i vila för större lager. Periodiska manuella granskningar. Partiell IaC. | RBAC/ABAC med minsta behörighet och kortlivade uppgifter. Segmentering med förbjud som standard. Kryptering som standard med KMS. CSPM med policy. | Läge, drift och policyöverträdelsemått följs mot utgångslägen. Skyddsräckens effektivitet mäts. | Säkra standardval levereras i landningszoner och IaC. Mikrosegmentering och förebyggande skyddsräcken utvecklas kontinuerligt och drift åtgärdas automatiskt i hela organisationen. |
| Säkerhetsoperationer | Säkerhetstestning manuell och sällsynt. Ingen central loggning eller SIEM. Ingen incidentplan. Ad hoc-lappning. Aldrig testad mot en motståndare. | Vissa skannrar i flödet. Central loggning. En grundläggande incidentplan. Lösa lappningstidslinjer. Årlig pentest. | Full DevSecOps-skanning med riskbaserade grindar. SIEM med viss SOAR. Repeterad IR med bordsövningar. Åtgärds-SLA:er. Red team-övningar. | MTTD och MTTR mäts mot utgångslägen. Detekteringstäckning kartläggs mot motståndartekniker och följs. | Testning och respons är högt automatiserade. Purple team och detekteringsingenjörskap förbättras kontinuerligt och anpassas till nya hot i hela organisationen. |
| Integritet och dataskydd | Personuppgifter samlas fritt. Ingen inventering, minimering eller lagring. Samtycke en eftertanke. Ingen process för rättigheter. | En integritetspolicy och grundläggande samtycke finns. Viss medvetenhet om lagring. Rättighetsbegäranden hanteras manuellt och långsamt. | Inbyggt dataskydd med DPIA. Data kartlagd och klassificerad. Lagring upprätthålls. Rättslig grund dokumenterad. Rättigheter uppfylls inom frist. | Integritetsläget mäts: täckning av datainventering, lagringsefterlevnad och handläggningstid för rättighetsbegäranden mot utgångslägen. | Integritet är en ingenjörsbegränsning som standard. Minimering och automatiserad lagring är standard. Rättighetsbegäranden är självbetjäning och praxisen anpassas i hela organisationen. |
| Efterlevnad och styrning | Efterlevnad är reaktiv. Inget kontrollramverk. Belägg sammanställs manuellt under tidspress. Frekventa fynd. | Nyckelramverk identifierade. Vissa dokumenterade kontroller. Revisioner klaras med tungt manuellt arbete. Tillgänglighet beaktas sent. | Ett enhetligt kontrollramverk korsmappar standarder. Belägg delvis automatiserade. Tillgänglighet testad. Register och godkännanden etablerade. | Kontrolleffektivitet och beläggtäckning mäts kontinuerligt mot utgångslägen. Fynd trendas. | Efterlevnad är kontinuerlig med alltid-på-belägg och efterlevnad som kod. Nya certifieringar är billiga och ramverket anpassas i hela organisationen, revisionsklart när som helst. |
Del 5. UI/UX-design
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| UX-grunder | Ingen dedikerad UX-praxis. Beslut efter åsikt. Research ad hoc. Inkonsekventa flöden och terminologi. | Några designers och enstaka användbarhetstestning. Personor ej underhållna. UX är en fas, ofta förbigången. | Kontinuerlig blandmetodsresearch matar prioritering. Delade personor, resekartor och IA. UX-kvalitetsgrindar i definitionen av klart. | UX-mått (uppgiftsframgång, nöjdhet, användbarhetspoäng) följs mot utgångslägen vid sidan av affärsmått. | Research är kontinuerlig och utfallskopplad. Kontrollerade experiment sluter loopen och insikter sprids över team när produkter utvecklas. |
| UI-design och designsystem | Varje team bygger sitt eget UI. Inga delade komponenter. Inkonsekvent utseende. Hårdkodade färger och avstånd. | En partiell stilguide eller komponentbibliotek finns men är valfritt och ofta osynkroniserat mellan design och kod. | Ett tokeniserat designsystem med ett underhållet kodat bibliotek, dokumentation och styrning används över team. Tillgänglighet inbyggd. | Paritet mellan design och kod, komponentadoption och drift mäts mot utgångslägen. Versionshantering följs. | Systemet är en styrd produkt med en färdplan. Det förbättras kontinuerligt i hela organisationen och omprofileringar blir tokenändringar. |
| Tillgänglighet | Ingen tillgänglighetspraxis. Problem hittas via klagomål eller stämning. Icke-semantisk, otestad uppmärkning. | Medvetenhet finns. Viss automatiserad skanning och en granskning före lansering. Tillgänglighet är en sen checklista, ofta nedprioriterad. | WCAG 2.2 AA är standard. Tillgänglighet inbyggd i designsystemet, testad och i definitionen av klart. Team utbildade med en ägare. | Tillgänglighetsefterlevnad mäts i CI mot WCAG-utgångslägen. Defektfrekvenser och revisionsresultat följs. | Tillgänglighet är kontinuerlig. Personer med funktionsnedsättning involveras i research. Den är inbäddad i upphandling, tokens och CI och förbättras i hela organisationen. |
| Innehålls- och kommunikationsdesign | Ingen innehållspraxis. Ord skrivs ad hoc. Inkonsekvent terminologi och ton. Ohjälpsamma fel och tomma tillstånd. | En stilguide kan finnas. Viss medvetenhet om klarspråk. Innehåll är fortfarande sent i processen och per team med lite återanvändning. | En innehållsstrategi, röst-och-ton-guide och ordlista används över team. Klarspråk är standard. Delade mönster. | Innehåll mäts mot utfall (förståelse, uppgiftsslutförande, felfrekvens) mot utgångslägen. | Innehåll förbättras kontinuerligt utifrån det beläggen. Mörka mönster är förbjudna och granskas. Mönster är lokaliserade och tillgängliga som standard i hela organisationen. |
| Internationalisering och lokalisering | Ett språk. Hårdkodade strängar. Icke-Unicode-antaganden. Nya lokaler kräver kodändringar. | Strängar externaliserade och Unicode används, men lokalisering är en manuell sats före lansering. Formatering och pluralformer inkonsekventa. | Delad i18n-arkitektur och lokalmedveten formatering. Ett översättningshanteringssystem och kontinuerligt flöde. Pseudolokalisering och CI för flera lokaler. | Lokaliseringstäckning, strängfärskhet och lokaldefektfrekvens mäts mot utgångslägen. | i18n upprätthålls av verktyg och lint över team. Lokalisering är kontinuerlig, kulturell anpassning är systematisk och nya lokaler lanseras fort. |
| Frontend-teknik | Ad hoc-frontend per team. Tung klientkod. Inga budgetar. Testad bara på teamets enheter. Ramverk efter hype. | Vissa delade verktyg och ett komponentbibliotek. Prestanda mäts ibland, inte budgeterad. Begränsad testning över enheter. | Ramverk och renderingsstrategi väljs medvetet per yta. Budgetar upprätthålls i CI med RUM. Progressiv förbättring är standard. | Prestanda, motståndskraft och räckvidd mäts mot verkliga användarutgångslägen och budgetar. Regressioner fäller bygget. | Dessa signaler knyts till utfall och förbättras kontinuerligt över ytor när frontend och dess användare utvecklas. |
Del 6. Artificiell intelligens
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| AI-strategi och beredskap | Ad hoc-experiment. Ingen gemensam strategi. Beslut drivna av hype och individuell entusiasm. | Problemramning i vissa projekt. En första plattformsbaslinje. Bygga-mot-köpa diskuteras men inkonsekvent. | En portfölj av användningsfall med tydliga mått, ett beslutsträd, beredskapsbedömningar och analys av inlåsning/TCO. | Användningsfalls värde, adoption och beredskap mäts mot utgångslägen. Portföljens ROI följs. | AI-strategin är integrerad med verksamhets- och riskplanering. Beredskap vidmakthålls kontinuerligt och system avgränsas om på belägg i hela organisationen. |
| MLOps | Modeller byggs ad hoc i anteckningsböcker. Manuell driftsättning. Ingen data-/modellversionering. Ingen övervakning. | Viss experimentspårning och ett modellregister. Halvautomatiserad driftsättning. Grundläggande övervakning för några modeller. | Delad plattform med feature store, register, reproducerbara flöden, ursprung. Drift-/kvalitetsövervakning. Styrd befordran. | Modellkvalitet, drift och affärspåverkan mäts mot utgångslägen. Omträning utlöses vid trösklar med grindar. | Livscykeln är helt automatiserad och granskningsbar. Självbetjäning på upptrampade stigar och kontinuerlig utvärdering förbättrar modeller i hela organisationen när data skiftar. |
| Generativ AI och LLM-applikationer | Ad hoc-prompting i isolerade projekt. Ingen förankring, inga skyddsräcken eller utvärdering. Hallucinationer upptäcks i produktion. | Viss RAG och promptversionering. Grundläggande utdatavalidering. En liten manuell utvärderingsmängd. | Delade mönster för RAG, skyddsräcken och verktygsanvändning. Automatiserad offlineutvärdering vid varje ändring. Onlinemått och mänsklig granskning. | Offline- och onlineutvärderingspoäng, hallucinations- och injektionsfrekvenser mäts mot utgångslägen. | Utvärdering knyts till utfall och förbättras kontinuerligt. Injektionsförsvar, styrda observerbara agenter och mildring anpassas i hela organisationen. |
| AI-stödd programvaruutveckling | Individer använder assistenter ad hoc. Ingen policy. Ingen mätning. Hemligheter och immateriella rättigheter i riskzonen. | Grundläggande användningsvägledning och dataregler. Viss säkerhetsskanning. Anekdotiska produktivitetspåståenden. | Tydliga normer efter risknivå. Obligatorisk granskning och skanning. Ärliga utfallsmått. Säker driftsättning och redovisning. | Assistansens påverkan på leverans och kvalitet mäts mot utgångslägen. Verifieringstäckning följs. | Verifiering är stark i flödet. Kompetensutveckling är medveten och policyn anpassas kontinuerligt när verktyg och belägg förändras i hela organisationen. |
| Ansvarsfull och pålitlig AI | Ingen rättvisetestning, förklaringar eller styrning. Ansvar odefinierat. Problem hittas först efter skada. | Viss biastestning och dokumentation. Ad hoc-tillsyn. Medvetenhet om ramverk men partiell adoption. | Styrning kartlagd mot erkända ramverk. Systematisk rättvise-/säkerhets-/integritetstestning. Dokumenterad tillsyn och överklaganden. Red team-övningar. | Rättvise-, säkerhets- och integritetsmått övervakas i produktion mot utgångslägen och trösklar. | Styrning är integrerad i leveransen. Ansvar är allas jobb och tillvägagångssättet förbättras kontinuerligt i organisationen. |
| AI-infrastruktur och drift | Ad hoc-allokering av GPU. Ingen batchning eller cachning. Ingen kostnadssynlighet. Icke-versionshanterade promptar. Minimal övervakning. | Viss delad schemaläggning och cachning. Grundläggande kostnadsuppföljning. Promptar i versionshantering. Ad hoc-utvärdering. | Delad plattform med schemaläggning, kvoter, batchning, cachning, rätt dimensionering. Vektorinfrastruktur. Automatiserad utvärdering. Kostnadsattribuering. | Utnyttjande, kostnad per utfall och latens mäts mot utgångslägen. Budgetar och kvoter upprätthålls. | Routing och skalning är automatiserade, LLMOps-observerbarhet är full och utnyttjande och kostnad optimeras kontinuerligt med bibehållen portabilitet i hela organisationen. |
Del 7. Data, analys och insikt
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Datastrategi och datastyrning | Data odokumenterad och oägd. Motstridiga definitioner. Kvalitet upptäcks när rapporter går sönder. Ingen katalog eller ursprung. | Vissa datamängder har ägare och dokumentation. En partiell katalog. Manuella, reaktiva kvalitetskontroller. Policy skriven men svagt upprätthållen. | Kritiska dataprodukter har ägare, kontrakt, SLA:er. Katalog med automatiskt ursprung. Kontinuerlig kvalitet. Federerad styrning. | Datakvalitet, kontraktsefterlevnad och färskhet mäts mot SLA:er och utgångslägen. | Data som produkt är normen. Kontrakt upprätthålls automatiskt, självbetjäningsskyddsräcken anpassas och definitioner är betrodda i hela företaget. |
| Datateknik | Ad hoc-skript, manuella körningar, inga tester eller övervakning. Fel upptäcks av konsumenter. Kostnader ohanterade. | Viss orkestrering och schemaläggning. Grundläggande transformationer i versionshantering. Enstaka tester. Reaktiv brandkårsutryckning. | ELT med lagerindelade, testade, versionshanterade modeller. Orkestrerade beroenden med omförsök/efterfyllnad. Observerbarhet. Kostnader följs. | Pipelinens tillförlitlighet, färskhet och kostnad mäts mot SLA:er. Avvikelser upptäcks mot utgångslägen. | Pipelines är programvara med CI/CD, kontrakt och testning. Plattformen förbättras kontinuerligt och nya dataprodukter levereras fort i hela organisationen. |
| Analys och affärsanalys | Rapporter byggs ad hoc i kalkylblad. Inkonsekventa mått. Vilseledande diagram. Ingen styrning. | Ett BI-verktyg med några delade paneler. Måttdefinitioner divergerar fortfarande. Okontrollerad självbetjäning och vildväxt börjar. | Ett semantiskt lager definierar kärnmått en gång. Certifierat mot experimentellt innehåll. Självbetjäning inom skyddsräcken. Hanterad livscykel. | Måttanvändning, färskhet och definitionsändringar följs mot utgångslägen. Certifierat innehåll övervakas. | Mått styrs som API:er med ägare och ändringsloggar. Analys sträcker sig från beskrivande till föreskrivande och bäddas in vid beslutspunkter i organisationen. |
| Produktanalys och experimentering | Lite/inkonsekvent instrumentering. Beslut efter åsikt. Inga experiment. Fåfängemått. Slarvigt samtycke. | Vissa händelser följs men taxonomin är inkonsekvent. Enstaka A/B-tester utan styrkeanalys. Ledstjärnemått föreslaget, inte förankrat. | En styrd, validerad spårningsplan. Trattar/kohorter/bibehållande är rutin. Experiment på en delad plattform. Samtycke hanteras korrekt. | Experimentvolym, styrka och vinstfrekvens mäts mot utgångslägen. Instrumenteringstäckning följs. | Experimentering är standard. Ett delat resultatförvar och ägd instrumentering låter organisationen lära kumulativt och anpassa sig. |
| Beslutsvetenskap och datakultur | Beslut genom hierarki och intuition. Korrelation behandlas som kausalitet. Osäkerhet ignoreras. Mått övervakar och manipuleras. | Data konsulteras selektivt för att motivera beslut. Viss medvetenhet om kausala fällor. Osäkerhet kommuniceras sällan. | Analyser knyts till beslut med fördefinierade kriterier. Korrelation skiljs från kausalitet. Osäkerhet kommuniceras. Utfallsfokus. | Beslutskvalitet och prognoskalibrering följs mot utfall och utgångslägen. | “Vad skulle få oss att ändra oss?” är rutin. Kausal stringens och ärlig osäkerhet är normer och ledare uppdaterar synligt på belägg i hela organisationen. |
Del 8. Automation
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| CI/CD och leverans | Byggen och driftsättningar till stor del manuella och inkonsekventa. Sen integrering. Sällsynta, stressiga releaser. Manuell återställning. | Automatiserade byggen och enhetstester per incheckning. Skriptade men manuellt övervakade driftsättningar. Artefakter kan byggas om per steg. | Ett standardiserat flöde befordrar en oföränderlig artefakt genom miljöer med automatiserade grindar. Kanarie/blågrön. Automatiska ändringsregister. | DORA-mått (ledtid, driftsättningsfrekvens, ändringsmisslyckandefrekvens, MTTR) följs mot utgångslägen och styr återställningar. | Progressiv leverans frikopplar release via flaggor. Flödet förbättrar sig självt och efterlevnadsbelägg är automatiska i hela organisationen. |
| Infrastruktur som kod och konfiguration | Infrastruktur provisioneras manuellt. Inkonsekventa, odokumenterade miljöer. Långsam, osäker återställning. | Viss infrastruktur skriptad, men praxis varierar. Inkonsekvent tillstånd. Vanlig drift. Policy upprätthålls genom manuell granskning. | Deklarativ IaC är standard från delade versionshanterade moduler med fjärrtillstånd. Policy-som-kod-skyddsräcken. Regelbunden driftdetektering. | Drift, provisioneringstid och policyöverträdelsefrekvenser mäts mot utgångslägen. Efterlevnadsbelägg är automatiska. | Infrastruktur är oföränderlig, GitOps-driven och självläkande. Modul- och policybiblioteket förbättras kontinuerligt och anpassas i hela organisationen. |
| Containrar, orkestrering, molnnativt | Containrar används ad hoc. Handbyggda oskannade avbildningar. Manuell driftsättning. Ingen delad plattform eller isoleringsmodell. | Team containeriserar och använder en orkestrerare, men praxis varierar. Inkonsekvent skanning och gränser. Ostyrd kostnad och multitenans. | En standardiserad plattform med härdade avbildningar, signerings-/skanningsgrindar, namnrymdsmultitenans med kvoter och nätverkspolicy, kostnadsallokering. | Utnyttjande, täthet och kostnad per arbetslast mäts mot utgångslägen. FinOps-optimering är datadriven. | En självbetjänings-, självläkande plattform med stark multitenans förblir portabel och hybrid-/suveränitetsberedd och förbättras kontinuerligt i hela organisationen. |
| Plattformsteknik och utvecklarupplevelse | Ingen plattform. Varje team sätter ihop sina egna verktyg inkonsekvent. Ärendedrivna överlämningar. Hög kognitiv belastning. | Vissa delade verktyg och mallar, men fragmenterade och delvis manuella. Begränsad självbetjäning. Utvecklarupplevelse omätt. | Ett plattformsteam kör upptrampade stigar, självbetjäningsprovisionering, en utvecklarportal och resultatkort. Skyddsräcken i upptrampade vägar. Utvecklarupplevelse mäts. | Adoption, utvecklarupplevelsepoäng och signaler om kognitiv belastning mäts mot utgångslägen och granskas. | En mogen plattformsprodukt förbättras kontinuerligt utifrån den återkopplingen. Frivillig adoption är hög och styrning förblir osynlig i arbetsflödet i hela organisationen. |
| Test- och processautomation | Testning och drift till stor del manuella. Inkonsekvent täckning. Rutiner i huvuden eller föråldrade dokument. Efterlevnadsbelägg för hand. | Automatiserade tester finns men är långsamma/opålitliga och körs inkonsekvent. Vissa driftskript. Manuell åtgärd. Styrning genom periodisk granskning. | Snabb, parallell, pålitlig testinfrastruktur. Kodifierade körböcker. ChatOps. Automatiskt genererade efterlevnadsbelägg. Styrning som automatiserade kontroller. | Automationstäckning, falskt positiva frekvenser och åtgärdstider mäts mot utgångslägen. | Rutinincidenter åtgärdas automatiskt med skyddsåtgärder. Efterlevnad är kontinuerlig och revisionsklar och människor fokuserar på omdöme i hela organisationen. |
Del 9. Drift, tillförlitlighet och observerbarhet
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Platsförlitlighetsteknik | Drift manuell och reaktiv. Inga SLO:er. Tillförlitlighet är åsikt. Samma incidenter återkommer. Brandkårsutryckning dominerar. | Nyckeltjänster har grundläggande SLI:er/SLO:er. Viss övervakning och larm. Slit erkänns men är omätt. Inkonsekventa efterhandsgranskningar. | Felbudgetar påverkar prioritering. Slit mäts och begränsas. Rutinmässig kapacitetsplanering. Finansierad automation. PRR och engagemangsmodell. | Felbudgetar, slit och SLO-uppfyllnad mäts mot utgångslägen och driver prioritering. | Felbudgetpolicy är automatiserad och respekterad. Självbetjäningsdrift och proaktiv kapacitet låter organisationen väga fart mot stabilitet på data och anpassa sig. |
| Observerbarhet och övervakning | Grundläggande drifttidskontroller och ostrukturerade loggar per maskin. Felsökning betyder SSH. Bullriga, ignorerade larm. | Centraliserade mått och logginsamling. Vissa paneler och tröskellarm. Partiella/saknade spår. Manuell korrelation. | OpenTelemetry-instrumentering med propagerade spår-ID. Strukturerade loggar, spårning, kurerade paneler, SLO-symptomlarm. Hållbar jour. | Larmkvalitet, MTTD och telemetrikostnad mäts mot utgångslägen. Förbränningstaktslarm trimmas mot SLO:er. | Observerbarhet med hög kardinalitet och rika händelser stöder ad hoc-utredning. Lagring är kostnadsoptimerad och telemetri informerar beslut i organisationen. |
| Incidenthantering | Incidenter hanteras ad hoc av den som märker dem. Inga roller, allvarlighetsgrader eller efterhandsgranskningar. Informell jour. Fel återkommer. | Grundläggande jourrotationer och allvarlighetsgrader. Vissa efterhandsgranskningar, men oklara roller och inkonsekvent spårade korrigerande åtgärder. | Ett formellt incidentledningssystem med tydliga roller och kriterier. Skuldfria efterhandsgranskningar är standard. Åtgärder spåras. Jour ersätts. | Incidentfrekvens, MTTR och jourbelastning mäts mot utgångslägen. Återkommande orsaker trendas. | Respons repeteras via spelövningar. Jour förblir hållbar och lugn och aggregerad analys driver strukturell investering när organisationen lär sig. |
| Kostnad, hållbarhet, grön programvara | Molnkostnader är en månatlig överraskning. Ingen märkning, allokering eller koldioxidmedvetenhet. Generös, ogranskad provisionering. | Grundläggande kostnadssynlighet och märkning. Viss reaktiv rätt dimensionering och städning av overksamma resurser. Hållbarhet erkänns men är omätt. | En FinOps-praxis med attribuering, budgetar, prognoser, avvikelselarm, åtaganden, rätt dimensionering. Koldioxid mäts för större tjänster. | Kostnad och koldioxid mäts per team mot budgetar och utgångslägen. Avvikelser flaggas. | Kostnad och koldioxid är kontinuerliga teamägda signaler. Effektiva standardval, automatiserad optimering och koldioxidmedveten schemaläggning förbättras kontinuerligt i hela organisationen. |
Del 10. Projekt-/produkt-/programledning
| Ämne | Nivå 1 Initiera | Nivå 2 Utveckla | Nivå 3 Standardisera | Nivå 4 Hantera | Nivå 5 Orkestrera |
|---|---|---|---|---|---|
| Portfölj- och programledning | Prioriteringar sätts ad hoc av den som ber högljuddast. Ingen portföljbild. Beroenden dyker upp som kriser. Årliga finansieringsröra. | En periodiskt granskad portföljinventering. Publicerade mål svagt kopplade till arbete. Ett beroenderegister. Projektbaserad budgetering. | Strategin kaskaderar via OKR. Ett konsekvent prioriteringsramverk. Planering över team hanterar beroenden. Bestående teamfinansiering. | Portföljutfall, leveransförutsägbarhet och antal beroenden mäts mot utgångslägen. | Portföljen balanseras kontinuerligt om på utfallsbelägg. Beroenden designas bort och finansieringstakten matchar lärandetakten i hela organisationen. |
| Risk, revision och garanti | Risk hanteras reaktivt efter incidenter. Inget ramverk eller register. Odokumenterade kontroller. Smärtsamma manuella revisioner. | Riskregister för större system. Ett kontrollramverk antaget, revisioner klaras men manuellt och vid en tidpunkt. Leverantörer bedöms vid introduktion. | Tre försvarslinjer och ett gemensamt ramverk i hela organisationen. Många kontroller automatiserade. Kontinuerlig övervakning. Leverantörs-/SBOM-inventeringar. Schemalagd DR. | Kontrolleffektivitet, antal öppna risker och revisionsfynd mäts mot riskaptit och utgångslägen. | Garanti är kontinuerlig och till stor del automatiserad. Revisorer tar stickprov på levande belägg och leveranskedjans integritet verifieras när risker utvecklas i hela organisationen. |
| Upphandling, öppen källkod, licensiering | Öppen källkod läggs till fritt. Ingen policy eller inventering. Licenser ogranskade. End-of-life upptäcks av en slump. Ingen ägare. | En grundläggande policy och en lista över godkända licenser. Viss manuell/sen skanning. En inventering för större system. Ad hoc-bidrag. | Ett OSPO äger strategi och verktyg. Automatiserad licens-/sårbarhetsskanning och erkännande. SBOM. Tydliga bidrag. EOL följs. | Licensefterlevnad, beroendens aktualitet och sårbarhetsexponering mäts mot utgångslägen. | Öppen källkod är en hanterad strategisk tillgång med fullt automatiserad efterlevnad. Investering uppströms är medveten och aktualitet och EOL hanteras kontinuerligt i hela organisationen. |
| Att vidmakthålla stora och långlivade system | System beror på hjältar. Ägarskap genom minne. Odokumenterad kunskap. System fryses tills de går sönder. Avvecklingar blir aldrig klara. | Ägarskap tilldelat och registrerat för större system. Viss dokumentation och några körböcker. Uppenbart kritiska funktioner har en reservperson. Reaktivt underhåll. | Teamnivåägarskap i en katalog som överlever omorganisationer. Bussfaktor mäts och mildras. Beslutsloggar och körböcker. Stegvis modernisering. | Bussfaktor, ägarskapstäckning och kunskapsöverföringens framsteg mäts mot utgångslägen. | Förvaltning är en finansierad disciplin. Inget kritiskt system är en enskild mänsklig felpunkt och kunskapsöverföring och planerade avslut fortsätter i hela organisationen. |
| Etik, ansvarsskyldighet, allmänintresse | Etik obehandlad eller reaktiv efter skandal. Tillgänglighet ignoreras. Ogenomskinliga automatiserade beslut utan möjlighet till prövning. Bias otestad. | En uppförandekod och viss (sen) tillgänglighet. Uppmärksammade automatiserade beslut får viss tillsyn. Enstaka biaskontroller. | Etisk granskning är en del av processen. Tillgänglighet inbyggd och användartestad. Konsekvensfulla beslut bär förklaring och möjlighet till prövning. | Rättvise-, tillgänglighets- och algoritmansvarsutfall övervakas mot utgångslägen. | Ansvar är inbäddat i hur organisationen bygger. Rättvisa är en icke förhandlingsbar standard och algoritmansvar är standard och förbättras kontinuerligt i hela organisationen. |
Övergripande mognadsbedömning
Använd matriserna ovan för att ta fram en lättviktig, ärlig poäng.
Poängsättningsunderlag
- Poängsätt varje kapitel 1 till 5 med den nivå vars beskrivning bäst matchar er typiska verklighet. När beteendet är inkonsekvent, poängsätt den lägre nivån.
- Medelvärdesbilda per del. Summera kapitelpoängen i en del och dividera med antalet kapitel. Det ger en mognad per del (t.ex. “Del IV har i snitt 2,5”).
- Notera minimum, inte bara medelvärdet. En del som har i snitt 3,0 men innehåller ett kapitel på nivå 1 bär det kapitlets risk oavsett medelvärdet.
- Rita upp trenden. Bedöm om var eller varannan kvartal och bevaka rörelseriktningen. En domän som rör sig 2 → 3 är friskare än en som står fast på en statisk 3.
Ett enkelt arbetsblad per del:
| Del | Poängsatta kapitel | Medelvärde | Lägsta kapitel | Anteckningar / prioritet |
|---|---|---|---|---|
| I-X | antal | medelvärde | lägsta nivå | … |
Att prioritera vad som ska förbättras
Försök inte höja allt på en gång och jaga inte det högsta medelvärdet. Prioritera efter riskviktat mognadsgap: angrip de domäner där en låg nivå möter hög konsekvens.
- Först: de lägst mogna kapitlen i era högriskdomäner. För de flesta organisationer betyder det säkerhet, integritet, tillförlitlighet, efterlevnad och varje system vars fel skadar människor eller bryter mot lag. En nivå 1 här är akut.
- Härnäst: grundläggande möjliggörare (kultur, arbetssätt, CI/CD, IaC, observerbarhet) som höjer taket för varje annan domän. Att förbättra dessa gör senare vinster billigare.
- Senare: domäner som redan är på nivå 3 och kunde klättra till nivå 4 eller 5. Pressa bara bortom golvet där insatserna och skalan motiverar den extra investeringen.
Baslinjen för företag och myndigheter
Företags- och myndighetssammanhang kan vanligen inte stanna vid “det fungerar.” För att klara revisioner, vidmakthålla tillstånd och uppfylla regulatoriska och offentliga ansvarsskyldigheter måste de flesta domäner nå minst nivå 3 (Standardisera), den nivå där praxis är standardiserad, dokumenterad, upprätthållen över team och producerar belägg. Nivå 2 faller typiskt vid revision eftersom den är inkonsekvent och manuellt hopsatt under tidspress. Nivå 1 faller direkt.
Läs nivå 3 som golvet för allt granskningsbart eller säkerhetsrelevant, och de högre nivåerna (4 och 5) som mål bara där kontinuerlig garanti, skala eller allmänhetens förtroende gör den extra stringensen värd det. Mognad förblir ett medel: syftet är en försvarbar, proportionerlig kontrollnivå för den risk ni faktiskt bär, inte en perfekt poäng.