Sloopwoede in IT-land en de paradox van vervanging en onderhoud

Na maanden zoeken op Funda heb je jouw droomhuis gekocht: een ongeïsoleerd opknappertje uit de jaren ’30. Het heeft een bruine bloemetjes badkamer en een oude keuken, maar het heeft “kenmerkende details”, voldoende ruimte en ligt op een perfecte locatie. Dan, op de dag dat je de tekent voor de overdracht, komt de sloper langs wordt de hele boel plat gegooid. Klaar om “green field” een nieuw huis te bouwen.

Het bovenstaande scenario klinkt niet heel logisch. En toch komt precies dit sloop en nieuwbouw scenario veelvuldig voor in IT-land. Maar wat zit er achter de vervangingsdrang? En is die sloopwoede echt nodig of kunnen we ook een ander pad bewandelen? Want hoe houdbaar en duurzaam is het om consequent duizenden manuren werk weg te gooien ten goede van ‘het nieuwe’?

Een mismatch die geen mismatch is

De eerste gedachte zal ongetwijfeld zijn dat IT en architectuur (die van staal, beton en glas) helemaal niet vergelijkbaar zijn. Alleen de snelheid van ontwikkelingen maken deze twee werelden niet compatibel. De grootste vernieuwing in de laatste 50 jaar bouwgeschiedenis is een betonpomp die computergestuurd beweegt: een 3d printer op gebouw schaal. 50 jaar geleden moesten mensen nog 10 jaar wachten voordat de eerste IBM PC op de markt zou komen. De introductie van de iPhone is bijna 16 jaar oud en Microsoft’s cloud platform Azure is net een ‘tiener’!

Wanneer we de tijdslijnen van de ‘bouw’ door tien delen, dan blijken de overeenkomsten ineens veel groter. De schilder komt iedere 6 maanden langs om de buitenboel te verven. Ieder jaar vervang je de badkamer of keuken en eens in de twee jaar staat er groot onderhoud gepland. De paradox is dat aanpassingen aan een gebouw de geaccepteerde (vaak kostbare) standaardoplossing is, maar zodra we het over software hebben kiezen we niet voor aanpassen maar voor vervanging. We lijken in IT-land soms gevangen in een reclame voor een wasmiddel, waarbij het nieuwe wasmiddel “nu nog beter” is. Het enige dat we hoeven te doen, is de naam van het wasmiddel te vervangen door de naam van een applicatie.

De snelheid van “Nieuw en verbeterd”

Dat IT-land en de wereld er om heen razendsnel veranderen is inmiddels wel duidelijk. Een applicatie die tien jaar geleden ontwikkeld is, had mogelijk nog geen verbinding met het internet. Misschien is die connectiviteit die wel wenselijk. Een niet up-to-date gehouden IT-landschap van vijf jaar oud zit waarschijnlijk vol veiligheidsgaten. Gaten die, getuige de stijgende hoeveelheid ransomware aanvallen, grote risico’s voor de continuïteit van de organisatie vormen. Maar ondanks veranderende eisen en verschenen gebreken, is de kans groot dat de basis van de applicatie nog uitstekend op de bedrijfsvoering aansluit. Ja, er zijn nieuwe wensen. Maar nee, dat wil niet zeggen dat het oude er uit moet. “Nieuw” is niet per definitie verbeterd, terwijl “verbeterd” niet automatisch betekent dat het oude niet meer voldoet.

Veiligheid, connectiviteit en nieuwe functionaliteiten zijn een aantal van de belangrijkste drijfveren om software aan te passen of te vernieuwen. Aanpassingen die niet per definitie makkelijk in de bestaande programmatuur te implementeren zijn. De hypothetische applicatie die nooit voor ‘internet toepassingen’ ontworpen was, kan een grondige en soms langdurige update nodig hebben om een veilige koppeling met internet mogelijk te maken. Wanneer we de vergelijking met het huis trekken, hebben we het over een aan- of opbouw op het bestaande gebouw. Niet eenvoudig, meestal niet goedkoop en zeker geen snelle oplossing. Maar de aanbouw is bijna altijd minder ingrijpend dan sloop en nieuwbouw of verhuizen en de meeste processen in huis kunnen gewoon door blijven gaan.

