Koop ik een nieuwe auto of investeer ik nog in mijn oude? Het is een keuze waar autobezitters helaas wel eens voor komen te staan. En wie kent niet het gevoel dat de enkele reparatie wel meevalt in vergelijking met de kosten van een nieuwe auto, maar dat achteraf en opgeteld alle reparaties en alle dagen dat je even niet kon rijden wel erg kostbaar en irritant waren? Mensen die in een oud brik doorrijden worden vaak meewarig aangekeken. Merkwaardigerwijs geldt hetzelfde de laatste tijd voor organisaties die juist kiezen voor nieuwe ICT.

Vragen over de vervanging van auto's en van ICT lijken op elkaar. Hoe lang kan het oude systeem nog mee en worden opgelapt? Hoe vaak krijg ik dan onverwacht onderhoud en lange zoektochten naar de oorzaak van een probleem? Hoeveel is me dat waard? En kan het oude systeem mijn nieuwe eisen wel aan?

Eerder schreef ik een column over de oproep van Chris Verhoef om vooral in stapjes te vernieuwen. Ik vergeleek het met alle onderdelen van een auto stapsgewijs vervangen. Ik heb niet zoveel met nieuwe auto’s, dus stond waarschijnlijk wat vaker dan gemiddeld voor de keuze om nog een keer te investeren of een nieuwe tweedehandse aan te schaffen. Gelukkig koos ik vaak tijdig voor dat laatste.

Maar wanneer kies je als het gaat om ICT voor doorgaan met het oude en wanneer voor iets nieuws? Dat vraagt, net als bij auto’s, een “diepgaand onderzoek op pijnpunten” zoals Chris Verhoef het noemt. Hoe verweven is de code of juist hoe modulair, hoe veilig, hoe begrijpelijk, hoe kwetsbaar, hoe schaalbaar? Kan het nieuwe eisen aan, of niet? Pas na een goede analyse kun je kiezen wat verstandig is.

Voor het beoordelen van softwarekwaliteit bestaat een ISO-norm. Die beschrijft helaas vooral kwaliteitskenmerken en is dus weinig concreet. Ik wil namelijk de vraag kunnen stellen “wat zijn de voordelen en de nadelen van het kopen van een nieuwe auto en van het houden van mijn oude in het licht van mijn vervoerswensen”, en daar dan een antwoord op krijgen dat niet afhankelijk is van de specifieke monteur maar gebaseerd is op een analyse waar de hele garagebranche het over eens is. Of, in ICT termen, ik wil code kunnen laten analyseren en aanhouden tegen (nieuwe of bestaande) eisen en op basis van een door iedereen geaccepteerde norm weten wat de risico's en kansen zijn van doorontwikkelen en van nieuwbouw.

Afgelopen weken lieten wij zo'n analyse doen voor een specifiek ICT-systeem. Van dat bestaande systeem werd de code doorgelicht en aangehouden tegen nieuwe eisen (10 maal zo hoog volume, bijvoorbeeld). De conclusie: nieuwbouw of verbouw zijn ongeveer even duur en zullen ongeveer even lang duren. Maar de risico’s voor onder meer uitval bij hoog volume zijn in het nadeel van verbouw. Op dat soort doorwrochte analyses van de broncode onder de motorkap kun je beslissingen nemen. Helaas is daar nog geen standaardaanpak voor en zijn de analyses van verschillende monteurs vaak heel verschillend.

Vandaar mijn oproep aan iedereen die zich bezig houdt met het toetsen van softwarekwaliteit: kom tot een norm. Een NEN-norm bijvoorbeeld, met daarin een industriestandaard (gebaseerd op ISO 25010) om op basis van analyse van broncode expliciet de kansen en risico’s van doorontwikkeling versus nieuwbouw te schetsen. Ik zou erg blij zijn met een dergelijke gestandaardiseerde aanpak. Dan ontstaan namelijk analyses over de gevolgen van nieuwbouw en verbouw waar een bestuurder of CIO echt iets mee kan en die ook de toets der kritiek van auditors en anderen kan doorstaan.

The biggest risk is not taking any risk. In a world that is changing really quickly, the only strategy that is guaranteed to fail is not taking risks. (Mark Zuckerberg)

Deze uitsprak kwam in mij op toen ik de column van Chris Verhoef over beheerst vernieuwen las.

In zijn betoog pleit Chris, terecht, ervoor om niet zomaar hele ICT-systemen ineens te vernieuwen. Veel beter is het, zo stelt hij, om stap voor stap te vernieuwen.

En juist daar zit een paradox. Want systemen die stap voor stap te vervangen zijn, die waren daartoe al voldoende op orde. Daar kon je stukjes uithalen en beheerst vernieuwen. Als dat kan, dan moet je vooral niet tot volledige nieuwbouw overgaan. Hoewel, zelfs dat is niet altijd waar. Je kunt prima alle onderdelen van een auto stuk voor stuk vervangen. De ene maand de versnellingsbak, dan de motor, dan het chassis en ga zo maar door. Maar een nieuwe auto is soms echt verstandiger, goedkoper en gaat weer langer mee. En van een auto een heel nieuw vervoersmiddel maken (de drone-auto van Audi en Airbus bijvoorbeeld) door stuk voor stuk de onderdelen te vervangen, het lijkt me nogal lastig.

Juist organisaties die niet snappen dat hun bestaande systemen hun grootste bezit zijn, zijn onvoldoende toegerust voor grootschalige nieuwbouw. Hoe vaak doet men dat, zulke nieuwbouw? Gezien de omvang van dit soort programma’s: nooit! (Chris Verhoef)

Beste Chris, om aan te tonen dat “nooit” niet waar is nodig ik je uit voor een bezoek aan het CIZ. Deze organisatie verving in 2014 haar hele ICT-landschap. Een landschap van meer dan 7000 functiepunten dat in 1 keer vervangen werd. Maar niet onbeheerst. De hele organisatie was betrokken (oh ja, ze gebruikten een “agile” aanpak, één van de buzzwoorden die jij "toeten-nog-blazen-prietpraat" noemt) en elke week werd de gemaakte code tegen het licht gehouden. Niet goed genoeg? Dan opnieuw.

Hoeveel ICT-systemen ken jij die zo blijvend van hoge kwaliteit zijn? Door die aanpak is er nu een ICT-landschap dat elke paar weken, via geautomatiseerd testen, nieuwe functionaliteit in productie kan brengen. Er is aantoonbaar sprake van software van hoge kwaliteit. En, nog belangrijker, een nieuwe wet (voor kenners: de WLZ als opvolger van de AWBZ) kon zonder gedoe in de systemen verwerkt worden.

Ik pleit niet voor onbeheerst risico’s nemen. Maar de tegenhanger “altijd veilig en in kleine stapjes” is in sommige gevallen juist “guaranteed to fail”. De crux wat mij betreft? Van te voren heel goed weten of kleine stapjes mogelijk zijn (daarover hier meer) en als dat niet kan dan juist heel beheerst grote stappen nemen.