fbpx

Koll på IT-komplexitet – så gör du med svarta svanar och feta svansar

Om vi vill höja kvaliteten på IT-Leveranserna måste vi bli bättre på att förstå komplexitet och hantera våra IT-system som just komplexa system, något som sällan görs i dag.
Detta är del ett i serien om komplexitet. 

Redan i slutet av 60-talet började man diskutera den så kallade mjukvarukrisen ”The software Crisis”, med problem som otillförlitlig mjukvara, skenande underhållskostnader, undermålig förändringsbarhet och leveranser som inte höll budget. Det är problemställningar som känns igen alltför väl även i dag. En mängd arbetssätt och metoder har tillämpats för att förbättra situationen sedan dess utan att graden av lyckade IT-leveranser förändras nämnvärt. Ett återkommande problem är komplexitet. Nya förbättrade arbetssätt som tillämpats för att förbättra leveranser hinner inte kompensera för den ökande komplexiteten som kommer sig av den teknikutveckling som möjliggör allt mer avancerade system. Ofta kan leveransproblem, brister i säkerhet eller funktionalitet direkt kopplas till just komplexitet.

Komplexitet
För att förstå hur komplexa problemställningar skall hanteras behöver vi titta lite övergripande på vad komplexitet är. En vanlig modell för att beskriva och dela upp olika typer av problemställningar är Cynefin-ramverket:

Ramverket delar upp problemställningar eller situationer i fem kategorier: Komplex, Komplicerad, Kaotisk, Enkel samt Oordning (mitten). Ramverket beskriver vissa egenskaper för respektive kategori samt det angreppssätt som kan användas för att hantera problemet eller situationen. Utifrån denna modell kan vi fundera på hur vi jobbar med IT-system och inse att vi ofta jobbar med komplexa system på fel sätt. Eller rättare sagt att vi inte jobbar med komplexitet över huvud taget.

Komplicerade system
Komplicerade problemställningar är, enligt Cynefin-ramverket, problemställningar med tydliga regler och avgränsningar samt enkla beroenden. Det går att förstå orsakssamband och händelser går att förutsäga. Dessa problemställningar (tillsammans med enkla) kallas också linjära då det finns ett linjärt samband mellan orsak och verkan. Bästa sättet att angripa eller förekomma problem är genom analys. Detta är klassisk ingenjörskonst och inom IT och systemteori är det nästan uteslutande inom denna problemdomän vi verkar. Vi har väl utvecklade metoder för att kravställa, analysera, testa och utveckla enligt denna princip. Problemet är att vi allt oftare inte arbetar med komplicerade system utan med komplexa system. Detta är jätteviktigt att förstå eftersom det till stor del förklarar varför IT-projekt med väldigt omfattande kravspecifikationer, analysfaser och implementationsprojekt ändå kan misslyckas att leverera det som förväntas.

Läs mer: Komplexa system – så hanterar vi dem i praktiken

Komplexa system
Vad är komplexa system då? Det finns ingen entydig definition av komplexa system och forskningen på ämnet spretar men komplexa system beskrivs ofta som system som består av många interagerande komponenter. Den stora mängden interaktioner och möjliga utfall gör det omöjligt att förutsäga systemets beteende eller till fullo modellera det.
Det är lätt att se att allt fler IT-system är just komplexa system endast genom dess storlek och antal beroenden vilka inte går att till fullo analysera. Det är också lätt att se detta genom antalet oväntade problem, incidenter eller för den delen möjligheter som det komplexa systemet skapar. En annan indikation på komplexa system är att oavsett hur stort analytiskt förberedande arbete vi gör för att säkra system så räcker det inte till. Att arbeta utifrån ett linjärt perspektiv är bra för linjära problemställningar, men för icke linjära problem är det helt fel. Oväntade händelser kommer att inträffa.
Detta leder oss till två egenskaper hos komplexa system som är centrala för att förstå hur vi behöver arbeta med dem: Black Swan Events och Fat Tails.

Osannolika händelser
Black Swans Events är osannolika händelser med stora konsekvenser. Att exempelvis arbeta med att tidsoptimera en viss process i en fabrik är normalt arbete som alla fabriker behöver jobba med. Men i förhållande till en händelse som att hela fabriken brinner ned blir det arbetet i stort sett irrelevant ifall man försöker jämföra dem. För komplexa system visar det sig att dessa händelser är vanligare än man tror och per definition är de omöjliga att förutsäga. Att jobba med riskhantering för komplexa system är därför oerhört svårt då det inte egentligen går att uppskatta vilka problem som kan uppstå eller hur allvarliga de kan bli.

Egenskap hos komplexa system
Fat Tails är en egenskap hos komplexa system som säger att det är mycket mer sannolikt med osannolika händelser än vad vi tror, räknar med, modellerar, bevisar eller designar för. Det är en direkt konsekvens av komplexa systems många interagerande komponenter som gör att mängden utfall eller tillstånd i systemet är långt större än vad som går att analysera. Termen kommer från hur en fördelningskurva av händelser ser ut för komplexa system där händelser som ligger i ändarna av kurvan är vanligare än förväntat och änden av kurvan blir tjockare än normalt. Den är alltså inte normalfördelad.

Kärnkraftverk – går sönder oftare än vi tror
Ett tydligt och kanske lite kontroversiellt exempel på detta är kärnkraftverk. Man kan ibland höra från tillverkare eller forskare att risken för en olycka kan ligga på exempelvis en på en miljard. Men kärnkraftverk är komplexa system och modellen som beräknat sannolikheten kan inte beakta allt som kan hända, som exempelvis en stor tsunami (Fukushima) eller flera var för sig oberoende felkällor (Tjernobyl). Genom att jämföra antalet kärnkraftverk i drift och antalet kärnkraftsolyckor som hänt förstår man enkelt att modellerna över risken ligger många tio-potenser fel. Antalet oförutsedda händelser är mycket större än man tror och det förekommer Black Swan-händelser med jämna mellanrum som ingen trodde skulle kunna inträffa. Detta är grundläggande egenskaper hos komplexa system.

Detsamma gäller för komplexa IT-system. Vi måste börja tänka på komplexitet när vi utvecklar system. De metoder vi traditionellt använder oss av är ofta till för att hantera komplicerade system med linjära samband. System där vi i förväg kan kravställa funktionalitet, modellera beteende, rita upp alla beroenden eller skapa de testfall som behövs för att fånga alla fel. Detta fungerar inte för komplexa system eftersom förändring och oförutsedda händelser behöver tas i beaktande.

 

Johannes Jansson, konsult och associerad partner, Tagore

 

Ps. Nästa blogginlägg handlar om hur vi praktiskt hanterar komplexiteten.