Gelijktijdig is nieuw niet per definitie ‘veiliger’ of sneller. Sterker, voor bedrijfsspecifieke ‘op maat gemaakte oplossingen’ kan het lang duren voordat er een eindproduct geproduceerd is die de huidige functionaliteiten kan vervangen en de nieuwe eisen inwilligt. Medewerkers moeten de nieuwe applicatie leren gebruiken en bedrijfsprocessen moeten misschien worden aangepast. Daarbij bestaat er het risico dat er, in de tijd tussen de start van de bouw en de oplevering van het eindproduct, nieuwe of veranderende eisen geformuleerd worden. Eisen die ervoor zorgen dat er meer onzekerheid ontstaat en het nog langer kan duren voor er een werkend eindresultaat is. Dit is goed te vergelijken met de bouw van een nieuwe woning. Het ontwerp en de vergunningen duren vaak al maanden, de bouw duurt minimaal een half jaar en het meerwerk dat tijdens de bouw er bij komt is altijd kostbaarder en tijdrovender dan gepland.

De essentie van onderhoud

Als we terugkijken, is misschien het grootste verschil tussen de IT-wereld en de wereld van ‘glas, beton en staal’ de focus op beheer. We accepteren allemaal dat een gebouw onderhoud nodig heeft. Dat we af en toe een schilder moeten inhuren om te zorgen dat de kozijnen weer een mooie, glimmende laag verf hebben. Dat de sloten op ons huis misschien vervangen moeten worden zodat de kans op inbraak kleiner wordt. En dat we onmiddellijk de loodgieter bellen zodra we een lekkage vaststellen in de badkamer.

Onderhoud in de IT-wereld lijkt, vaker dan wordt toegeven, vooral een ‘last’ te zijn. Een nieuwe applicatie met een aantrekkelijke, hippe uitstraling is makkelijker te verantwoorden dan een moeilijke update in een back-end systeem waar bijna niemand van gehoord heeft. Het tonen van de voorraadaantallen, zodat klanten het vertrouwen hebben dat de bestelling morgen in huis is, is eenvoudiger te ‘verkopen’ dan het zorgdragen dat het systeem veilig de voorraad bijhoudt.  En juist daar schuilen de grootste risico’s in onze data gedreven wereld: de levenscyclus van software.

IT-modernisering: het belang van de levenscyclus

Net zoals gebouwen, vraagt software onderhoud. Onderhoud is een essentieel onderdeel van de levenscyclus van software. Vanaf het eerste idee, langs de architectuur en userinterface ontwerpen, via de bouw en oplevering tot uiteindelijk onderhoud en, ja, de sloop en vervanging van de applicatie: software volgt in grote mate de levenscyclus van een gebouw. Door het consequent onderhoud te plegen, software up-to-date te houden, en vooral te blijven investeren in het verbeteren van de applicatie kan de levensduur van software veilig en vaak langdurig gebruikt blijven worden.

De conclusie is dan ook dat nieuw niet slecht is, of dat ‘alles bij het oude’ moet blijven. Nieuwe software biedt vaak kansen voor de bedrijfsvoering. Maar bestaande processen moeten blijven draaien. Aan grote nieuwe releases kleven vaak grote risico’s voor (bestaande) bedrijfsprocessen. Met goed ‘lifecycle management’ kunnen deze risico’s gespreid worden en blijft kennis over de werking van de applicatie, aan zowel de voor- en achterkant behouden. Tenslotte zorgt levenscyclus beheersing er voor dat het mogelijk blijft om in te spelen op veranderingen. Om de bestaande applicaties zo vorm te geven dat ze aanpasbaar blijven en de continuïteit van de organisatie geborgd is. Maar misschien wel het belangrijkste is, om de vergelijking met een gebouw te maken, dat ze niet instorten onder de druk van de tijd.