.Adv - Hoe Rabobank 175 teams laat bouwen op één platform zonder release trains

In dit artikel:

Bij Rabobank werken meer dan 175 teams aan digitale klantkanalen en -diensten. Om te voorkomen dat ieder team afzonderlijk oplossingen ontwikkelt voor onder meer deployment, beveiliging, monitoring en naleving van regels, gebruikt de bank het Rabobank Online Platform (ROP). Solution architects Stefan van de Vooren en Barteld Klasens zijn verantwoordelijk voor respectievelijk de frontend- en backendkant.

ROP is geen afzonderlijke applicatie, maar een gezamenlijke ontwikkelomgeving met diensten, processen en hulpmiddelen. Het platform ondersteunt onder meer de particuliere en zakelijke app, de website en diensten rond iDEAL en Wero. Teams krijgen centrale voorzieningen voor onder andere testen, securitycontroles, analytics, A/B-tests, toegankelijkheid, gebruikersinterface en lifecyclemanagement. Daardoor kunnen ontwikkelaars zich vooral richten op nieuwe functionaliteit, terwijl algemene eisen centraal worden geregeld.

Die aanpak is belangrijk omdat bancaire software aan hoge eisen voor veiligheid, beschikbaarheid, onderhoud en controleerbaarheid moet voldoen. Zonder gedeelde voorzieningen zouden teams vergelijkbare oplossingen steeds opnieuw bouwen. Tegelijk probeert Rabobank voldoende ruimte te laten voor experimenten en productinnovatie. Het doel is dus niet dat alle teams hetzelfde bouwen, maar dat zij binnen een betrouwbare technische basis zelfstandig kunnen werken.

De oorsprong van ROP ligt ongeveer negen jaar geleden bij meerdere frontendteams die onderdelen voor dezelfde app en website ontwikkelden. Omdat zij dezelfde Angular-versie en hetzelfde designsysteem moesten gebruiken, werd de code samengebracht in één monorepository. Daar omheen ontstonden centrale processen voor bouwen, testen en uitrollen. Later werden ook backenddiensten en andere platformfuncties toegevoegd.

Toen het aantal teams en applicaties sterk toenam, bleken uiteenlopende configuraties en technische keuzes steeds moeilijker te beheren. Rabobank voerde daarom meer gezamenlijke standaarden in, waaronder automatische controles op codekwaliteit. Voor backendontwikkelaars kan ROP bijvoorbeeld een nieuwe microservice aanmaken met een actuele Spring Boot-versie, cloudconfiguratie, pipelines voor bouwen en testen en basisfuncties voor monitoring. Ook uitrol zonder onderbreking en een eerste werkende applicatie worden automatisch voorbereid.

Aan de frontendzijde genereert het platform op basis van enkele keuzes de benodigde code en instellingen. Een nieuwe functie kan direct in productie staan zonder voor klanten zichtbaar te zijn, bijvoorbeeld via een feature flag. Teams kunnen de functionaliteit vervolgens geleidelijk testen en met kleine wijzigingen verbeteren. Automatische tests, beveiligingsanalyses en kwaliteitscontroles worden tijdens het ontwikkelproces uitgevoerd. Sommige problemen blokkeren verdere verwerking, andere verschijnen eerst als waarschuwing. Voor een brede introductie moeten alle relevante tekortkomingen zijn opgelost.

Rabobank werkt niet met vaste gezamenlijke releasemomenten. Teams kunnen wijzigingen daardoor afzonderlijk uitbrengen; volgens de betrokken architecten kan dat in gunstige gevallen binnen ongeveer twee uur. Kleine releases, experimenten en de mogelijkheid om een functie snel uit te schakelen beperken de gevolgen van fouten. Tegelijk zijn registratie, controles en terugdraaiprocedures verplicht ingebouwd. Ook uitzonderingen worden vastgelegd. Dat maakt het voor auditors mogelijk om veel toezicht centraal in het platform te organiseren, in plaats van duizenden microservices volledig afzonderlijk te beoordelen.

Het platform ondersteunt eveneens beheer op lange termijn. Het frontendteam houdt gedeelde npm-pakketten bij en gebruikt migratiescripts om teams zoveel mogelijk werk uit handen te nemen. Daarnaast bewaakt Rabobank niet alleen de klantapplicaties, maar ook de werking van het platform zelf, waaronder het aantal mislukte pipelines en de invloed van wijzigingen op bouwtijden. Het frontendplatform verwerkt dagelijks ongeveer tweehonderd pull requests en builds. Goede testdekking is volgens de architecten noodzakelijk om zulke processen veilig te kunnen automatiseren.

Om de groeiende hoeveelheid interne documentatie beter toegankelijk te maken, ontwikkelde Rabobank ROPPIE. Deze AI-assistent zoekt antwoorden in informatie over ROP en kan gewone vragen koppelen aan de juiste interne voorzieningen. Daarmee moet hij praktischer zijn dan een algemene programmeerassistent, die wel een technisch correct maar binnen Rabobank onbruikbaar advies kan geven. De bank onderzoekt bovendien een koppeling via het Model Context Protocol, zodat AI-assistenten bij het schrijven van code rekening kunnen houden met interne ontwerp-, configuratie-, monitoring- en deploymentregels.

Ook gespecialiseerde AI-agents worden getest voor bijvoorbeeld pakketupdates, beveiligingsproblemen en migraties. Zij kunnen code aanpassen en controleren, maar krijgen nooit meer rechten dan een menselijke ontwikkelaar. Een agent mag dus niet zelfstandig software naar productie brengen; menselijke beoordeling en de bestaande scheiding van verantwoordelijkheden blijven verplicht. De experimenten zijn nog niet breed ingevoerd. Rabobank onderzoekt daarnaast hoe generieke migratiescripts efficiënter kunnen zijn dan afzonderlijke AI-bewerkingen voor duizenden services, mede vanwege kosten, energiegebruik en tokenverbruik.

Volgens Rabobank maakt de bestaande standaardisatie verdere automatisering mogelijk, maar stelt de bancaire omgeving duidelijke grenzen. Niet alle applicatiegegevens zijn voor platformteams toegankelijk en backenddiensten moeten vaak nog tien tot vijftien jaar veilig en onderhoudbaar blijven. Nieuwe technologie wordt daarom alleen gebruikt als die past bij de eisen voor beveiliging en langdurig beheer. AI kan de ontwikkelstraat versnellen, maar de eindverantwoordelijkheid blijft bij mensen.