Förändringsplanering: gap, jobbpaket och prioritering

Var ska du stoppa din nästa krona, vilket gap ska du fylla med vilket jobbpaket? Det handlar om att planera arkitekturen och prioritera arbetspaket. Vilket gap blir ifyllt. 

Den här artikeln handlar om hur du omvandlar svaren från din gapanalys till en plan: hur du definierar arkitekturplatåer som verksamheten faktiskt kan stå på, identifierar gapen mellan dem, formar jobbpaket som stänger gapen, och prioriterar bland paketen med WIA.

Det är här funktion och säkerhet sammanstrålar. Prioriteringsartikeln definierar måtten, WPRF, WSRF, affärsvärde och golvet. Den här artikeln använder dem för att forma en plan.

En platå är inte en milstolpe, en driftbar version av arkitekturen, din design. Det är inte en release, inte ett kvartalsmål och inte en leveransplan. En platå är ett tillstånd där verksamheten faktiskt fungerar.

Fyra krav, och alla fyra måste vara uppfyllda:

1. Den levererar värde till en identifierad intressent. Går det inte att peka ut vem som får något är det ingen platå.
2. Den är driftbar och förvaltningsbar. Någon kan köra den, övervaka den och åtgärda fel i den.
3. Den uppfyller golvet för det den exponerar. Se kapitel 4.
4. Den är mätbar. Ni kan se om antagandena höll, så att nästa platå bygger på erfarenhet i stället för på samma gissning igen.

Kravet på mätbarhet är det som oftast fattas. En platå som inte går att utvärdera ger ingen återkoppling, och då är trappan bara en projektplan i ny förklädnad.

Du har redan två MVP–BIP-stegar.

Affärsprodukten. BIP, Business Idea Product, är produkten som realiserar hela affärsidén, verionen av affärsmodellen som arkitekturen implimenterar. MVP är det minsta livsdugliga steget på vägen dit, kärnan som produkten inte kan fungera utan, testbar, produktionsduglig, och med tillräckligt värde för att någon ska vilja ha den.

Säkerhetssystemet. Säkerhetssystemets BIP är det säkerhetssystem som skyddar hela affärsmodellen och dess tjänster. Säkerhetssystemets MVP är det minsta säkerhetssystem som är ett långsiktigt byggblock i det, valt så att det ger intressenterna nytta från första stund och är reviderbart.

Platån är det enda ställe där de två sammanfaller. Ett steg som bara innehåller det ena är ingen platå — det är en delleverans. Bygger ni affärs-MVP:n utan motsvarande säkerhets-MVP har ni skapat ett tillstånd som inte går att driftsätta, bara demonstrera.

Skillnaden mellan MVP och prototyp är värd att hålla ren. En prototyp finns för att lära, och ska ofta inte återanvändas i produkten. En MVP finns för att driftsättas. Prototypen hör hemma i kategorin osäkerhetsreducerande arbete i kapitel 5.

4-2-1 låter som en formation för fotbollsproffs. Här är det en taktik för verksamhetsproffs.

• Fyra år är den bortre platån. Så långt fram att den rymmer en riktig omvandling, så nära att någon i rummet fortfarande kommer att ha ansvar för den. Den beskrivs i förmågor, inte i teknik.
• Två år är det som är realistiskt att faktiskt uppnå. Här ligger tyngdpunkten i planeringen.
• Ett år är förändringen som ska rymmas inom budgetåret. Den ska vara så konkret att den går att skatta.

Att spannen växer är avsiktligt: det närmaste året planeras i detalj, fyraårsplatån i riktning.

Långa förändringscykler. Storföretag och infrastrukturägare kan lägga till en åttaårshorisont, 8-4-2-1. Men var då tydlig med vad åttan är. Tänk åtta år bakåt: pandemi, krig, Nato, räntechock, AI. Ingen planerade det. Poängen är att åttaårshorisonten är en riktning, inte en prognos. Den ska överleva att alla antaganden om omvärlden slår fel. Läs mer under strategisk planering.

Svaret är alltså tre platåer utöver nuläget. Den sista i horisonten är sällan BIP, och det är i sin ordning så länge riktningen dit är utskriven. Mellan platåerna arbetar ni med MVP-logiken: varje steg ska vara ett minsta livsdugligt tillskott, inte en delleverans som väntar på nästa.

Gapet är avståndet mellan två platåer, uttryckt i förmågor. Fyra typer, och den fjärde glöms nästan alltid.

Osäker förmåga är gapet som gör att säkerhet och affär hamnar i samma lista. Ett säkerhetsgap är inte en särskild sorts arbete — det är samma sorts gap som de andra, med en annan källa. Riskanalysen är den kravinsamling som hittar det.

Avveckling är ett gap. Det kostar arbete, det står sällan i någon backlogg, och det är ofta den billigaste riskreduktionen som finns — att ta bort riskkällan är ett av behandlingsalternativen i ISO/IEC 27005 8.2, och det enda som ger hundra procents täckning. Ett system som är avstängt kan inte angripas.

