Moderniseer het systeem waar niemand aan durft te komen, functie per functie.
Decennia aan bedrijfsregels zitten in COBOL, PL/I, Oracle Forms en vroege Java- en .NET-code. Wij halen die regels boven, bouwen een vangnet van tests en verhuizen functie per functie achter een façade, met parallel draaien en reconciliatie voordat er iets wordt uitgeschakeld.
Voor Nederlandse uitvoeringsorganisaties en bedrijven waar een kritisch systeem verouderd is en uitval geen optie.
Het applicatieportfolio wordt beoordeeld en het doel afgesproken. Bedrijfsregels worden met ondersteuning van AI uit de code gehaald en door mensen geverifieerd. Karakteriseringstests vormen een vangnet. Elke functie wordt achter een façade opnieuw gebouwd en parallel met het oude systeem gedraaid; verschillen worden geanalyseerd en opgelost voordat de proceseigenaar de overstap goedkeurt en het oude deel wordt uitgefaseerd.
Voor en na
Wat er verandert in de manier van werken
Vandaag
Met het systeem
Vandaag
Vandaag: Elke wijziging is een risico
Kleine wijzigingen in de regelgeving duren maanden, omdat niemand kan voorspellen wat een wijziging nog meer raakt.
Met het systeem
Met het systeem: Wijzigingen gedekt door tests
Karakteriseringstests leggen vast wat het systeem vandaag doet, zodat elke wijziging haar effect toont vóór de release.
Vandaag
Vandaag: Kennis gaat met pensioen
De mensen die de code begrijpen, gaan binnenkort met pensioen, en de documentatie strookt al lang niet meer met het systeem.
Met het systeem
Met het systeem: Regels vastgelegd en geverifieerd
Bedrijfsregels die uit de code zijn gehaald, worden in gewone taal gedocumenteerd en door domeinexperts bevestigd.
Vandaag
Vandaag: Big-bangplannen lopen vast
Volledige vervangingsprogramma’s beloven één overstapdatum die blijft opschuiven terwijl de kosten stijgen.
Met het systeem
Met het systeem: Waarde in delen opgeleverd
Functies verhuizen één voor één achter een façade. Elk deel gaat afzonderlijk live en kan worden teruggedraaid.
Vandaag
Vandaag: Gegevens opgesloten in oude structuren
Nieuwe diensten en AI-toepassingen kunnen de gegevens niet bereiken zonder fragiele extracten en nachtelijke batches.
Met het systeem
Met het systeem: Gegevens beschikbaar via API’s
Gemigreerde domeinen stellen hun gegevens beschikbaar via gedocumenteerde API’s, met reconciliatie tegen het oude systeem tot dat wordt uitgefaseerd.
Workflow
Hoe de workflow verloopt
Een strangler-fig-aanpak: het nieuwe systeem groeit functie per functie rond het oude. De lus tussen parallel draaien en herbouwen is waar het meeste echte werk gebeurt.
Illustratieve workflow
7 stappen · 3 menselijke controles
Legenda
Systeem
Agent
Persoon
Menselijke controle
Uitzonderingspad
Modernisering van legacysystemen: illustratieve workflow met reconciliatielus
Lees het diagram als tekst
Het hoofdpad loopt van het beoordelen van het portfolio en het bovenhalen van de bedrijfsregels, via het bouwen van een vangnet van karakteriseringstests en het herbouwen van één functie achter een façade, naar het parallel draaien van oud en nieuw en ten slotte het overschakelen en uitfaseren van het oude deel.
Mensen keuren de doelarchitectuur goed, verifiëren elke gevonden regel en keuren elke overstap goed: dat zijn de menselijke controlepunten.
Toont het parallel draaien dat de uitvoer afwijkt, dan verlaat het deel het hoofdpad voor analyse door ontwikkelaars en domeinexperts, en gaat het terug naar de herbouwstap tot oud en nieuw met elkaar overeenstemmen.
01
Stap 1: Het portfolio beoordelenPersoon
Inventaris van applicaties, in kaart brengen van afhankelijkheden en gegevensstromen, en per applicatie een beslissing: uitfaseren, behouden, rehosten, replatformen, herbouwen of vervangen. Domeinen worden in kaart gebracht om de naden te vinden waar opdelen mogelijk is.
Menselijke controle
Uw architectuurraad keurt de doelarchitectuur en de volgorde van de delen goed.
02
Stap 2: De bedrijfsregels bovenhalenAgent
Codeanalyse met ondersteuning van AI leest COBOL, PL/I, JCL, Oracle Forms en oudere Java- of .NET-code, en stelt documentatie, aanroepgrafen en een catalogus van bedrijfsregels in concept op.
Menselijke controle
Ontwikkelaars en domeinexperts verifiëren elke gevonden regel voordat die als specificatie wordt gebruikt. Niet-geverifieerde regels worden als zodanig gemarkeerd.
03
Stap 3: Het vangnet bouwenSysteem
Karakteriseringstests worden gegenereerd uit geanonimiseerde invoer en uitvoer uit productie, zodat het huidige gedrag, inclusief de eigenaardigheden, is vastgelegd voordat er iets verandert.
04
Stap 4: Een deel herbouwen achter een façadeSysteem
Voor het oude systeem wordt een routerende façade of API-laag geplaatst. Eén functie wordt herbouwd als nieuwe dienst, met de bijbehorende gegevens gemigreerd en gesynchroniseerd.
05
Stap 5: Parallel draaien en reconciliërenSysteem
Oud en nieuw verwerken dezelfde transacties. Uitvoer en gegevens worden automatisch vergeleken en elk verschil wordt per regel en per record gerapporteerd.
06
Stap 6: Verschillen analyserenPersoon
Ontwikkelaars en domeinexperts beslissen of elk verschil een fout in de nieuwe dienst is, een fout in de oude, of een bedoelde wijziging, en sturen het deel terug om te worden aangepast.
Uitzonderingspad: Uitvoer wijkt af· Keert terug naar stap 4
07
Stap 7: Overschakelen en uitfaserenPersoon
Het verkeer voor de functie gaat via de façade naar de nieuwe dienst. Na een stabiele periode worden het oude codepad en de bijbehorende gegevens uitgefaseerd en gearchiveerd.
Menselijke controle
De proceseigenaar keurt elke overstap goed op basis van de reconciliatieresultaten. Terugdraaien via de façade blijft mogelijk tot de uitfasering.
Componenten
Wat wij zouden bouwen
01
Kaart van portfolio en afhankelijkheden
Inventaris, in kaart gebrachte interfaces en gegevensstromen, en een domeinmodel dat toont waar het systeem in delen kan worden opgesplitst.
Salesforce als nieuwe frontofficePlatformSalesforce
Integratieplatform en API-gateway
Doelcloud of -datacenter
Controles
Ingebouwde waarborgen
Toegangsgrenzen
De codeanalyse draait in een omgeving die u beheert, en er gaat geen broncode naar diensten die u niet hebt goedgekeurd. Productiegegevens voor tests worden geanonimiseerd voordat ze de productiezone verlaten.
Menselijke beoordeling
Gevonden regels worden door ontwikkelaars en domeinexperts geverifieerd voordat ze specificaties worden. Elke overstap wordt door de proceseigenaar goedgekeurd op basis van de reconciliatieresultaten, met de mogelijkheid om terug te draaien.
Controleerbaarheid
Elke regel in de catalogus is herleidbaar naar de code waaruit ze komt en naar de persoon die ze heeft geverifieerd. Reconciliatierapporten worden bewaard als bewijs bij elke overstap.
Gegevensbescherming
De datamigratie volgt een gedocumenteerde mapping met recordtellingen en checksums, en persoonsgegevens in testsets worden tot het minimum beperkt. Bewaarregels verhuizen mee met de gegevens.
Transparantie over AI
Waar AI documentatie of code in concept opstelt, wordt de output gemarkeerd, beoordeeld en geversioneerd zoals elk ander engineeringartefact.
Meetpunten
Wat wij zouden meten
Wij spreken deze meetpunten met u af tijdens de beoordeling en volgen ze per deel, niet alleen voor het programma als geheel.
Wat wij zouden meten
Meetpunt
Waarom het telt
Hoe we het zouden meten
01Doorlooptijd van wijzigingen
Waarom het teltHet duidelijkste teken dat het systeem makkelijker te wijzigen wordt.
Hoe we het zouden metenTijd van goedgekeurd wijzigingsverzoek tot productie, voor de oude en de gemoderniseerde delen.
02Reconciliatiestatus
Waarom het teltToont of de nieuwe dienst zich echt gedraagt zoals de oude, waar dat moet.
Hoe we het zouden metenHet aandeel transacties en records dat overeenstemt tijdens het parallel draaien, met de openstaande verschillen per oorzaak.
03Dekking van regels
Waarom het teltOnbekende regels zijn het grootste risico bij elke vervanging.
Hoe we het zouden metenHet aandeel gevonden bedrijfsregels dat door domeinexperts is geverifieerd en door tests is gedekt.
04Omvang van de legacy
Waarom het teltModernisering loont pas als oude componenten echt worden uitgeschakeld.
Hoe we het zouden metenUitgefaseerde functies, codepaden, batchjobs en licenties, gevolgd per deel.
Er worden geen doelen vastgelegd zolang er geen nulmeting is.
Uitrol
Hoe wij het zouden uitrollen
Fase 01
Beoordeling
Portfolio, afhankelijkheden, domeinen en risico’s. Wij kiezen een eerste deel dat voor de organisatie telt, maar kan worden teruggedraaid.
Exitcriteria
Doelarchitectuur goedgekeurd
Volgorde van de delen afgesproken
Toegang tot testomgevingen en gegevens geregeld
Fase 02
Eerste deel
Regels bovenhalen, vangnet, façade en één herbouwde functie, parallel gedraaid met het oude systeem.
Exitcriteria
Reconciliatie binnen de afgesproken tolerantie
Proceseigenaar keurt de overstap goed
Terugdraaien getest
Fase 03
Deel per deel
Volgende functies volgen hetzelfde pad, elk met een eigen periode van parallel draaien en een eigen overstapbeslissing.
Exitcriteria
Elk deel gereconcilieerd en overgeschakeld
Kennis overgedragen aan uw team
Fase 04
Uitfasering
Oude codepaden, batchjobs en gegevensopslag worden gearchiveerd en uitgeschakeld.
Op maat gebouwde ERP-uitbreidingen en fabriekssystemen, verhuisd samen met een migratie naar SAP S/4HANA.
Illustratief voorbeeld
Een berekeningssysteem voor uitkeringen vernieuwen
Situatie
Een uitvoeringsorganisatie berekent uitkeringen in een mainframesysteem met regels uit vele wetswijzigingen. Nieuwe regelgeving staat klaar en twee van de ontwikkelaars die de code kennen, gaan binnenkort met pensioen.
Systeem
Regels worden met hulp van AI uit de code teruggevonden en door specialisten bevestigd. Eén regeling verhuist eerst naar een nieuwe dienst en draait parallel met het mainframe tot de uitkomsten aansluiten.
Menselijke controle
Wet- en regelgevingsspecialisten bevestigen elke teruggevonden regel. De proceseigenaar beslist over de overstap; terugschakelen blijft mogelijk.
Wat we zouden meten
Aansluiting van uitkomsten per regeling, dekking van de regels en doorlooptijd voor de volgende wetswijziging.
Nederland
Vernieuwen zonder de uitvoering te raken
Veel Nederlandse uitvoeringsorganisaties draaien op systemen van decennia oud, terwijl wetswijzigingen blijven komen en de mensen die de code kennen met pensioen gaan. Grote vernieuwingen bij het Rijk kunnen door het Adviescollege ICT-toetsing worden beoordeeld, en een vervanging in één klap past daar zelden in.
Wij vernieuwen in kleine stappen, laten oud en nieuw naast elkaar draaien tot de uitkomsten aansluiten, en bouwen nieuwe diensten volgens de BIO2 en NORA. Bij persoonsgegevens volgen migratie en testdata de AVG.
01Waarom niet het hele systeem in één keer vervangen?
Omdat één overstapmoment alle risico op één datum legt, en de organisatie jaren op enig resultaat wacht. Functie per functie verhuizen laat elk deel zich bewijzen in een parallelle run, afzonderlijk live gaan en zo nodig teruggedraaid worden.
02Kan AI onze COBOL naar Java vertalen?
Een vertaling regel per regel levert meestal code op die even moeilijk aan te passen is als het origineel. Wij gebruiken AI om de oude code te lezen en te documenteren en om regels en tests in concept op te stellen, en ontwerpen de nieuwe diensten daarna zorgvuldig. Elke gevonden regel wordt door mensen geverifieerd voordat ze wordt gebruikt.
03Onze experts gaan met pensioen. Hoe legt u vast wat zij weten?
Via gestructureerde sessies waarin experts de gevonden regels en de karakteriseringstests beoordelen. Hun kennis belandt in documentatie en tests die bij uw team blijven, niet in onze hoofden.
04Geldt dit ook voor SAP ECC?
Ja. Dezelfde principes gelden voor het saneren van eigen ontwikkelde code en voor een migratie naar SAP S/4HANA: beoordelen wat nog wordt gebruikt, bovenhalen en testen wat ertoe doet, en in gecontroleerde stappen verhuizen.
05Hoe lang draaien oud en nieuw naast elkaar?
Tot de reconciliatieresultaten de tolerantie halen die met de proceseigenaar is afgesproken, en lang genoeg om periodieke processen zoals maandafsluitingen of jaarlijkse runs te dekken.