Vad gör jag nu? Att planera för designändringar

Ganska ofta ställs jag inför att tala med människor om deras systemdesigner, planer och arkitekturer. Och många gånger sker den diskussionen för sent och designerna är antingen redan implementerade eller också är de delvis implementerade. Detta kan vara mycket frustrerande om den pågående designen har bedömts inte vara idealisk för situationen.

Jag förstår känslan av frustration som kommer av en situation som denna, men det är något som vi inom IT måste möta mycket regelbundet, och att hantera denna reaktion konstruktivt är en central IT-färdighet. Vi måste bli mästare på denna situation både tekniskt och känslomässigt. Vi bör inte förlamas av den; det är en naturlig situation som varje IT-yrkesperson kommer att uppleva regelbundet. Den bör inte vara nedslående eller förlamande, men det är fullt förståeligt att den kan kännas så.

En central anledning till att vi upplever detta så ofta är att IT är ett enormt fält med ett stort antal variabler att beakta i varje situation. Det är också ett mycket kreativt fält där det kan finnas talrika, gångbara tillvägagångssätt för ett givet problem. Att det överhuvudtaget finns ett enda “bästa” alternativ är sällan sant. Normalt finns det många konkurrerande alternativ. Ibland är dessa mycket nära besläktade, ibland är dessa alternativ drastiskt olika, vilket gör dem mycket svåra att jämföra på ett meningsfullt sätt.

En annan central anledning är att faktorer förändras. Detta kan vara att nya tekniker eller ny information kommer fram, nya produkter släpps, produkter uppdateras, priser ändras eller affärsbehov förändras nära eller till och med under besluts- och designprocesserna. Denna förändringstakt är inte något som vi, som IT-yrkespersoner, någonsin kan hoppas på att kontrollera. Det är något som vi måste acceptera och hantera så gott vi kan.

En annan sak som jag ofta ser förbises är att en lösning som var idealisk när den skapades kanske inte är idealisk om samma beslut skulle fattas i dag. Detta utgör inte på något sätt en brist i den ursprungliga designen, men jag har sett många reagera på det som om det vore så. Det vanligaste scenariot som jag stöter på där jag ser människor uppvisa detta beteende är i motviljan mot att använda RAID 5 i modern lagringsdesign, där RAID 6 och RAID 10 är de populära alternativen av goda skäl. Men denna motvilja mot RAID 5, som varit vanlig sedan ungefär 2009, fanns inte alltid, och från mitten av 1990-talet fram till nästan slutet av 2000-talet var RAID 5 inte bara gångbart, det var mycket ofta den bästa lösningen för de givna affärsmässiga och tekniska behoven (ökningen av motviljan mot det var mestadels gradvis, inte plötslig). Många ser dock RAID 5 som förståeligt dåligt som alternativ i dag, men tillämpar denna nya motvilja på system som designades och implementerades för länge sedan, ibland för nära två decennier sedan. Detta är ologiskt och är en rent känslomässig reaktion. Att RAID 5 var det bästa valet för ett scenario 2002 innebär inte på något sätt att det fortfarande kommer att vara det bästa valet 2015. Men på samma sätt förringar eller upphäver inte det faktum att RAID 5 är ett dåligt val 2015 för ett scenario det faktum att det mycket ofta var ett utmärkt val för flera år sedan.

Jag har många gånger blivit tillfrågad om vad man ska göra när mindre än idealiska designbeslut redan har fattats. “Vad gör jag nu?”

Att lära sig vad man ska göra när perfektion inte längre är ett alternativ (som om det någonsin verkligen var det – all IT handlar om kompromisser) är en mycket viktig färdighet. Det första vi måste ta itu med är de känslomässiga problemen, eftersom dessa kommer att undergräva allt annat. Vi måste göra vårt bästa för att ta ett steg tillbaka, acceptera situationen och agera rationellt. Det sista vi vill göra är att ta en icke-idealisk situation och förvärra saker genom att försöka i efterhand rättfärdiga dåliga beslut eller genom att gripas av panik.

Att acceptera att ingen design är perfekt, att det inte finns något sätt att alltid få allt helt rätt och att hantera detta helt enkelt är en del av att arbeta inom IT är det första steget. Ta ett steg tillbaka, andas djupt. Det är inte så illa. Detta är inte en unik situation. Varje IT-proffs som arbetar med design går igenom detta hela tiden. Du bör göra ditt bästa för att fatta bästa möjliga beslut, men du måste också acceptera att det sällan kan göras – ingen har tillgång till tillräckligt med resurser för att verkligen kunna göra det. Vi arbetar med det vi har. Så här är vi. Vad är nästa steg?

