Ontwikkelaars houden niet van Bloemkool!

Laats hoorde ik een prachtige beeldspraak: “Bij de aanschaf van een nieuw bankstel denk je na wat je met het oude gaat doen. Geven we het aan de kinderen, zetten we het op marktplaats, brengen we het naar de kringloopwinkel of naar het grof vuil? Stel je eens voor dat we hetzelfde doen als bij bestaande IT-systemen. We zetten onze nieuwe sofa gewoon bovenop de oude bank. Vervolgens na een aantal jaar een nieuwe daar bovenop. Het gebruik wordt er niet eenvoudiger van, om nog maar te zwijgen over het stofzuigen en afstoffen.  Toch is dit precies wat wij in de IT-wereld doen.”

Het fenomeen waar de beeldspraak over ging heeft een naam: bloemkoolautomatisering. Om allerlei redenen – zoals project, planning, roadmap, budget – is er van bovenaf besloten om bepaalde nieuwe functionaliteit toe te voegen aan het bestaande systeem. Gewoon omdat het huidige systeem er al is of omdat het te complex, duur of politiek onhandig is om een nieuw traject te starten. De realisatie wordt ondergebracht bij het beheer (of DevOps als we in een modern bedrijf werken) en de financiering komt uit het onderhoudsbudget. Dit alles gebeurt niet eenmalig, maar meerdere keren. Iedere keer komt er een nieuwe stronk functionaliteit bij de bloemkool. En er gaat nooit iets weg. Zo ‘stronken’ we ons richting een situatie waarin het volledige it-budget wordt opgesoupeerd aan het in de lucht houden van de systemen die we de afgelopen jaren zelf hebben gemaakt. Geen geld meer voor vervanging, laat staan voor innovatie. We bloemkolen onszelf volledig vast.

Op de een of andere manier is het makkelijker een bestaand systeem uit te bouwen dan nieuw systeem of architectuur goedgekeurd te krijgen. Als je, zoals ik, al een tijdje in de IT rondloopt herken je dit ongetwijfeld.

Complexiteit maakt besluitvormig lastig

Veel directies vinden het lastig om de aard en omvang van hun it-landschap te overzien. Niet omdat ze incapabel zijn, maar omdat de omvang en complexiteit van de huidige it-systemen het lastig maken  om dit in zijn geheel te overzien. Het goedkeuren van een wijziging op een bestaand systeem klinkt dan vaak eenvoudiger dan besluitvorming over zo’n nieuw systeem of een compleet nieuwe architectuur.

De verplichte weggooi-paragraaf!

Terug naar de gestapelde Sofa’s. Vergelijk een nieuw IT-project met deze aanschaf in de huiselijke sfeer. Neem bij ieder systeem de lifecycle fase mee in de beslissing. Wat zijn de kosten van onderhoud en wat zijn de kosten van nieuwbouw? Ik adviseer om bij ieder projectvoorstel verplicht  een paragraaf ‘Wat gaan we na dit project weg gooien?’ op te nemen. Hiermee verplicht je het projectteam om na te denken over het vervangen van bestaande systemen terwijl we bezig zijn met het toevoegen van nieuwe functies en het vergroten van de bloemkool tot proporties waar als ontwikkelaar geen eer meer aan te behalen is.

Ook het opdelen van je landschap in een architectuur van microservices is in de basis geen oplossing, al zijn ontwikkelaars daar sneller voor te porren. Zonder een ‘wat gooien we weg’-regel is dit alleen maar het splitsen van een grote bloemkool in een grote schaal aan kleinere stronken.

Mijn pleidooi is dus: blijf nadenken over wat we moeten opruimen voordat we iets nieuws starten. Alleen al het stellen van de vraag is een goede start. Als het plan voor het nieuwe systeem een gedegen strategie bevat voor de vervanging van een aantal bestaande systemen, dan vormt het een goede basis voor de verdere ontwikkeling en lifecycle management van de totale it-infrastructuur. Zit dit plan er niet bij, dan is er een grote kans dat er een nieuwe stronk aan je bloemkool in de maak is.

En ontwikkelaars houden niet van bloemkool. Ik ook niet, met of zonder papje!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *