Wat doe ik nu? Plannen voor ontwerpwijzigingen

Heel vaak sta ik tegenover de taak om met mensen te praten over hun systeemontwerpen, plannen en architecturen. En vaak vindt dat gesprek te laat plaats en zijn de ontwerpen al geïmplementeerd of gedeeltelijk geïmplementeerd. Dit kan zeer frustrerend zijn wanneer is vastgesteld dat het ontwerp in uitvoering niet ideaal is voor de situatie.

Ik begrijp het gevoel van frustratie dat uit een dergelijke situatie zal voortkomen, maar het is iets waarmee wij in de IT zeer regelmatig geconfronteerd worden, en het constructief beheersen van deze reactie is een essentiële IT-vaardigheid. Wij moeten meesters van deze situatie worden, zowel technisch als emotioneel. We moeten ons er niet door laten verlammen; het is een natuurlijke situatie die elke IT-professional regelmatig zal meemaken. Het zou niet ontmoedigend of verlammend moeten zijn, maar het is heel begrijpelijk dat het zo kan aanvoelen.

Een belangrijke reden waarom wij dit zo vaak ervaren, is dat de IT een enorm vakgebied is met een groot aantal variabelen die in elke situatie in overweging genomen moeten worden. Het is tevens een uiterst creatief vakgebied waarin talrijke werkbare benaderingen voor elk willekeurig probleem kunnen bestaan. Dat er zelfs maar één “beste” optie is, is zelden waar. Normaal gesproken zijn er veel concurrerende opties. Soms liggen deze zeer dicht bij elkaar, soms verschillen deze opties drastisch, waardoor ze zeer moeilijk zinvol met elkaar te vergelijken zijn.

Een andere belangrijke reden is dat factoren veranderen. Dit kan zijn doordat nieuwe technieken of informatie aan het licht komen, nieuwe producten worden uitgebracht, producten worden bijgewerkt, prijzen veranderen of zakelijke behoeften veranderen kort vóór of zelfs tijdens de besluitvormings- en ontwerpprocessen. Dit veranderingstempo is niet iets waarop wij als IT-professionals ooit kunnen hopen het te beheersen. Het is iets wat wij moeten accepteren en zo goed mogelijk moeten aanpakken.

Iets anders wat ik vaak over het hoofd zie gaan, is dat een oplossing die ideaal was op het moment van besluitvorming, mogelijk niet ideaal is als dezelfde beslissing vandaag genomen zou worden. Dit duidt op geen enkele wijze op een tekortkoming in het oorspronkelijke ontwerp, en toch heb ik veel mensen erop zien reageren alsof dat wel zo was. Het meest voorkomende scenario waarin ik mensen dit gedrag zie vertonen, is de afkeer van het gebruik van RAID 5 in modern opslagontwerp, waarbij RAID 6 en RAID 10 om goede redenen de populaire alternatieven zijn. Maar deze afkeer van RAID 5, die sinds ongeveer 2009 gangbaar is, bestond niet altijd, en van halverwege de jaren negentig tot vrijwel het einde van de jaren 2000 was RAID 5 niet alleen werkbaar, maar zeer vaak de beste oplossing voor de gegeven zakelijke en technische behoeften (de toename van de afkeer ervan verliep grotendeels geleidelijk, niet plotseling). Toch zien veel mensen RAID 5 vandaag terecht als een slechte optie, maar passen ze deze nieuwe afkeer toe op systemen die lang geleden zijn ontworpen en geïmplementeerd, soms bijna twee decennia geleden. Dit slaat nergens op en is louter een emotionele reactie. Dat RAID 5 in 2002 de beste keuze voor een scenario was, impliceert op geen enkele wijze dat het in 2015 nog steeds de beste keuze zal zijn. Maar evenzo doet het feit dat RAID 5 in 2015 een slechte keuze voor een scenario is, op geen enkele wijze afbreuk aan het feit dat het enkele jaren geleden zeer vaak een uitstekende keuze was.

Mij is vele malen gevraagd wat te doen wanneer er minder dan ideale ontwerpbeslissingen zijn genomen. “Wat doe ik nu?”

Leren wat te doen wanneer perfectie geen optie meer is (alsof het dat ooit echt was; in de IT draait alles om compromissen) is een zeer belangrijke vaardigheid. Het eerste wat wij moeten aanpakken zijn de emotionele problemen, aangezien deze al het andere zullen ondermijnen. Wij moeten ons best doen om een stap terug te doen, de situatie te accepteren en rationeel te handelen. Het laatste wat wij willen doen, is een niet-ideale situatie nemen en de zaken erger maken door slechte beslissingen achteraf te willen rechtvaardigen of in paniek te raken.