Nästa steg är att bedöma situationen. Var befinner vi oss nu? I många fall är implementeringen klar och det finns inget mer att göra. Situationen är inte idealisk, men är den dålig? Mycket ofta är det största misstaget som jag ser människor ställas inför hos en redan implementerad design att den är för kostsam – vanligtvis är “bättre” lösningar inte bättre för att de är snabbare eller mer tillförlitliga, utan de är bättre för att de är billigare, enklare eller snabbare att få implementerade. Det är en olycklig situation, men knappast en förlamande sådan. Vilken tid eller vilka pengar som än spenderades måste ha varit en acceptabel mängd vid den tidpunkten och måste ha godkänts. Det bästa vi kan göra, just nu, är att lära av beslutsprocessen och försöka undvika överutgifterna i framtiden. Det betyder inte att den befintliga lösningen inte kommer att fungera, eller ens att den inte kommer att fungera fantastiskt bra. Det är helt enkelt så att det kanske inte var ett perfekt val med tanke på de inblandade affärsbehoven, främst de ekonomiska.

Det finns situationer där en design som har implementerats inte i tillräcklig grad uppfyller de angivna affärskraven. Detta är lyckligtvis mindre vanligt, enligt min erfarenhet, eftersom det är en mycket svårare situation. I detta fall behöver vi göra vissa modifieringar för att uppfylla våra affärsbehov. Detta kan visa sig vara dyrt eller komplext. Men saker och ting kanske inte är så illa som de verkar. Ofta är reaktionerna på detta vilseledande och situationen kan ofta räddas.

Det första steget när vi väl befinner oss i en position där vi har implementerat en lösning som inte uppfyller affärsbehoven är att på nytt bedöma affärsbehoven. Detta innebär inte att vi bör förvanska behoven för att massera in dem så att de blir vad än vårt system kan uppfylla, inte alls. Men det är ett bra tillfälle att gå tillbaka och se om de ursprungligen angivna behoven verkligen är giltiga eller om de helt enkelt inte granskades tillräckligt väl, eller, ännu mer sannolikt, att gå och se om affärsbehoven har förändrats under den tid då implementeringen ägde rum. Det kan vara så att den implementerade lösningen faktiskt uppfyller de verkliga affärsbehoven även om de ursprungligen angavs felaktigt, eller för att behoven har förändrats över tid. Eller också kan det vara så att affärsbehoven har förändrats så dramatiskt att även perfekt planering ursprungligen skulle ha kommit till korta gentemot de befintliga behoven, och det faktum att den implementerade lösningen inte presterar som förväntat är av mindre betydelse. Jag har blivit mycket förvånad över hur ofta denna verifiering av affärsbehoven har förvandlat en lösning som ansetts vara otillräcklig till en “överdimensionerad” lösning som faktiskt kostade mer än nödvändigt, helt enkelt för att ingen ifrågasatte överdrifterna av affärsbehoven eller för att ingen ifrågasatte det ekonomiska värdet av vissa teknikinvesteringar.

Det andra steget är att skapa en ny teknisk baslinje. Detta är ett mycket viktigt steg för att hjälpa till att förhindra att IT faller ner i fällan med sunk cost-villfarelsen (kostnaden för redan nedlagda investeringar). Det är extremt vanligt för vem som helst, detta är inte på något sätt unikt för IT, att se på den tid och de pengar som lagts ned på ett projekt och anta att det rätta är att fortsätta längs den ursprungliga vägen, oavsett hur dåraktig den är, eftersom så mycket resurser redan har lagts ned på den vägen. Men detta är förstås ologiskt, hur du kom till ditt nuvarande tillstånd är irrelevant. Det som är relevant är att bedöma de nuvarande behoven hos avdelningen och företaget och att inventera de för närvarande tillgängliga lösningarna, teknikerna och resurserna. Givet det nuvarande tillståndet kan den bästa vägen framåt fastställas. All hänsyn som tas till den ansträngning som lagts ned för att nå det nuvarande tillståndet är endast vilseledande.