Gapet ska mätas, inte beskrivas. "Bristande övervakning" är ingen gapformulering. "Vi upptäcker avvikelser i förmedlingsflödet inom timmar, vi behöver inom minuter" är det. Utan ett mätbart avstånd går täckningsgraden i kapitel 5 inte att skatta.

Ett jobbpaket är den minsta enhet som går att prioritera, besluta och driftsätta. Det stänger ett eller flera gap och producerar leverabler — kod, konfiguration, avtal, rutiner, utbildning, dokumentation.

Leverablerna behöver inte vara tekniska. Det högst prioriterade paketet i Gipsat-exemplet är en övad manuell reservrutin.

Begreppet är inte nytt. Du har det troligen redan under ett annat namn:

Om du kör SAFe är jobbpaketet en feature. Säkerhetsgapen blir enabler features, och det är viktigt att de ligger i samma backlogg som allt annat, inte i en separat säkerhetsbacklogg, vilket är den vanligaste och sämsta lösningen. SAFe har redan mekanismen för att skydda dem: capacity allocation, en beslutad andel av kapaciteten som går till enablers. Golvet i kapitel 4 är strängare än så. Det är inte en andel utan ett krav, och det ska in i solution intent tillsammans med övriga regelkrav.

Om du kör PPS är jobbpaketet ett arbetspaket, med det som PPS redan kräver: en definierad leverans, en ansvarig och ett godkännandekriterium. Platån motsvarar en milstolpe där ett fortsättningsbeslut fattas, och WIA är underlaget till just det beslutet. Effekthemtagningen efter projektet är samma sak som utvärderingen i kapitel 7.3 — med skillnaden att den här utvärderar även täckningsgraden på säkerhetsgapen, inte bara nyttoeffekterna.

Det som saknas i båda metoderna är barriärregeln. SAFe låter en feature brytas ner i stories som prioriteras var för sig, och PPS låter ett arbetspaket delas i deluppdrag. Båda är rimliga i normalfallet och farliga när paketet är en barriärkedja: tre av fyra levererade delar ger noll riskreduktion men ser ut som god framdrift. Regeln i 3.2 är därför ett tillägg till er befintliga metod, inte en ersättning för den.

Regel 1: barriärpaket får inte splittras över platågränser. Kräver en farlig händelse fyra barriärer för att brytas, och tre ligger i platå ett medan den fjärde ligger i platå två, är risken oreducerad under hela platå ett. Alla fyra i samma platå, eller så accepteras risken formellt för platå ett.

Regel 2: paketet ska vara självständigt driftsättbart. Kan det inte driftsättas utan ett annat paket är de i praktiken ett paket. Slå ihop dem, eller lägg in beroendet uttryckligen i sekvenseringen.

Regel 3: paketet ska innehålla både affärs- och säkerhetsleverabler när det exponerar något nytt. Ett paket som lägger till funktionalitet utan att ta med skyddet skapar en platå som levererar funktion utan att uppfylla golvet. Det är den vanligaste orsaken till att säkerhetsskuld byggs in i en i övrigt välplanerad arkitektur.

Ett paket ska rymmas inom en platå och gå att skatta med rimlig säkerhet. Går det inte att skatta är det för stort, och då hör det hemma i kategorin osäkerhetsreducerande arbete tills det går.

Motsatt fel är lika vanligt: paket så små att prioriteringen blir en administrativ övning. Riktmärket är att en platå bör innehålla en handfull paket, inte femtio.

Kör ni SAFe har ni redan riktmärket. Ett jobbpaket är en feature, den ska rymmas inom en PI och gå att uttrycka som en nyttohypotes. Blir den större är den en capability och behöver brytas ner. Blir den mindre är den en story, och stories prioriteras inte av WIA utan sekvenseras av teamet.

I PPS är motsvarigheten att arbetspaketet ska ha en ansvarig, en definierad leverans och ett godkännandekriterium. Kan ingen skriva under på leveransen är paketet fel avgränsat.

Kontrollfrågan i båda fallen: kan ledningen fatta ett meningsfullt ja eller nej till just det här paketet? Är svaret nej är det antingen för stort — beslutet blir en principfråga — eller för litet, och då är beslutet inte värt ledningens tid.

prioriteringsartikeln räknas golvet en gång: det legalt tvingande, det som håller värden med vikt 5 under acceptanströskeln, och det existentiella.

I en plan är golvet en funktion av vad platån exponerar. En platå som inte hanterar personuppgifter har inget integritetsgolv. En platå som inte är driftsatt mot verkliga patienter har ett annat golv än en som är det.

Det ger arkitekten ett handgrepp som annars är osynligt: Ryms inte golvet i budgeten är svaret att krympa scopet, inte att sänka säkerheten.

Det är den formuleringen som gör MVP-tänkandet legitimt i en säkerhetskontext. Utan den blir MVP en förevändning för att skjuta upp säkerhet, vilket är den vanliga och farliga varianten.

Det ursprungliga golvet omfattar skydd av transportdata, den övade reservrutinen och hela barriärpaketet mot vårdkaos. Nitton insatsenheter, vilket inte ryms i den första budgeten.

