Meer dan 175 teams werken binnen Rabobank aan digitale klantreizen en diensten. Om te voorkomen dat zij allemaal afzonderlijk deployment, security, observability en compliance moeten regelen, bouwen ze op het Rabobank Online Platform, kortweg ROP. Solution architects Stefan van de Vooren en Barteld Klasens werken ieder aan een andere kant van dat platform. Stefan richt zich op de frontend, Barteld op de backend.
Twee architecten, twee kanten van ROP
Barteld werkt bijna zes jaar bij Rabobank aan de backend van ROP. Via game design en
Werken bij Rabobank
testengineering belandde hij in platformtechnologie. Ook thuis gamet hij graag en speelt hij tabletop games. "Ik pas absoluut in het technerdhokje. Hier staat de hele kast vol met Dungeons & Dragons-boeken en tabletop figurines."
Stefan werkt negen jaar bij de bank, waarvan ongeveer vier als solution architect voor het frontendplatform. Zijn achtergrond ligt in het onderwijs en de creatieve technologie. Stefan werd opgeleid tot docent elektrotechniek en werkte vijftien jaar aan e-learning, serious games, apps en interactieve museuminstallaties. Buiten werktijd zoekt hij de techniek liever in zonnepanelen, een thuisbatterij of zijn omgebouwde brandweerbus. "Om eerlijk te zijn probeer ik buiten de uren die ik voor Rabobank werk juist zo min mogelijk dingen met computers te doen."
Niet één product, maar een complete ontwikkelstraat
ROP is geen los product of één grote applicatie. Het is een verzameling van diensten, processen en ontwikkeltools die samen een groot deel van de route van code naar productie afdekken. Het platform richt zich vooral op de kanalen waarmee klanten rechtstreeks werken, zoals de particuliere en zakelijke app, de website en diensten rond iDEAL en Wero. Dat is niet zonder succes: de app staat wereldwijd op de vijfde plaats binnen de bankensector."Zo kun je als developer gewoon focussen op het daadwerkelijk ontwikkelen van een feature."
Die gedeelde laag is nodig omdat een bank onder strenge wet- en regelgeving valt. Iedere intern gebouwde applicatie moet voldoen aan eisen voor onder meer security, beschikbaarheid, onderhoud en controleerbaarheid. Als ieder team die eisen zelf vertaalt naar code en processen, wordt hetzelfde werk honderden keren uitgevoerd. ROP biedt daarom centrale bouwstenen voor bijvoorbeeld deployment, analytics, A/B-tests, toegankelijkheid, securityscans, UX-componenten en lifecyclemanagement. Barteld vat het doel kernachtig samen: "Zo kun je als developer gewoon focussen op het daadwerkelijk ontwikkelen van een feature."
Tegelijkertijd wil je de teams die op het platform werken ook genoeg vrijheid geven om te innoveren en nieuwe dingen uit te proberen voor onze klanten. De uitdaging is daarom niet simpelweg standaardiseren, maar een gedeelde onderlaag bouwen waarbinnen teams zelfstandig kunnen bewegen.
Van monorepo naar platform
De eerste versie van ROP ontstond ongeveer negen jaar geleden, al droeg het toen nog niet die naam. Verschillende teams bouwden zelfstandig frontendfeatures die uiteindelijk in dezelfde website en app terechtkwamen. Die onderdelen moesten wel dezelfde Angular-versie en hetzelfde designsysteem gebruiken. Naarmate er meer teams bijkwamen, werd het steeds moeilijker om versies gelijk te houden en eigenaarschap helder te organiseren.
Rabobank bracht de frontendcode daarom samen in één grote monorepo. Rond die repository ontstonden centrale processen voor bouwen, testen en deployen. Later kwamen daar backendvoorzieningen en andere platformonderdelen bij.
De standaardisatie werd gaandeweg strenger. In de beginjaren kregen developers veel vrijheid om eigen keuzes te maken. Dat werkte met twintig teams en twee apps, maar niet meer toen het aantal apps en de teams significant groeiden. Afwijkende configuraties en uiteenlopende implementaties maakten het landschap steeds lastiger te onderhouden. Rabobank legde daarom onder meer centrale codekwaliteitsregels vast en automatiseerde de controle daarop.
Van idee naar productie
De waarde daarvan wordt duidelijk in een concrete developer journey. Een team met een idee voor een nieuwe klantreis bepaalt eerst welke frontendcomponenten en backendservices nodig zijn. Voor een nieuwe microservice kan een backenddeveloper vervolgens via het interne developerportal een applicatie aanvragen. ROP bootstrapt die service met een actuele versie van Spring Boot en de configuratie die nodig is om in de cloud te draaien. Build-, test- en deploymentpipelines en de eerste laag voor observability worden automatisch toegevoegd. Een werkend Hello World-template levert direct de basis voor monitoring en deployment zonder downtime, bijvoorbeeld via een blue-green deployment.
Backendapplicaties leven doorgaans in afzonderlijke repositories. Via GitOps beschrijft een team de gewenste toestand van een applicatie. "Eigenlijk beschrijf je hoe jij wilt dat het op productie staat", legt Barteld uit. Hoe ROP die toestand bereikt, kan achter de schermen veranderen. Daardoor kan het platformteam processen of complianceregels centraal aanpassen zonder dat ieder team zijn applicatie opnieuw hoeft in te richten.
Aan de frontendzijde begint een developer in de gedeelde monorepo. Scaffolding vraagt onder meer welk team eigenaar is van de feature en in welke app die moet verschijnen. Daarna genereert ROP de benodigde code en configuratie. "Vervolgens heb je eigenlijk al een Hello World-pagina", zegt Stefan. "Zo'n pagina kan meteen naar productie worden gedeployed, maar blijft via een feature flag verborgen voor klanten. Op deze manier kan een featureteam de functionaliteit al testen en telkens kleine aanpassingen maken (trunk-based development) totdat de feature klaar is om onder een beperkte groep klanten te testen."
Tests, static application security testing (SAST) en controles op codekwaliteit draaien automatisch. Sommige fouten blokkeren een pull request direct; andere leiden tot een waarschuwing. Die fouten moeten vóór een brede uitrol zijn opgelost. Een vroege testversie hoeft bijvoorbeeld nog niet volledig aan alle toegankelijkheids- en taaleisen te voldoen, maar de uiteindelijke klantversie wel.
Geen releasetreinen, wel ingebouwde controle
Ondanks de centrale onderlaag hoeven teams niet op een gezamenlijk releasemoment te wachten. Een wijziging kan in principe binnen ongeveer twee uur in productie staan. "Wij hebben geen release trains. Daarom is er geen discussie over wat wel of niet meegaat"
Rabobank werkt met kleine veranderingen, feature flags en A/B-tests. Daardoor kunnen meerdere versies van een feature naast elkaar draaien en kan een problematische wijziging snel worden uitgezet. "Wij hebben geen release trains. Daarom is er geen discussie over wat wel of niet meegaat", aldus Stefan.
Snel releasen kan alleen als de verplichte controles onderdeel zijn van de ontwikkelstraat. ROP registreert wijzigingen automatisch, voert codescans uit en biedt vaste rollbackmogelijkheden. Voor auditors is het daardoor niet nodig om bijna tweeduizend microservices volledig los van elkaar te beoordelen. Een belangrijk deel van de controles zit in het gedeelde framework.
Die regels zijn niet vrijblijvend. Developers kunnen verplichte scans of registraties niet simpelweg uitschakelen. Voor incidenten bestaan uitzonderingsroutes, maar ook het gebruik daarvan wordt vastgelegd. Barteld beschrijft de soms wat ongemakkelijke kracht daarvan met een glimlach: "Als developer denk je aan de ene kant: shit, kan ik dit niet uitzetten? Maar je bent altijd compliant."
De vaste onderlaag maakt bovendien lifecyclemanagement op schaal mogelijk. Het frontendplatformteam houdt alle npm-pakketten up-to-date en gebruikt migratiescripts, zodat de teams hier zelf geen tijd aan kwijt zijn. Ook ROP zelf wordt gemonitord. Per dag verwerkt het frontendplatform rond de tweehonderd pull requests en builds, soms meer. Het platformteam volgt daarom niet alleen of klantapplicaties werken, maar ook hoeveel pipelines mislukken en wat een platformwijziging doet met bijvoorbeeld de buildtijd. Goede geautomatiseerde tests zijn daarbij onmisbaar. Barteld: "Je kunt al die veranderingen automatiseren, maar eigenlijk alleen als je testcoverage hoog genoeg is."
ROPPIE brengt platformkennis naar de developer
Een platform dat complexiteit wegneemt, produceert zelf veel documentatie. Naarmate de informatie over frontend, backend, autorisatie, deployment en security groeit, wordt het lastiger om snel het juiste antwoord te vinden.
Daarvoor ontwikkelde Rabobank ROPPIE, een AI-assistent die antwoorden baseert op alle ROP-documentatie. Dat onderscheidt hem van een algemene Copilot. Die kan een technisch correct antwoord geven dat niet past bij de interne omgeving, bijvoorbeeld door een AWS-oplossing voor te stellen die binnen ROP niet wordt gebruikt.
ROPPIE helpt ook wanneer iemand de interne naam van een dienst niet kent. Een nieuwe developer zoekt eerder op 'Hoe voer ik een A/B-test uit?' dan op de productnaam van de gebruikte tool. ROPPIE kan zo'n vraag in gewone taal koppelen aan de juiste documentatie.Een nieuwe developer zoekt eerder op 'Hoe voer ik een A/B-test uit?' dan op de productnaam van de gebruikte tool.
De volgende stap is om die kennis naar de ide te brengen. Via een server voor het Model Context Protocol (MCP) kan Copilot relevante context en tools uit ROP gebruiken. Bij het genereren van een frontend-feature kan de assistent dan rekening houden met bijvoorbeeld het Rabobank-designsysteem. Bij backendcode kan hij rekening houden met de juiste configuratie-, observability- en deploymentpatronen. Later kan dezelfde kennis worden gebruikt om bij een commit of pull request te signaleren dat code technisch werkt, maar bijvoorbeeld in de verkeerde module is geplaatst.
Agents krijgen niet meer rechten dan developers
Rabobank onderzoekt ook een architectuur waarin gespecialiseerde AI-agents samenwerken. Een eenvoudige voorloper bestaat al in de vorm van Renovate, dat pull requests opent voor package-updates. Een nieuwe versie van Spring Boot vraagt alleen soms meer dan een versienummer aanpassen. De applicatiecode moet dan mee veranderen.
In een mogelijke agentloop constateert een eerste agent dat een dependency moet worden bijgewerkt of dat een securityscan een kwetsbaarheid vindt. Een tweede past de code aan, een volgende controleert de interne standaarden en een andere kijkt specifiek naar security. Daarna moeten de bestaande pipelines aantonen dat de code compileert, de tests doorstaat en de applicatie nog werkt.
"Bij Rabobank mag nooit één developer autonoom dingen naar productie pushen, dus dan mag een agent dat ook niet"
Een agent krijgt daarbij nooit meer bevoegdheden dan een mens. "Bij Rabobank mag nooit één developer autonoom dingen naar productie pushen, dus dan mag een agent dat ook niet", zegt Barteld. Of code door een developer of een model is geschreven, verandert niets aan de verplichte review. De bestaande scheiding van verantwoordelijkheden blijft leidend.
De eerste experimenten lopen, maar zijn nog niet breed uitgerold. Menselijke correcties kunnen vervolgens een leerloop vormen: als developers een voorstel afwijzen of aanpassen, kan een volgende poging daarvan leren.
Daar hangt wel een prijskaartje aan. Gespecialiseerde agents kunnen efficiënter werken, maar verbruiken tokens, energie en geld. "Het is zonde als we duizenden euro's aan tokens weggooien terwijl het efficiënter had gekund", merkt Stefan op. Juist de schaal van ROP biedt hier een voordeel. In plaats van duizenden microservices afzonderlijk door een model te laten migreren, kan Rabobank op basis van een representatieve groep applicaties generieke migratiescripts ontwikkelen en die centraal testen.
Standaardisatie is ook een keuze
ROP geeft Rabobank een sterke uitgangspositie voor verdere automatisering. De code, pipelines en controles zijn al grotendeels gestandaardiseerd, waardoor AI kan aansluiten op bestaande feedbackloops. Tegelijk legt de bancaire context beperkingen op. Platformengineers mogen niet automatisch alle applicatiegegevens bekijken en veel backendservices moeten na hun bouw nog tien tot vijftien jaar veilig en actueel blijven.
Standaardisatie beperkt daarnaast de vrijheid om ieder nieuw framework meteen in productie te gebruiken. Technologie moet passen bij de security-eisen, onderhoudsstrategie en verwachte levensduur van het platform. De vrijheid zit vooral in wat een team voor de klant bouwt, niet in het telkens opnieuw ontwerpen van de technische onderlaag.
Precies daarin zien Stefan en Barteld de kern van platformengineering: "Automatiseer wat voor iedereen gelijk is en laat de teams hun aandacht besteden aan wat hun feature onderscheidt. AI kan dat proces verder versnellen, maar verandert niets aan het uitgangspunt. De techniek mag steeds autonomer worden. De verantwoordelijkheid blijft bij mensen."
Ontdek meer over werken in de IT bij Rabobank
Dit artikel is geen redactioneel artikel, maar gesponsord en tot stand gekomen dankzij Rabobank en Tweakers Partners. Tweakers Partners is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers events zoals meet-ups, Developers Summit, Testfest en meer. Bekijk hier het overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].
:strip_icc():strip_exif()/u/417627/crop5fc8d563465dc_cropped.jpeg?f=community)