Waarom stabiele systemen de échte helden zijn
Iedere organisatie wil vernieuwen. Innovatie, digitalisering, kunstmatige intelligentie – het zijn de toverwoorden die op iedere directieagenda staan. Nieuwe projecten krijgen energie, aandacht en budget. Maar ondertussen rust de dagelijkse operatie vaak op systemen die tientallen jaren geleden zijn ontwikkeld. En daar wringt het: onderhoud krijgt zelden dezelfde waardering als vernieuwing.
Toch is onderhoud geen luxe, maar een randvoorwaarde voor continuïteit én innovatie. Tijd voor een ode aan onderhoud.
De menselijke aard: liever nieuw dan bestaand
Er zit iets diep menselijks in onze voorkeur voor het nieuwe. Een gloednieuwe auto, een frisse werkomgeving of de nieuwste softwareversie voelt aantrekkelijker dan het bestaande. Ook in de IT is dat zichtbaar.
Ontwikkelaars hebben vaak een natuurlijke hang naar nieuw. Nieuwe frameworks, nieuwe tools – een kans om met een schone lei te beginnen. Nieuwbouw is leuker dan blijven werken in een landschap vol technische schuld. Beheerders daarentegen voelen de verantwoordelijkheid om het bestaande stabiel te houden. Hun grootste winst is dat het morgen ook weer gewoon werkt.
Beide perspectieven zijn waardevol, maar het probleem ontstaat wanneer ze elkaar uitsluiten. Vernieuwing zonder onderhoud leidt tot chaos. Alleen behouden zonder meebewegen leidt tot stilstand – en stilstand ís achteruitgang. Dit is waarom in mijn ogen concepten als DevOps en BizDevOps in opkomst zijn: ze doorbreken de traditionele scheiding tussen bouwen en beheren, en maken onderhoud een integraal onderdeel van vernieuwing en voortbrenging.
De realiteit van onderhoud
In mijn jaren als IT-architect bij grote organisaties, waaronder grote Rijksoverheidsorganisaties, zag ik hoe onderhoud voortdurend onder druk stond. Niet omdat het onbelangrijk is, maar omdat het minder aantrekkelijk lijkt dan een groot vernieuwingstraject of nieuwe functionaliteiten.
Uit interne en externe kwaliteitsmetingen werd duidelijk: sommige applicaties waren ooit bedoeld om de tand des tijds te doorstaan, maar waren daar in de praktijk niet tegen bestand. Onderhoud werd te laat of niet gesignaleerd of te lang uitgesteld – en de prijs daarvan werd pas zichtbaar toen het te laat was.
De metafoor van de tegeltjes
Wanneer een nieuw gebouw wordt opgeleverd, moet alles perfect zijn. Een gebroken tegeltje bij de opening? Dat wordt meteen vervangen. De aannemer staat klaar en de reserve tegels liggen op voorraad.
Maar jaren later is dat anders. De aannemer is verdwenen, de reservevoorraad is op en vervangende tegels blijken moeilijk te vinden. Vaak laten we het voor wat het is: “Het gebouw functioneert toch nog?”
Ondertussen stellen gebruikers nieuwe eisen. Het gebouw was nooit ontworpen om onbeperkt mee te veranderen. Uiteindelijk wordt het verouderd verklaard en vervangen door nieuwbouw die beter aansluit bij de eisen van die tijd.
Bij software is het niet anders. Kleine gebreken worden genegeerd of tijdelijk opgelapt. Documentatie veroudert, kennis verdwijnt. Totdat vervanging onvermijdelijk is – vaak tegen hoge kosten en risico’s.
Onderhoud op het snijvlak van architectuur, agile en lifecycle management
Het organiseren van onderhoud is geen puur technisch of organisatorisch vraagstuk. Het vraagt om samenhangende keuzes op het snijvlak van architectuur, agile werken en lifecycle management.
In agile omgevingen ligt de focus vaak op het realiseren van nieuwe functionaliteit. De lange termijn – de technische levensvatbaarheid – raakt daardoor makkelijker uit beeld. Architectuur kan hier een verbindende rol spelen tussen strategische keuzes, iteratieve realisatie en lifecycle-afspraken, zoals versies, ondersteuning en end-of-life.
Daarbij helpt het om onderhoud niet als één homogene activiteit te zien, maar te onderscheiden in de bekende vier typen:
- Correctief onderhoud – het herstellen van fouten en verstoringen.
- Adaptief onderhoud – aanpassen aan veranderde omstandigheden (bijvoorbeeld platformupdates).
- Perfectief onderhoud – verbeteren van prestaties en kwaliteit.
- Preventief onderhoud – problemen voorkomen door tijdige ingrepen.
Geen van deze termen is “sexy”, maar ze zijn stuk voor stuk essentieel om systemen gezond te houden.
De basis begint bij ontwerp: bedrijfskritische systemen en levensduur
Deze ode aan onderhoud gaat vooral over bedrijfskritische systemen – de ruggengraat van organisaties, waar stabiliteit en betrouwbaarheid boven alles gaan. Juist bij dit soort systemen begint onderhoud niet ná de oplevering, maar al vóór de eerste eisen op papier staan. Voordat de eerste regel code wordt geschreven, moet worden bepaald wat een realistische levensduur is van het systeem of ecosysteem als geheel.
Die levensduurverwachting bepaalt namelijk hoe je de architectuur ontwerpt, hoeveel flexibiliteit je inbouwt en hoe je onderhoud organiseert. Een systeem dat vijf jaar mee moet, ontwerp je anders dan een systeem dat twintig jaar moet functioneren.
De realisatietijd en de omvang van het systeem zijn hierin bepalend. Hoe groter en complexer het landschap, hoe belangrijker het is om modulariteit bewust mee te ontwerpen. Alleen zo kun je onderdelen vervangen, verbeteren of moderniseren zonder dat het hele systeem moet worden afgebroken.
Onderhoud is dus niet iets wat je achteraf organiseert – het is een ontwerpbeslissing.
De essentie: meebewegen
De oplossing ligt in balans. Ontwikkelaars hoeven niet voortdurend te vernieuwen, beheerders moeten leren meebewegen. En organisaties moeten van tevoren bepalen hoe lang een systeem mee moet gaan – dat bepaalt de architectuurkeuzes en onderhoudscyclus.
Een goed georganiseerde onderhoudsaanpak rust op drie pijlers:
- Zichtbaarheid: onderhoud moet meetbaar en bespreekbaar zijn.
- Regelmaat: onderhoudswerk moet gepland, niet ad hoc, plaatsvinden.
- Eigenaarschap: iemand moet verantwoordelijk zijn voor de technische levensvatbaarheid.
Een kwestie van waardering
Onderhoud is onzichtbaar wanneer het goed gaat, maar onmisbaar zodra het faalt. Het verdient dezelfde aandacht als innovatie. Net als bruggen en dijken moet ook software onderhouden worden om veilig te blijven.
De echte helden zijn niet degenen die de nieuwste applicatie opleveren, maar degenen die ervoor zorgen dat alles elke dag blijft werken.
Conclusie: onderhoud ís vooruitgang
Wie vandaag onderhoud negeert, betaalt morgen de prijs van achterstallige innovatie.
Een ode aan onderhoud is dus meer dan een lofzang: het is een pleidooi voor een bewuste, strategische en structurele aanpak van onderhoud – op het snijvlak van architectuur, agile werken en lifecycle management.
Innovatie mag de toekomst brengen, maar onderhoud zorgt dat we er ook veilig aankomen.
Zes aanbevelingen om onderhoud structureel te organiseren:
- Strategisch verankeren
Zie onderhoud als waardebehoud, niet als kostenpost. Leg in beleid en architectuurprincipes vast wat correctief, preventief, adaptief en perfectief onderhoud omvat. Wijs per applicatie een lifecycle owner aan. - Governance en prioritering
Reserveer structureel capaciteit (15–25%) voor beheer en onderhoud in teams en maak het een vast onderwerp in portfolio- en PI-overleggen. Gebruik lifecycle-dashboards om veroudering zichtbaar te maken. - Gepland uitvoeren
Voer onderhoud niet ad hoc uit maar plan vaste vensters. Werk met component-roadmaps waarin LTS- en EOL-data zijn opgenomen. Combineer waar mogelijk adaptieve upgrades met perfectieve verbeteringen. - Transparantie in tooling
Label onderhoudswerk in backlogtools en maak de verdeling tussen features en onderhoud zichtbaar. Automatiseer dependency- en security-scans zodat risico’s vroegtijdig aan het licht komen. - Cultuur en gedrag
Stimuleer trots op goed beheer: onderhoud is de basis van continuïteit en wendbaarheid. Beloon teams ook voor technische gezondheid, niet alleen voor feature-velocity. - Meten en signaleren
Monitor de leeftijd van componenten, technical debt en defect-trends. Stel drempelwaarden vast en gebruik heatmaps waarin technische risico’s zichtbaar zijn naast businessprioriteiten.