Alternativ A — sänk säkerheten. Skjut upp skyddet av transportdata till platå två. Platån driftsätts och bär patientuppgifter till transportören utan skydd. Detta är otillåtet: golvet är legalt.

Alternativ B — krymp scopet. Låt platå ett förmedla transport utan att skicka patientuppgifter vidare till transportören. Chauffören får adress och tidpunkt, inget vårdinnehåll. Integritetskedjan lyfts därmed ur platå ett i sin helhet.

Alternativ B ger en platå som är driftbar, laglig och möjlig att lära av. Skyddet av transportdata flyttar till platå två, tillsammans med den funktionalitet som kräver det — journalintegrationen.

Det är arkitektens viktigaste beslut i hela planeringen: att ändra vad platån gör i stället för att ändra hur säker den är.

Varje platå ska ha en uttrycklig avgränsningslista. "Platå 1 hanterar inte vårdinnehåll i transportledet" är ett arkitekturbeslut med säkerhetskonsekvenser, och det ska stå någonstans där någon hittar det innan den första utvecklaren lägger till fältet för att det var praktiskt.

Avgränsningen är också en förutsättning i säkerhetsbeviset. Ett antagande som inte är utskrivet är den vanligaste orsaken till att ett bevis inte håller.

Prioriteringsartikeln ställer säkerhetsåtgärder och affärsåtgärder i samma lista. Här är objektet jobbpaketet:

Paketvärde = Σ ( värdet av de gap paketet stänger )
Avkastning = Paketvärde / Paketets insats

Affärsgap värderas som förväntad nytta i de fyra konsekvensområdena, gånger realiseringssannolikhet. Säkerhetsgap värderas som åtgärdsvärde, alltså riskpoäng gånger täckningsgrad. Samma enhet, samma lista.

Golvet. Räknas per platå enligt kapitel 4. Inte förhandlingsbart. Ryms det inte, krymp scopet eller acceptera risken formellt.

Portföljen. Allt ovanför golvet, rangordnat på avkastning oavsett om det är affär eller säkerhet.

Osäkerhetsreducerande arbete. Prototyper, spikes, mätningar och utredningar. De har nästan noll direkt avkastning och skulle alltid hamna sist — men är ofta rätt att göra först.

Prioritera det på hur många efterföljande beslut det förbättrar, inte på avkastning.

En prototyp som gör att fem skattningar går från gissning till underbyggd bedömning är billig och hör hemma tidigt. En utredning som besvarar en fråga ingen ska fatta beslut om är slöseri, hur intressant den än är.

Ett praktiskt riktmärke: avsätt en fast andel av varje platå, förslagsvis tio till tjugo procent, till osäkerhetsreducerande arbete, och låt den andelen konkurrera internt. Då slipper ni diskussionen om huruvida prototyper får kosta, varje gång.

Kom ihåg prototypens natur: den finns för att lära, inte för att driftsättas. Att låta prototypkod glida in i platån är ett effektivt sätt att bygga systematiska fel i grunden.

När paketen är valda sorterar teamen ordningen inom platån med WSJF. Det är en genomförandefråga, inte ett ledningsbeslut, och beroenden mellan paket väger tyngre än marginella skillnader i poäng.

Barriärregeln gäller även här: ett barriärpaket bär hela riskvärdet först när det är komplett. Delarna bär noll.

Det ser ut som fyra steg i följd — definiera platåer, identifiera gap, forma paket, prioritera. Det är det inte.

WIA-resultatet ändrar platåerna. Visar prioriteringen att golvet inte ryms, eller att två paket i olika platåer borde ligga ihop, är det platåindelningen som ska ändras — inte prioriteringen som ska tummas på.

Föreslå platåer → räkna golv → identifiera gap → forma paket → WIA
        ↑                                                      │
        └──────────────  justera platåerna  ───────────────────┘

Räkna med två till tre varv innan planen sitter. Det är normalt, och det är billigare än att upptäcka samma sak efter halva platå ett.

Planen revideras vid två tillfällen. När en platå är nådd, som en del av utvärderingen. Och när en förutsättning ändras — ny lagstiftning, ny hotbild, förvärv, förlorad kund. Det andra är den strategiska cykeln i ISO/IEC 27005 5.2.

Planen och säkerhetsbeviset delar ryggrad, och det är därför båda kan genereras ur modellen:

Värde → förmåga → gap → jobbpaket → leverabel → krav → test → bevis
                    ↑
              platå (tillstånd)

Varje jobbpaket pekar uppåt på de gap det stänger, och nedåt på de leverabler som stänger dem. Saknas någon länk syns det som ett tomt fält, inte som en tyst brist.

Fyra frågor, och de är samma varje gång:

1. Levererade platån det värde vi antog?
2. Blev täckningsgraden på säkerhetsgapen den vi skattade?
3. Vilka skattningar var systematiskt fel, och åt vilket håll?
4. Vad i nästa platå ska ändras på grund av svaren?

Resultaten går in i ledningens genomgång, och de uppdaterar säkerhetsbeviset. En platå som passerats utan att utvärderas är en missad iteration — och det är iterationerna som är hela poängen.