Accepteren dat geen enkel ontwerp perfect is, dat er geen manier is om de dingen altijd volledig goed te krijgen en dat het omgaan hiermee nu eenmaal onderdeel is van werken in de IT, is de eerste stap. Doe een stap terug, haal diep adem. Zo erg is het niet. Dit is geen unieke situatie. Elke IT-professional die ontwerpen maakt, maakt dit voortdurend mee. U zou uw uiterste best moeten doen om de best mogelijke beslissingen te nemen, maar u moet ook accepteren dat dit zelden gedaan kan worden – niemand heeft toegang tot voldoende middelen om daartoe werkelijk in staat te zijn. Wij werken met wat wij hebben. Dus hier staan wij. Wat is de volgende stap?

De volgende stap is het beoordelen van de situatie. Waar staan wij nu? In veel gevallen is de implementatie voltooid en valt er niets meer te doen. De situatie is niet ideaal, maar is ze slecht? Heel vaak is de grootste fout die ik mensen zie maken bij een reeds geïmplementeerd ontwerp dat het te kostbaar is – doorgaans zijn “betere” oplossingen niet beter omdat ze sneller of betrouwbaarder zijn, maar omdat ze goedkoper, eenvoudiger of sneller te implementeren zijn. Dat is een ongelukkige situatie, maar bepaald geen verlammende. Welke tijd of welk geld ook is besteed, het moet destijds een aanvaardbaar bedrag zijn geweest en moet zijn goedgekeurd. Het beste wat wij op dit moment kunnen doen, is leren van het besluitvormingsproces en proberen de overbesteding in de toekomst te vermijden. Het betekent niet dat de bestaande oplossing niet zal werken of zelfs niet uitstekend zal werken. Het is simpelweg zo dat het mogelijk geen perfecte keuze was gezien de zakelijke behoeften, voornamelijk financiële, die ermee gemoeid waren.

Er zijn situaties waarin een ontwerp dat is geïmplementeerd niet adequaat voldoet aan de gestelde zakelijke eisen. Dit komt naar mijn ervaring gelukkig minder vaak voor, aangezien het een veel lastigere situatie is. In dat geval moeten wij enkele aanpassingen doen om aan onze zakelijke behoeften te voldoen. Dit kan kostbaar of complex blijken te zijn. Maar de zaken zijn misschien niet zo slecht als ze lijken. Vaak zijn reacties hierop misleidend en kan de situatie vaak gered worden.

De eerste stap, zodra wij in een positie verkeren waarin wij een oplossing hebben geïmplementeerd die niet aan de zakelijke behoeften voldoet, is het opnieuw beoordelen van de zakelijke behoeften. Dit wil niet zeggen dat wij de behoeften zouden moeten verdraaien om ze te kneden tot iets wat ons systeem wél kan vervullen, integendeel. Maar het is een goed moment om terug te gaan en te kijken of de oorspronkelijk gestelde behoeften werkelijk geldig zijn, of dat ze simpelweg niet grondig genoeg zijn getoetst, of, nog waarschijnlijker, om te gaan kijken of de zakelijke behoeften zijn veranderd gedurende de tijd dat de implementatie plaatsvond. Het kan zijn dat de geïmplementeerde oplossing in feite wél aan de werkelijke zakelijke behoeften voldoet, ook al waren deze oorspronkelijk verkeerd geformuleerd, of doordat de behoeften in de loop der tijd zijn veranderd. Of het kan zijn dat de zakelijke behoeften zo drastisch zijn veranderd dat zelfs perfecte planning oorspronkelijk tekort zou zijn geschoten ten opzichte van de huidige behoeften, en dat het feit dat de geïmplementeerde oplossing niet presteert zoals verwacht van ondergeschikt belang is. Ik heb mij er zeer vaak over verbaasd hoe vaak deze verificatie van zakelijke behoeften een oplossing die inadequaat werd geacht heeft veranderd in een “overdreven” oplossing die in werkelijkheid meer kostte dan nodig, simpelweg omdat niemand zich verzette tegen overdrijvingen van zakelijke behoeften of omdat niemand de financiële waarde van bepaalde technologische investeringen in twijfel trok.

De tweede stap is het creëren van een nieuwe technologische uitgangspositie. Dit is een zeer belangrijke stap om te helpen voorkomen dat de IT in de val van de sunk cost-drogreden trapt. Het is uiterst gangbaar voor eenieder, dit is op geen enkele wijze uniek voor de IT, om naar de tijd en het geld te kijken die aan een project zijn besteed en aan te nemen dat het voortzetten van de oorspronkelijke koers, hoe dwaas die ook is, de juiste weg is, omdat er al zoveel middelen aan die koers zijn besteed. Maar dit slaat natuurlijk nergens op; hoe u in uw huidige toestand bent beland, is irrelevant. Wat relevant is, is het beoordelen van de huidige behoeften van de afdeling en het bedrijf en het opmaken van de balans van de op dit moment beschikbare oplossingen, technologieën en middelen. Gegeven de huidige toestand kan de beste koers voorwaarts worden bepaald. Elke overweging die wordt gegeven aan de inspanning die is geleverd om de huidige toestand te bereiken, is slechts misleidend.

