Senior Solution Architect — Data & Integratie
Ik ontwerp de data- en integratieruggengraat, bouw wat erop draait — en krijg de organisatie zover dat ze beide adopteert.
20+ jaar het ontwerpen van de data-, integratie- en streamingplatformen waar ondernemingen op draaien. Vrijwel niets daarvan kwam met een mandaat: 18–20 productteams op één platform, drie landschappen op één event-contract, een finance-afdeling die een getal moest vertrouwen voordat ze het gebruikte. Geen slideware — systemen in productie, en de beslissingen vastgelegd waar ze aangevochten konden worden.
Staat van dienst
Vier cijfers uit werk dat daadwerkelijk live is gegaan. Elk cijfer linkt naar de casus erachter, inclusief het deel waarover discussie was.
18–20 teams, zonder verplichting
Productteams samengebracht op één API-platform door de gebaande weg goedkoper te maken dan blijven zitten — ~€250–300k/jaar bespaard
3 landschappen, 1 contract
SAP-, legacy-ESB- en cloudteams op één event-contract — afgesproken voordat een van beide kanten code schreef
~30+ company codes
SAP Finance-grootboeken naar Snowflake — geadopteerd omdat Finance de cijfers zelf kon aansluiten
~500M+ req/maand
Federatief cross-cloud API-platform over AWS en Azure (Cloud Gateway)
Hoe ik het geadopteerd krijg
Het ontwerp is meestal de makkelijkere helft. Wat bepaalt of er iets komt, zijn de teams die elk al iets hebben dat werkt, de afdeling die een getal moet vertrouwen, en het contract dat iemand vier jaar geleden tekende. Drie situaties, met de onenigheid en wat het kostte.
Twintig teams, en geen bevoegdheid om er één te verplaatsen
Om een verplichting vragen had twintig uitzonderingen opgeleverd. Het platform moest in plaats daarvan goedkoper zijn voor het team, en de eerste teams die overgingen waren die met de slechtste bestaande situatie, niet die het makkelijkst te overtuigen waren.
Drie teams, drie definities van “klaar”
Voor SAP hield de taak op bij “de events staan op de broker”; voor het cloudteam begon die bij “wij consumeren wat er staat”. Alles wat ertoe doet zat in het gat. Ik heb de naad vastgelegd en de saaie helft zelf gedaan.
Een finance-organisatie die geen reden had mij te geloven
De pipeline uitleggen veranderde niets. Een aansluiting die Finance zelf tegen het eigen grootboek kon draaien veranderde alles. Adoptie volgde op de controle, niet op de presentatie.
Wat ik bouw
Vijf gebieden, geordend naar waar ik meestal voor gevraagd word. Data en integratie voorop. AI staat achteraan, en dat is bewust — een profiel dat met AI opent, betekent meestal dat er over de rest van het landschap niet is nagedacht.
Data & lakehouse
Medallion-lakehouses, contracten op de bronnaad, en CDC-pijplijnen die betrouwbaar blijven — zo gebouwd dat de cijfers aansluiten op het systeem dat mensen al geloven.
Integratiearchitectuur
De ruggengraat waarmee enterprisesystemen praten: legacy-ESB-landschappen wave voor wave uitgefaseerd naar event-driven, API-led, domeineigen platformen.
Event-driven & streaming
Kafka en broker-gebaseerde integratie als ruggengraat van het landschap, waarbij schema-evolutie een governancecontract is en geen serialisatiedetail.
API's & gateways
API-platformen die schalen over tientallen teams — gatewaystrategie, één beveiligingsmodel, en de developer experience die ze daadwerkelijk geadopteerd krijgt.
AI & automatisering
AI geïntegreerd zoals elk ander leverancierssysteem: achter een contract, met een evaluatiepoort vóór release, en het model buiten de runtime zodat het vervangbaar blijft.
Bekijk de code erachter
Openbare repositories die je kunt klonen en draaien — de “actieve klant”-vraag, de naadbeslissing, de Fabric-of-Databricks-beslissing, het moderniseringslab, het streamingplatform en de identity-service.