Ett bra exempel på sunk cost-villfarelsen finns i schackspelet. Vid varje drag är det viktigt att på nytt bedöma alla tillgängliga drag, risker och strategier, eftersom vilka drag som användes för att nå det nuvarande tillståndet inte har någon betydelse för vilka drag som är vettiga framöver. Om världens bästa schackspelare eller en fantastisk schackalgoritm i en dator skulle tas in mitt i ett parti skulle de inte behöva någon kunskap om hur det nuvarande tillståndet hade uppstått – de skulle helt enkelt bedöma det nuvarande tillståndet och skapa en strategi baserad på det.

Detta är detsamma som hur vi bör bete oss inom IT. Vårt nuvarande tillstånd är vårt nuvarande tillstånd. Det spelar ingen roll för den strategiska planeringen vad som utspelade sig för att försätta oss i det tillståndet. Vi bryr oss endast om de besluten och kostnaderna när vi gör en obduktion (post mortem) för att fastställa var beslutsfattandet kan ha brustit, i syfte att lära av det. Att lära om oss själva och våra processer är mycket viktigt. Men det är en mycket annorlunda uppgift än att göra strategisk planering för det aktuella initiativet.

Det olyckliga här är att vi måste börja om våra planeringsprocesser, men denna gång med, antar vi, mer att arbeta med. Men detta kan inte undvikas. I de värsta fallen är budgetar inte längre tillgängliga och det finns inga resurser för att åtgärda den felaktiga designen och uppnå de nödvändiga affärsmålen. Kompromisser är ibland nödvändiga. Att klara sig med det vi har är ibland det bästa vi kan göra. Men i den absoluta majoriteten av fallen, tycks det, kan någon kombination av ytterligare budget eller kreativ återanvändning av befintliga produkter vara tillräcklig för att avhjälpa situationen.

När vi väl har nått ett tillstånd där vi har åtgärdat våra tillkortakommanden, vare sig det helt enkelt är genom att acceptera att vi har spenderat för mycket, levererat för lite eller har anpassat oss för att uppfylla behoven, har vi en möjlighet att gå tillbaka och undersöka våra beslutsprocesser. Det är genom att göra detta som vi hoppas kunna växa som individer och, om det överhuvudtaget är möjligt, på en organisatorisk nivå lära av våra misstag, eller fastställa om det ens fanns några misstag. Varje företag och varje individ gör misstag. Det som skiljer oss åt är förmågan att lära av dem och undvika samma misstag i framtiden. Tillväxt kommer främst av att uppleva smärta på detta sätt, och även om det ofta är obehagligt att möta är det här som vi har den bästa möjligheten att skapa verkligt, bestående värde. Skjut inte upp eller hoppa över denna möjlighet till granskning, vare sig det är en hård, personlig granskning som du gör själv eller en formell, organisatorisk granskning som drivs av personer som är utbildade för att göra det, eller något däremellan. Ju snabbare beslutsprocesserna utvärderas, desto färskare kommer minnet att vara och desto snabbare kan kurskorrigeringen träda i kraft.

Det sista steget som vi kan ta är att börja beslutsprocessen för att designa en ersättare för den nuvarande implementeringen så snart som möjligt, när väl granskningen av beslutsprocessen är klar. Detta betyder inte nödvändigtvis att vi bör avse att spendera pengar eller ändra våra designer inom en snar framtid. Inte alls. Men genom att vara extremt proaktiva i beslutsfattandet kan vi försöka undvika det förflutnas problem genom att ge oss själva ytterligare tid för planering, mer tid för kravinsamling och dokumentation, bättre insikt i förändringar i kraven över tid genom att regelbundet återbesöka dessa krav för att se om de förblir stabila eller om de förändras, fler tillfällen att få ledningens och kollegornas stöd och engagemang i beslutet samt bättre förståelse för problemdomänen så att vi är bättre rustade att ändra den avsedda designen eller veta när vi ska skrota den och börja om innan vi implementerar den nästa gång. Det kan också, potentiellt, ge oss en bättre chans att kodifiera organisatorisk kunskap som kan föras vidare till en efterträdare, ifall du själv inte skulle befinna dig i positionen att fatta beslut eller utföra implementering när nästa cykel kommer.

Med goda, rationella processer och en god förståelse för de steg som behöver tas i ett fall av mindre än idealisk systemdesign eller -implementering kan vi återhämta oss från felsteg och inte bara, i de flesta fall, återhämta oss från dem på kort sikt, utan vi kan också skydda organisationen från samma misstag i framtiden.