Een goed voorbeeld van de sunk cost-drogreden is het schaakspel. Bij elke zet is het belangrijk om alle beschikbare zetten, risico's en strategieën opnieuw te beoordelen, omdat welke zetten ook zijn gebruikt om de huidige toestand te bereiken, geen invloed hebben op welke zetten zinvol zijn voor de toekomst. Als de beste schaker ter wereld of een verbluffend computer-schaakalgoritme midden in het spel zou worden ingeschakeld, zouden zij geen enkele kennis nodig hebben over hoe de huidige toestand tot stand is gekomen – zij zouden simpelweg de huidige toestand beoordelen en daarop een strategie baseren.

Dit is precies hoe wij ons in de IT zouden moeten gedragen. Onze huidige toestand is onze huidige toestand. Voor strategische planning maakt het niet uit wat zich heeft afgespeeld om ons in die toestand te brengen. Wij hechten alleen belang aan die beslissingen en kosten bij het uitvoeren van een evaluatie achteraf, om te bepalen waar de besluitvorming mogelijk heeft gefaald, teneinde ervan te leren. Leren over onszelf en onze processen is zeer belangrijk. Maar dat is een heel andere taak dan het uitvoeren van strategische planning voor het huidige initiatief.

Het vervelende hier is dat wij onze planningsprocessen opnieuw moeten beginnen, maar dit keer met, naar wij aannemen, meer om mee te werken. Maar dit valt niet te vermijden. In de ergste gevallen zijn er geen budgetten meer beschikbaar en zijn er geen middelen om het gebrekkige ontwerp te herstellen en de noodzakelijke zakelijke doelstellingen te bereiken. Compromissen zijn soms noodzakelijk. Het roeien met de riemen die wij hebben, is soms het beste wat wij kunnen doen. Maar in de overgrote meerderheid van de gevallen, zo lijkt het, kan een combinatie van aanvullend budget of creatief hergebruik van bestaande producten toereikend zijn om de situatie te verhelpen.

Zodra wij een toestand hebben bereikt waarin wij onze tekortkomingen hebben aangepakt, hetzij simpelweg door te accepteren dat wij te veel hebben uitgegeven of te weinig hebben geleverd, hetzij door bij te sturen om aan de behoeften te voldoen, hebben wij de gelegenheid om terug te gaan en onze besluitvormingsprocessen te onderzoeken. Het is door dit te doen dat wij hopen te groeien als individu en, indien enigszins mogelijk, op organisatorisch niveau te leren van onze fouten, of vast te stellen of er überhaupt fouten waren. Elk bedrijf en elk individu maakt fouten. Wat ons onderscheidt, is het vermogen om ervan te leren en diezelfde fouten in de toekomst te vermijden. Groei komt voornamelijk voort uit het op deze wijze ervaren van pijn, en hoewel het vaak onaangenaam is om onder ogen te zien, is het hier dat wij de beste gelegenheid hebben om werkelijke, blijvende waarde te creëren. Stel deze gelegenheid tot evaluatie niet uit en sla haar niet over, of het nu gaat om een harde, persoonlijke evaluatie die u zelf uitvoert, of een formele, organisatorische evaluatie die wordt uitgevoerd door mensen die daarvoor zijn opgeleid, of iets daartussenin. Hoe eerder de besluitvormingsprocessen worden geëvalueerd, des te verser de herinnering zal zijn en des te eerder de koerscorrectie effect kan sorteren.

De laatste stap die wij kunnen zetten, is zo spoedig mogelijk beginnen met het besluitvormingsproces om een vervanging voor de huidige implementatie te ontwerpen, zodra de evaluatie van het besluitvormingsproces is voltooid. Dit betekent niet noodzakelijkerwijs dat wij van plan zouden moeten zijn om in de nabije toekomst geld uit te geven of onze ontwerpen te wijzigen. Integendeel. Maar door uiterst proactief te zijn in de besluitvorming kunnen wij proberen de problemen uit het verleden te vermijden door onszelf extra tijd voor planning te geven, meer tijd voor het inventariseren en documenteren van eisen, beter inzicht in veranderingen in eisen in de loop der tijd door deze eisen regelmatig opnieuw te bekijken om te zien of ze stabiel blijven of veranderen, meer gelegenheid om steun en betrokkenheid van het management en collega's bij de beslissing te verwerven, en een beter begrip van het probleemdomein, zodat wij beter toegerust zijn om het beoogde ontwerp aan te passen of weten wanneer wij het moeten verwerpen en opnieuw beginnen voordat wij het de volgende keer implementeren. Het zou ons mogelijk ook een betere kans kunnen geven om organisatorische kennis vast te leggen die zou kunnen worden overgedragen aan een opvolger, mocht u zelf niet in de positie van besluitvorming of implementatie verkeren wanneer de volgende cyclus aanbreekt.

Met goede, rationele processen en een goed begrip van de stappen die genomen moeten worden in geval van minder dan ideaal systeemontwerp of ideale implementatie, kunnen wij ons herstellen van misstappen en niet alleen, in de meeste gevallen, op de korte termijn van deze misstappen herstellen, maar kunnen wij de organisatie ook beschermen tegen diezelfde fouten in de toekomst.