Twintig jaar geleden was ik architect van een maatwerkapplicatie voor een klant.
Vandaag draait die applicatie nog altijd.
Dat zegt iets over de oplossing die toen gebouwd werd, maar vooral over de manier waarop ze in de organisatie een vaste plaats kreeg. Software blijft zelden zo lang relevant als ze geen echte rol speelt in de dagelijkse werking.
Wat ik minstens even belangrijk vind: de samenwerking met die klant staat vandaag nog altijd sterk.
Bij maatwerksoftware bouw je niet alleen functionaliteit. Je raakt aan processen, gewoontes, verantwoordelijkheden en beslissingen. Als de samenwerking twintig jaar later nog altijd goed zit, ontstaat er ruimte om opnieuw samen naar de toekomst te kijken.
Twintig jaar samenwerking helpt. Je kent de geschiedenis van de toepassing, je begrijpt beter waarom bepaalde keuzes ooit gemaakt zijn en je kan opener spreken over wat moet blijven werken en wat beter kan.
Vandaag kijken we samen naar een herbouw van die applicatie.
De bestaande toepassing werkt nog goed. Ze ondersteunt nog altijd het proces waarvoor ze ooit gebouwd werd. Zonder nieuwe technologische mogelijkheden had ze waarschijnlijk nog een tijd kunnen blijven draaien.
Toch is dit een goed moment om opnieuw naar de fundamenten te kijken.
Waarom een werkende maatwerkapplicatie toch herbouwen?
Een maatwerkapplicatie herbouwen is voor een KMO geen kleine beslissing, zeker niet wanneer de huidige toepassing nog doet wat ze moet doen.
Gebruikers kennen de applicatie. Processen zijn erop afgestemd. De organisatie heeft geleerd hoe ze ermee werkt. Daardoor voelt een herbouw op het eerste gezicht vaak alsof je opnieuw investeert in iets dat al bestaat.
Dat verklaart waarom dit soort traject vroeger moeilijk te verantwoorden was. Technisch kon een herbouw zinvol zijn, maar financieel bleef de drempel hoog zolang de bestaande software haar werk bleef doen.
AI-ondersteunde ontwikkeling verandert die realiteit niet magisch, maar verlaagt wel een deel van de praktische drempel. Bepaalde stappen kunnen vandaag efficiënter verlopen: bestaande logica begrijpen, documentatie voorbereiden, testscenario’s uitwerken en repetitieve onderdelen bouwen.
De investering blijft serieus, maar de verhouding tussen inspanning en meerwaarde wordt anders.
AI neemt het denkwerk daarbij niet over. Bij bedrijfskritische software blijven procesbegrip, architectuur, security, datamigratie en validatie met gebruikers essentieel.
Als een deel van het traject efficiënter kan, komt herbouw voor een KMO wel sneller binnen bereik.
Dat maakt deze case interessant. De bestaande applicatie hoeft niet eerst een probleem te worden vooraleer het zinvol is om opnieuw naar de fundamenten te kijken.
Legacy modernisering begint met respect voor wat werkt
Het woord legacy klinkt vaak alsof er iets mis is, wat zeker niet altijd terecht is.
Een toepassing die twintig jaar meegaat, heeft meestal vooral bewezen dat ze waarde had. Ze paste bij de werking. Ze ondersteunde belangrijke processen. Ze werd onderdeel van de manier van werken, waarmee je zorgvuldig moet omgaan.
Bij legacy modernisering vervang je niet alleen code. Je raakt ook aan gewoontes, uitzonderingen, controles en kennis die doorheen de jaren in het systeem zijn gegroeid.
Wie een maatwerkapplicatie herbouwt, moet dus eerst begrijpen welke businesslogica behouden moet blijven. Welke stappen zijn kritisch? Welke uitzonderingen komen vaak voor? Welke rapporten of controles zijn belangrijker dan ze op het eerste gezicht lijken?
Een herbouw is pas zinvol als je die context meeneemt.
Van bestaande toepassing naar moderne webapplicatie
De nieuwe applicatie wordt een webapplicatie. Dat klinkt vandaag vanzelfsprekend, maar het gaat om meer dan gebruiksgemak.
Een moderne webapplicatie maakt beheer eenvoudiger. Gebruikers kunnen centraler werken. Toegang kan beter gecontroleerd worden. Updates kunnen gestructureerder uitgerold worden. Integraties worden eenvoudiger. Monitoring en logging kunnen van bij het begin meegenomen worden.
Omdat de toepassing webgebaseerd wordt, hebben gebruikers alleen nog een browser nodig. Daardoor werkt ze op verschillende toestellen en besturingssystemen.
Ook veilig werken op afstand wordt beter ondersteund. Dat is vandaag veel normaler dan twintig jaar geleden, maar het vraagt wel een andere technische basis.
Security hoort bij de basis van bedrijfskritische software
Security krijgt vandaag een andere plaats dan twintig jaar geleden.
Sterke authenticatie, tweefactorauthenticatie, correct rechtenbeheer en duidelijke logging zijn geen extraatjes meer. Ze horen bij de basis van een bedrijfskritische applicatie.
Twintig jaar geleden lag de focus vooral op functionaliteit. Het proces moest digitaal ondersteund worden en betrouwbaar werken. Dat blijft belangrijk, maar de omgeving errond is complexer geworden.
Applicaties hangen vaker samen met andere systemen. Data is gevoeliger. Gebruikers werken op andere manieren. Verwachtingen rond beschikbaarheid en veiligheid liggen hoger. Bij herbouw vertrekken we daarom opnieuw van de praktijk van vandaag.
We kijken hoe mensen de toepassing gebruiken, welke processen veranderd zijn en welke keuzes nodig zijn om de applicatie de komende jaren veilig, onderhoudbaar en betrouwbaar te houden. Van daaruit bouwen we verder.
Bewuste technologiekeuzes: Docker, .NET en PostgreSQL
Voor deze herbouw kiezen we bij dotNET lab voor Docker-containers, .NET en PostgreSQL.
Die combinatie geeft ons controle over hoe de applicatie gebouwd, beheerd en gehost wordt. Containers maken de toepassing minder afhankelijk van één specifieke hostingomgeving. Daardoor kan de setup ook draaien op infrastructuur buiten de grote cloudplatformen, of op een omgeving die de klant zelf kiest.
Dat maakt de architectuur big tech-onafhankelijker. We zijn hiervan overtuigd omdat we vinden dat keuzevrijheid, portabiliteit en voorspelbare kosten belangrijk zijn wanneer je een bedrijfskritische applicatie opnieuw bouwt.
We evolueren hiermee ook weg van een oplossing waarvoor database-licenties een structurele kost vormden. PostgreSQL is een volwassen open-source databasesysteem zonder klassieke database-licentiekost. Dat maakt het interessant in trajecten waar langetermijnkosten, portabiliteit en controle belangrijk zijn.
Voor een KMO tellen die keuzes mee. Ze bepalen waar je later kan hosten, hoe beheersbaar de kosten blijven en hoe eenvoudig onderhoud kan gebeuren.
Daarom maken we technologiekeuzes liever bewust dan toevallig.
AI-ondersteunde ontwikkeling maakt herbouw haalbaarder
AI speelt in dit traject een duidelijke rol, maar niet als vervanging van software engineering.
We gebruiken AI om bepaalde stappen sneller en efficiënter aan te pakken. Denk aan analyse van bestaande logica, documentatie, testscenario’s en repetitieve ontwikkelonderdelen.
Dat kan de totale inspanning van een herbouw beter beheersbaar maken.
Voor KMO’s is dat belangrijk. Een softwaremodernisering die vroeger moeilijk te verantwoorden was, kan vandaag sneller financieel haalbaar worden.
De verantwoordelijkheid blijft wel bij mensen. Zeker bij bedrijfskritische software.
Iemand moet begrijpen wat de toepassing doet. Iemand moet bepalen welke processen behouden blijven. Iemand moet afwegen welke architectuur verdedigbaar is. Iemand moet valideren of de nieuwe oplossing klopt met de realiteit van de gebruikers.
AI helpt versnellen.
Vakmanschap bepaalt of het resultaat betrouwbaar genoeg is.
Tot slot
Voor mij zit de waarde van dit project in de combinatie.
Een applicatie die twintig jaar haar werk heeft gedaan. Een klantrelatie die sterk gebleven is. En een moment waarop herbouw praktisch en financieel zinvol wordt.
De nieuwe versie moet meer doen dan dezelfde functionaliteit opnieuw aanbieden. Ze moet veiliger gebruik op afstand ondersteunen, eenvoudiger te onderhouden zijn, meer controle geven over hosting en kosten, en sneller ruimte maken voor nieuwe functionaliteit wanneer de organisatie daarom vraagt.
Zo ontstaat een gezond moderniseringstraject.
We vertrekken van wat twintig jaar lang gewerkt heeft.
En we bouwen verder op een manier die beter past bij hoe organisaties vandaag werken.
