Door Bertrand de Neve, de Neve IT consulting B.V.
Diensten- en informatieketens bestaan zelden uit één systeem. Of het nu gaat om een overheidsketen, een financiële sector met tientallen aangesloten partijen, of een logistieke keten van leveranciers en vervoerders: overal wisselen organisaties al jaren, soms decennia, gegevens uit via afspraken en techniek die ooit state-of-the-art waren. Zo’n uitwisseling stopzetten om “in één keer” over te stappen op iets nieuws, is in de praktijk bijna nooit een optie: er staan processen, belangen en soms iemands rechten op het spel als de verbinding tussen partijen uitvalt.
Toch wíl je vooruit. Moderne, REST-gebaseerde API’s zijn sneller, beter te onderhouden en makkelijker te beveiligen dan de zware, XML-gebaseerde berichtenprotocollen van twintig jaar geleden. De vraag is dus niet of je moderniseert, maar hoe je dat doet zonder de bestaande keten te breken.
Daar helpt een architectuurpatroon dat al langer bestaat, maar in ketenomgevingen nog te weinig wordt toegepast: het strangler pattern.
Zie ook het artikel Transformatie naar soevereiniteit: bouwen aan een nieuwe fundering terwijl de winkel openblijft
Het idee: de oude weg laten bestaan, terwijl je een nieuwe bouwt
De naam komt van de wurgvijg — een plant die om een boom heen groeit totdat de oorspronkelijke boom overbodig is geworden, zonder dat er ooit een moment is geweest waarop alles tegelijk omviel.
Toegepast op IT-architectuur betekent het: je zet een tussenlaag (een adapter) tussen de nieuwe, moderne consumenten en het oude systeem. Die tussenlaag vertaalt tussen de twee werelden. Nieuwe partijen praten in het nieuwe protocol; het oude systeem hoeft niets te merken. Stap voor stap kun je vervolgens meer verkeer via de nieuwe route laten lopen, tot het oude systeem uiteindelijk overbodig is — zonder ooit een “big bang”-migratie te hoeven doen die de hele keten stillegt.
Om te bewijzen dat dit ook werkt voor een keten met een verouderd berichtenprotocol, heb ik een kleine proof of concept gebouwd in mijn eigen R&D-lab.
Photo by Armand Mckenzie on Unsplash
De opzet: twee fictieve partijen, twee protocollen
Ik heb drie eenvoudige applicaties gesimuleerd die samen een herkenbaar ketenscenario naspelen — bewust een overheidsvoorbeeld, omdat de meeste mensen zich daar snel iets bij kunnen voorstellen, maar hetzelfde patroon is net zo goed toepasbaar tussen een bank en een betaaldienstverlener, of tussen een verlader en een vervoerder:
- PolitieSim — een fictieve applicatie die namens “de Politie” een moderne REST-API-aanroep doet: “wat is de status van deze persoon bij de bron?”
- INDSim — een fictieve applicatie die namens “de IND” optreedt als bronsysteem, en die (bewust, om het scenario realistisch te maken) uitsluitend het oudere ebXML/SOAP-berichtenformaat begrijpt.
- Converter — de tussenlaag die het strangler-pattern daadwerkelijk waarmaakt: hij ontvangt het moderne REST-verzoek, vertaalt het naar een geldig ebXML-bericht, en vertaalt het antwoord weer terug.
Beide simulaties zijn puur fictief en bevatten geen echte data — het gaat om het aantonen van het architectuurpatroon, niet om een concreet systeem.
Het lastige detail: tijd
Een REST-consument verwacht doorgaans binnen enkele seconden een antwoord. Een verouderd bronsysteem kan er, zeker bij piekbelasting of onderhoud, uren over doen. Die twee werelden moet je met elkaar verzoenen zonder dat de aanroepende partij blijft hangen op een openstaande verbinding.
De oplossing: de Converter antwoordt direct met een bevestiging (“verzoek ontvangen, ik ga ermee aan de slag”) en een uniek verzoek-ID. Het daadwerkelijke bericht gaat op een wachtrij (ik gebruikte RabbitMQ, zie hieronder waarom), waar het veilig blijft staan — ook als het bronsysteem tijdelijk niet reageert. Zodra het antwoord er wél is, wordt het teruggekoppeld via datzelfde verzoek-ID.
Dit is precies wat je terugziet in het dashboard dat ik erbij heb gebouwd om het geheel live te kunnen volgen:
Elke rij is één verzoek, met een tijdlijn van statussen: ontvangen, verzonden naar de bron, gebufferd (wachtend), antwoord ontvangen, afgeleverd. Klik je op een stap, dan zie je het daadwerkelijke bericht — inclusief het “oude” ebXML-formaat waarin de bron communiceert:
En uiteindelijk, soms een volle minuut later, het resultaat: een modern JSON-antwoord bij de aanroepende partij, alsof er nooit een verouderd protocol tussen heeft gezeten.
Dat laatste is het bewijs waar het echt om gaat: geen berichtverlies, ook niet als de bron traag of tijdelijk onbereikbaar is. Dit is niet alleen lokaal getest: het scenario is end-to-end bevestigd op de daadwerkelijk gedeployde infrastructuur — het bronsysteem tijdelijk offline gehaald tijdens een lopend verzoek, het bericht bleef intussen veilig in de wachtrij staan, en na herstart is het alsnog correct verwerkt en teruggekoppeld. Geen enkel bericht ging verloren.
Elke keuze vastgelegd, ook de grenzen ervan
Een PoC die alleen werkt is niet hetzelfde als een PoC die uitlegbaar is. Voor elke belangrijke architectuurkeuze — waarom een wachtrij in plaats van een zwaardere event-streaming-oplossing, waarom deze vorm van authenticatie voor nú, waarom bewust geen containerplatform voor déze schaal — is een Architecture Decision Record vastgelegd: kort, met context, de daadwerkelijke beslissing, en de consequenties ervan. Dat dwingt tot scherpte: een keuze die je niet kunt onderbouwen, schrijf je niet zomaar op.
Diezelfde discipline is ook toegepast op de scheiding tussen verantwoordelijkheden. Documentatie die alleen tekst en diagrammen bevat, staat in een ander project dan de infrastructuurcode die met echte cloud-resources en sleutels werkt — met eigen toegangsregels per project. In een omgeving met meerdere mensen is dat vanzelfsprekend; hier is het bewust net zo ingericht, ook al werkt er voorlopig maar één persoon aan.
Waarom bewust open source
Voor deze PoC heb ik uitsluitend open source-componenten gebruikt: Python met FastAPI voor de applicaties, RabbitMQ als berichtenmakelaar, en open CI/CD-tooling om alles geautomatiseerd te bouwen en te draaien. Dat is geen toevallige keuze.
Voor dit soort ketens is transparantie en controle over de eigen technologie geen bijzaak — het is een randvoorwaarde. Dat geldt sterk voor de overheid, waar publieke verantwoording en aanbestedingsregels meespelen, maar evengoed voor een financiële sector met toezichteisen of een logistieke keten met veel wisselende partijen. Open source software kan volledig worden doorgelicht (geen “black box” waar je op moet vertrouwen), is niet afhankelijk van het commerciële beleid van één leverancier, en voorkomt vendor lock-in op een schaal waar dat later moeilijk terug te draaien is. Voor RabbitMQ specifiek geldt bovendien: het is een volwassen, breed toegepaste technologie met een heldere open source-licentie (Mozilla Public License 2.0) — geen “open core”-model waarbij de interessante functionaliteit alsnog achter een commerciële laag verdwijnt.
Dat past bij een bredere overtuiging: moderniseren moet niet betekenen dat je de ene afhankelijkheid inruilt voor de andere.
Wat er nog niet in zit — en dat is expres
Een proof of concept bewijst een principe, geen productierijpheid. Bewust nog niet meegenomen — en in de eigen architectuurdocumentatie ook zo vastgelegd, niet toevallig weggelaten — en noodzakelijk vóór een productie-omgeving:
- Sterke authenticatie en encryptie tussen alle onderdelen (denk aan wederzijdse certificaatverificatie/mTLS en OAuth2), in plaats van de vereenvoudigde sleutel die in de PoC volstaat.
- Versleuteling van gegevens in rust, niet alleen onderweg.
- Aansluiting op de daadwerkelijke sector- of ketenstandaarden voor gegevensuitwisseling — denk aan landelijke overheidsstandaarden, maar evengoed aan sectorafspraken in de financiële sector of logistiek — een PoC kan het patroon bewijzen, maar moet vervolgens getoetst worden aan de specifieke afspraken die in de echte ketenomgeving gelden.
- Notificaties in een gestandaardiseerd, uitwisselbaar formaat in plaats van een eigen berichtformaat, zodat andere ketenpartners er zonder maatwerk op kunnen aansluiten.
- Een schaalbaar platform (in plaats van één enkele omgeving) zodra het van proof of concept naar een echte pilot gaat, inclusief monitoring, alerting en formele beveiligingstoetsing.
Dat is geen tekortkoming van het patroon — het is precies waarom je eerst een PoC bouwt voordat je een miljoeneninvestering doet. Je wilt weten of het concept standhoudt vóórdat je het productierijp maakt, niet erna.
De kern
Ketens hoeven niet te kiezen tussen “alles laten zoals het is” en “alles in één keer vervangen.” Met een doordachte tussenlaag kun je geleidelijk moderniseren, de risico’s klein houden, en toch elke stap aantoonbaar maken — met echte berichten, echte vertraging, en een dashboard waarop je live kunt zien dat niets verloren gaat.
Dat is precies het soort architectuurwerk waar ik graag mijn tijd in steek: niet alleen het plaatje op papier, maar het ook zelf bouwen en bewijzen dat het werkt.
Disclaimer: dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden en bevat mijn persoonlijke ervaringen en inzichten rond ketenmodernisering en soevereine architectuur, opgedaan in de praktijk en in mijn eigen lab-omgeving. De beschreven proof of concept — inclusief de rollen “PolitieSim” en “INDSim” — is een fictieve, zelf gebouwde simulatie ter illustratie van een architectuurpatroon, en geen weergave van een bestaand of daadwerkelijk systeem van de genoemde organisaties. De genoemde tools en patronen — waaronder RabbitMQ, Python/FastAPI, GitLab CI/CD, OpenTofu en het Strangler (Fig)-patroon — dienen ter illustratie van de onderliggende principes en zijn geen exclusieve aanbevelingen; ik ben niet gelieerd aan deze partijen, en er bestaan vergelijkbare alternatieven die afhankelijk van context beter kunnen passen. Dit artikel is tot stand gekomen met assistentie van een AI-systeem; de technische implementatie, inhoudelijke keuzes, conclusies en eindredactie zijn volledig door mij gedaan.