Ontkoppelen

Kleine incidenten kunnen ook hard om zich heen grijpen als je geen idéé hebt wat je moet doen om dat tegen te houden. Het ontbreekt simpelweg aan kennis. Je zou ook kunnen zeggen: dan heb je het te complex gemaakt. Het kan ook zijn dat je heel goed weet wat er gebeurt, maar geen middelen hebt om snel in te grijpen. Je weet wel wat je moet doen om het tegen te houden, maar het gaat gewoon te snél. Tsjernobyl is ook bekend geworden vanwege een uit de hand gelopen test… het ging ineens héél snel.

Het antwoord kennen we eigenlijk wel: ontkoppelen… zorg ervoor dat je zo min mogelijk afhankelijkheden hebt tussen de dingen. En niet alleen tussen de dingen, maar ook tussen processen, afdelingen, organisaties, enz. Bouw branddeuren in. De meesten denken dus nu: “Ja dúh… dat weten we nu wel”. Dat klopt… dat dénken ze. Maar weten ze het ook écht!? Want wat is nu een branddeur in zoiets abstracts als IT?
Is ook best lastig…

Volg de signalen

Zelfs als we niet precies weten wat branddeuren zijn, zelfs als we niet weten hoe goed we ontkoppeld hebben… er zijn wel degelijk signalen. Hoe vinden we die signalen? Even een zijstapje… leg de relatie tussen incidenten en changes. Changes zou je namelijk kunnen zien als geplande incidenten. Je maakt bewust iets stuk: effe een component verwijderen, effe iets onbeschikbaar maken, effe iets aanpassen.

Wat is dan zo’n signaal? Bijvoorbeeld: hoeveel van die minor impact changes leiden nu tot major incidents? Veel? Is niet goed! Dan heb je niet voldoende ontkoppeld. Hoe vaak moeten we verhoogde dijkbewaking uit bed bellen omdat er tóch iets mis gaat tijdens een change wat we niet hadden voorzien? Vaak? Weer niet voldoende ontkoppeld. Hoe vaak blijkt de volgende dag dat er iets niet meer werkt in een heel andere hoek van de bank waar we alleen achterkomen omdat mensen ermee aan het werk willen? Vaak? …

En hoeveel moeite moeten we doen om componenten te vervangen? Hoeveel tijd en geld hebben we bijvoorbeeld nodig om aleen al tent in de lucht te houden? Wat kost het om Websphere versie X te vervangen door versie Y? Hoeveel mensen moeten we dan bellen? Als onze leverancier ergens iets kleins verandert -laten we zeggen- ze noemen iets geen “platinum" meer, maar het gaat “high" heten… hoeveel moeite moeten we dan doen om onze bestel-portal aan te passen? Veel? …dat zegt iets over de mate van ontkoppeling.

Morgen al?

De meest dodelijke vraag die ik vaak krijg: “Wat moeten we mórgen doen om dit op te lossen?” Dit is namelijk niet iets van morgen… dit is iets van langere termijn. Morgen is het verdelen van de bank in allemaal onafhankelijke agile teams… Langere termijn is het zorgen dat al die teams ook iets doen wat als geheel kan werken. Morgen kopen we een product. Op langere termijn moeten we dit weer kunnen weggooien. En dat weggooien gaat steeds sneller. Moét steeds sneller!

Wat we morgen moeten doen? Nadenken over het weggooien van alles wat we nú kopen en alles wat we nú bouwen. Als we dát kunnen, dan is IT een echt wegwerpproduct. Pas dán doen we “prepare for change”… pas dán doen we “agile".

Vaag? Yep. Nodig? Jazeker! … en dat vergt meer dan alleen één iemand die er een blogje over schrijft!

Richard Bliek

PS. Nóg iets om over na te denken: wat je nu niét koopt, hoef je later ook niet weg te gooien.