Software bouwen is één ding. Zorgen dat het over een paar jaar nog steeds betrouwbaar, begrijpelijk en betaalbaar draait, is minstens zo belangrijk.
Voor mij is system maintenance daarom geen los onderdeel dat pas begint zodra software in productie staat. Onderhoudbaarheid begint al bij de keuzes die je maakt tijdens het ontwerpen en ontwikkelen van een systeem.
Wat is System Maintenance?
System maintenance gaat over het betrouwbaar, veilig en beheersbaar houden van software gedurende de volledige levensduur.
Dat betekent voor mij meer dan alleen bugs oplossen. Het gaat ook om:
technische schuld beheersen
dependencies en infrastructuur onderhouden
performance blijven bewaken
logging en monitoring verbeteren
oude componenten vervangen of verwijderen
kosten kritisch blijven beoordelen
systemen begrijpelijk houden voor het team dat ermee werkt
Een systeem dat technisch werkt, maar niemand meer durft aan te passen, is wat mij betreft niet goed onderhouden.
Wat vind ik belangrijk bij onderhoud?
Mijn uitgangspunt is simpel: onderhoud moet voorkomen dat complexiteit ongemerkt blijft groeien.
Daarom kijk ik niet alleen naar wat vandaag opgelost moet worden, maar ook naar de oorzaak erachter. Komt een probleem regelmatig terug, dan heeft opnieuw een tijdelijke oplossing toevoegen weinig waarde.
Ik probeer dan te begrijpen waar die complexiteit vandaan komt en hoe we het structureel eenvoudiger kunnen maken.
Dat kan betekenen dat je code herschrijft, maar soms juist dat je code, infrastructuur of zelfs een complete technologie verwijdert.
Onderhoud is voor mij daarom ook durven opruimen.
Hoe ik System Maintenance toepas
Ik probeer onderhoud zo dicht mogelijk tegen het dagelijkse ontwikkelproces aan te organiseren.
Daarbij kijk ik onder andere naar:
duidelijke verantwoordelijkheden tussen services
automatische tests rondom belangrijke functionaliteit
CI/CD om wijzigingen voorspelbaar uit te rollen
goede observability rondom processen en datastromen
foutafhandeling die past bij distributed systems
dependencies en infrastructuur die daadwerkelijk waarde toevoegen
code die ook door iemand anders eenvoudig begrepen kan worden
Zeker binnen event-driven systemen is onderhoudbaarheid belangrijk. Problemen zitten daar namelijk niet altijd in één service. Ze kunnen ontstaan door events, retries, externe databronnen of processen die verspreid over meerdere componenten plaatsvinden.
Juist dan wil je dat het systeem vertelt wat er gebeurt.
Onderhoud van bedrijfskritische systemen
Bij Port of Amsterdam lag system maintenance sterk in het verlengde van continuïteit.
Binnen het Maritime Applications Team werkte ik als Lead Java Backend Developer aan verschillende cruciale applicaties voor havenoperaties, waaronder Lock Schedule, MyPort, Applications, HAP List en de Zeehavengeld Applicatie.
Bij zulke systemen kun je niet zomaar technologie vervangen omdat iets nieuws interessanter lijkt. Betrouwbaarheid en bedrijfscontinuïteit wegen zwaar.
Dat vraagt om eerst begrijpen wat een systeem doet, wie ervan afhankelijk is en waar de echte risico's zitten. Daarna kun je bepalen welke verandering daadwerkelijk verbetering oplevert.
Onderhoudbaarheid begint bij eenvoud
Ik zie vaak dat maintenance duur wordt omdat systemen door de jaren heen steeds meer uitzonderingen, abstracties en technologieën verzamelen.
Mijn voorkeur is daarom bewust eenvoudig blijven.
Niet iedere uitdaging vraagt om een nieuwe service, database of framework. Soms is het verwijderen van een component waardevoller dan het toevoegen van een nieuwe.
Een goede architectuur maakt verandering makkelijker. Een goede maintenance-strategie zorgt ervoor dat dit zo blijft.
Wat ik vaak zie in het werkveld
Systemen worden uitgebreid voordat iemand ze echt begrijpt
Er wordt soms snel naar een technische oplossing gegrepen, terwijl nog niet duidelijk is waar het echte probleem zit. Dat levert vaak extra complexiteit op die later weer onderhouden moet worden.
Technical debt wordt te lang uitgesteld
Technical debt is niet direct een probleem, zolang het bewust wordt geaccepteerd. Het wordt vervelend wanneer tijdelijke oplossingen permanent worden en niemand meer precies weet waarom bepaalde keuzes ooit zijn gemaakt.
Technologie blijft bestaan omdat die er nu eenmaal staat
Een database, service of framework wordt soms jarenlang onderhouden zonder opnieuw te kijken of het nog waarde toevoegt. Ik vind dat je die vraag juist regelmatig moet blijven stellen.
Onderhoud wordt gezien als werk naast development
Voor mij hoort onderhoud bij software development. Refactoring, monitoring, tests en het vereenvoudigen van bestaande oplossingen zijn net zo goed onderdeel van het bouwen van software.
Complexiteit wordt te makkelijk geaccepteerd
Niet ieder complex probleem heeft een complexe technische oplossing nodig. Vaak zit de grootste winst juist in het terugbrengen van verantwoordelijkheden, afhankelijkheden en uitzonderingen.