“Waarom moeten we hier tijd aan besteden? De applicatie werkt toch?”
Het is een begrijpelijke vraag. Gebruikers kunnen inloggen, bestellingen komen binnen en rapportages verschijnen op tijd. Waarom zou je budget aan onderhoud besteden als je daarmee ook een nieuwe functie kunt bouwen?
Bij een brug is het antwoord makkelijker. Iedereen begrijpt dat een brug inspecties nodig heeft, dat onderdelen vervangen moeten worden en dat je daar geld voor reserveert, ook als er vandaag gewoon verkeer overheen rijdt. Bij maatwerksoftware is dat onderhoud minder zichtbaar, en daardoor is het vaak het eerste wat naar achteren schuift.
Een brug is nooit klaar
Neem de Van Brienenoordbrug. De brug is ruim zestig jaar oud en er rijden dagelijks zo’n 250.000 voertuigen overheen.
Rijkswaterstaat meldde in juni 2026 dat de brug door de jaren heen steeds zwaarder is belast, omdat er meer en zwaarder verkeer overheen gaat. De vernieuwing is een omvangrijk project, en tot die klaar is blijven inspecties en onderhoud nodig om de brug veilig te kunnen gebruiken. (Bron: Rijkswaterstaat, projectoverzicht).
Met software gaat het net zo. Je bouwt iets voor een bepaald gebruik, binnen de omstandigheden van dat moment, en daarna gaat de wereld verder.
Een applicatie die ooit een klein team ondersteunde, wordt onderdeel van het dagelijkse werk van honderden mensen. Er komen koppelingen en gegevens bij, de wetgeving verandert en de eisen aan beschikbaarheid en beveiliging schuiven op. De oorspronkelijke oplossing kan uitstekend zijn geweest. Je moet alleen blijven nagaan of die nog past bij wat je er inmiddels van vraagt.
Software “slijt” door wijzigingen
De bruggenbouw kent een vorm van slijtage die goed op software past: vermoeiing. In een stalen brug ontstaan scheuren door miljoenen passerende voertuigen, die elk afzonderlijk geen kwaad doen.
In software werkt elke wijziging zo. Een snelle aanpassing of een uitzondering voor één klant is op zichzelf onschuldig. Na een paar jaar vol van zulke wijzigingen heb je code die niemand meer durft aan te raken.
Software heeft, net als een brug, ook bewegende delen. Bij de Van Brienenoordbrug is volgens Rijkswaterstaat het beweegbare deel “technisch het meest dringend toe aan vernieuwing”. Het gaat om de brugkleppen, de aandrijving en de systemen waarmee de brug wordt bediend en bewaakt.
In maatwerksoftware zijn de koppelingen met andere systemen en de onderdelen van anderen waarop je bouwt die bewegende delen. Een framework krijgt een nieuwe versie en de oude verliest support. Een leverancier wijzigt een koppeling. In een onderdeel dat al jaren probleemloos draait, wordt een kwetsbaarheid ontdekt. En de server moet bijgewerkt worden. Dat gebeurt allemaal buiten je eigen code, maar je moet er wel op reageren.
Ook binnen de organisatie verandert er van alles. Medewerkers vertrekken en nemen kennis mee, werkprocessen krijgen uitzonderingen, en een tijdelijke oplossing blijft bestaan omdat iedereen eraan gewend is geraakt.
Ondertussen toont de applicatie nog steeds hetzelfde scherm, waardoor je niet ziet hoeveel er daaronder veranderd is. “Het werkt nog” vertelt je iets over vandaag. Het zegt weinig over hoe makkelijk je morgen een beveiligingsupdate of een noodzakelijke wijziging kunt doorvoeren.
Uitstel maakt de volgende stap vaak groter
Een update overslaan is niet meteen een probleem. Soms is uitstellen zelfs verstandig, bijvoorbeeld omdat je eerst wilt zien of een nieuwe versie stabiel is, of omdat je de wijziging op een rustiger moment wilt plannen.
Het wordt lastiger wanneer uitstel de standaard wordt. Dan moeten er op een gegeven moment meerdere onderdelen tegelijk bijgewerkt worden, omdat de nieuwe versie van het ene onderdeel alleen werkt met een nieuwere versie van het andere. Intussen zijn de tests verouderd en weet niemand meer precies waarom die ene uitzondering ooit is ingebouwd. Wat een overzichtelijke onderhoudsklus had kunnen zijn, is een verbouwing geworden.
Wat er gebeurt als onderhoud te laat komt, zagen we begin september bij de Hardenbergerbrug in de A28 bij Nijkerk. Rijkswaterstaat moest de brug in beide richtingen afsluiten, omdat er rond de pijlers zoveel zand en grind was weggespoeld dat de veiligheid niet meer gegarandeerd kon worden. Het herstel stond al voor november gepland, maar de situatie was sneller verslechterd. Het gevolg waren files op de omliggende wegen en extra kosten voor vrachtwagens die moesten omrijden (bron: NOS).
“Iets in stand houden is niet sexy”, zei Richard Loendersloot, hoogleraar engineering dynamics aan de Universiteit Twente, daarover tegen de NOS.
Volgens hem kun je met vroeg onderhoud de groei van scheurtjes stoppen of beperken. Zijn ze eenmaal ver gegroeid, dan moet je hele onderdelen vervangen, en hoe langer je wacht, hoe duurder dat wordt.
Bij bedrijfssoftware is dat niet anders. Ook daar kun je werkzaamheden niet altijd uitvoeren op het moment dat ze onvermijdelijk worden. De organisatie blijft met de software werken terwijl jij aanpassingen doet. Gegevens moeten behouden blijven, koppelingen moeten blijven werken en gebruikers kunnen niet een paar weken stoppen. Met regelmatig onderhoud houd je die veranderingen kleiner en beter te plannen.
Goed onderhoud valt nauwelijks op
Een nieuwe functie kun je laten zien: een gebruiker klikt ergens op en er gebeurt iets wat gisteren nog niet kon.
Onderhoud laat zich lastiger demonstreren. Een ondersteunde softwareversie ziet er vaak precies zo uit als de vorige. Betere monitoring merk je pas als er iets misgaat, en een geteste herstelprocedure lijkt overbodig tot je haar nodig hebt.
Daarom moeten we als softwaremakers goed uitleggen wat onderhoud oplevert. Met “het framework moet worden bijgewerkt” heeft een opdrachtgever weinig. Die wil weten wat er gebeurt als we het laten liggen: kunnen we straks nog beveiligingsupdates toepassen, blijven noodzakelijke wijzigingen mogelijk en kunnen we herstellen als het systeem uitvalt?
Voor dat gesprek heb je concrete informatie nodig. Welke onderdelen verdienen aandacht, wat kan wachten, en wat wordt duurder of moeilijker als we het laten liggen? Met die antwoorden kun je samen een afweging maken.
Niet alles hoeft steeds de nieuwste versie te hebben
Onderhoud betekent ook kiezen. Een stabiele applicatie hoeft niet opnieuw gebouwd te worden alleen omdat er een nieuw framework verschijnt.
Wat verstandig is, hangt af van het gebruik en de verwachte levensduur. Voor een tijdelijke toepassing gelden andere eisen dan voor een systeem waarop een belangrijk bedrijfsproces draait. En een onderdeel dat nog goed ondersteund wordt, vraagt om een andere afweging dan een onderdeel waarvoor geen beveiligingsupdates meer verschijnen.
Vaak is bijwerken genoeg. Soms kun je een kwetsbaar onderdeel gericht vervangen, en soms is het beter om een toepassing af te bouwen of uit te zetten.
Daarvoor moet je wel weten wat je hebt, wie ervan afhankelijk is en in welke staat het verkeert. Zonder dat overzicht bepaalt al snel het eerstvolgende incident welke onderhoudsbeslissing je neemt.
Sneller bouwen vraagt ook om nadenken over later
Met AI kun je sneller software ontwikkelen, waardoor meer ideeën binnen bereik komen. Een kleine automatisering of een applicatie voor één specifiek proces kan ineens de moeite waard zijn.
Zodra mensen erop gaan vertrouwen, moet iemand verantwoordelijk zijn voor het vervolg. Bij een brug weet je wie de beheerder is: Rijkswaterstaat, de provincie of de gemeente. Die houdt de staat van de brug in de gaten en beslist wanneer er iets moet gebeuren. Bij een applicatie die in een paar dagen is gebouwd, is dat vaak niet geregeld. Niemand houdt dan bij of de gebruikte onderdelen nog ondersteund worden, niemand merkt het als er iets misgaat, en over twee jaar weet niemand of de toepassing nog nodig is.
AI kan helpen bij updates, bij het uitzoeken van fouten en bij het schrijven van tests, en dat maakt onderhoud makkelijker. Wie de beheerder is, moeten we nog steeds zelf bewust besluiten. Als bouwen goedkoper wordt, is het verstandig een deel van die winst te gebruiken om bestaande software gezond te houden.
De oplevering is het begin van het gebruik
Bij maatwerksoftware praten we vooral over de weg naar de eerste oplevering: wat het moet kunnen, wanneer het klaar is en wat het kost. Vanaf het begin hoort daar ook een gesprek bij over de jaren erna. Wie is waarvoor verantwoordelijk, hoe regelen we onderhoud, en hoe blijft het systeem meebewegen met de organisatie?
Dat dit loont, zien we bij Mijngastouderburo.nl. Daarvan schreven we 15 jaar geleden de eerste code, en we ontwikkelen en onderhouden het nog altijd samen met ViaViela. In die tijd hebben verschillende Kabisanen aan de code gewerkt, en is de applicatie steeds meebewogen met wat ViaViela nodig had.
Een brug bewijst haar waarde doordat mensen er jarenlang op kunnen vertrouwen, en van software verwacht je hetzelfde.
Dus als iemand vraagt: “Waarom onderhoud? Hij doet het toch nog?”, dan is dat een goed moment om vooruit te kijken. Juist nu het systeem nog goed werkt, hebben we de ruimte om te zorgen dat dat zo blijft.
Hoe staat jouw software ervoor?
Werkt jouw applicatie nog prima, maar weet je niet zeker hoe het zit met onderhoud, beveiliging en toekomstige aanpassingen? Bij Kabisa denken we graag mee over wat nu aandacht verdient en wat verantwoord kan wachten, ook als je twijfelt tussen verder ontwikkelen en vervangen.
Neem contact met ons op, dan bespreken we samen hoe jouw software betrouwbaar blijft en kan meegroeien met je organisatie.
