API-first. Het staat in elke roadmap, elke strategiepresentatie en in vrijwel elk architectuurdocument dat de afgelopen vijf jaar is geschreven. Het klinkt modern, volwassen en gestructureerd. Maar zodra je gaat kijken wat er in de praktijk gebeurt, blijkt API-first vaak vooral een marketingterm die over legacy heen wordt geplakt.
Want eerlijk is eerlijk: veel API-landschappen binnen verzekeraars zijn niet ontworpen, ze zijn ontstaan. Spontaan. Iteratief. En vooral: ongecontroleerd.
Teams bouwen API’s alsof het connectors zijn, systemen hangen steeds verder aan elkaar, en iedereen denkt dat het wel goed zit “want het is toch een API”. Dat is precies hoe je spaghetti-architectuur maakt in een modern jasje.
Het onderliggende probleem is simpel: er is geen API-governance. Geen lifecycle management, geen centraal overzicht, geen duidelijk eigenaarschap, geen controle op afhankelijkheden, geen beleidskaders en geen borging. En als je niet weet wat je hebt, kun je ook niet controleren wat je bouwt.
En dat is in verzekeringsland een bijzonder slecht idee, want hier lopen integraties dwars door kritische ketens heen. Eén verkeerd draadje eruit trekken en een compleet proces ligt plat.
De klassieker: de vergeten API die alles breekt
In vrijwel elke organisatie vind je één zo’n verhaal. Je kunt het bijna voorspellen.
Er was ooit een API gebouwd. Snel, pragmatisch, tijdelijk, want deadlines zijn deadlines. Hij koppelde twee systemen slim aan elkaar en iedereen ging door met de waan van de dag.
Fast forward naar een paar jaar later: die API draait nog steeds. Hij is nooit bijgehouden, nooit gedocumenteerd, nooit officieel opgenomen in de catalogus en al helemaal nooit gekoppeld aan eigenaarschap. De teams die hem ooit bouwden zijn gefuseerd, opgesplitst of simpelweg doorgerold naar een ander domein.
Dan komt er een wijziging in één van de achterliggende systemen. Niets spannends. Gewoon een aanpassing “die geen impact zou moeten hebben”.
Tot elders in het landschap plotseling de alerting rood uitslaat. Functionaliteit valt uit. Processen lopen spaak. Er wordt koortsachtig gedebugd, tot iemand ontdekt dat die oude API nog steeds vrolijk meedraait. En dat die wijziging dus wél impact heeft. Veel meer dan iemand dacht.
Deze situatie is geen uitzondering. Dit is precies wat je krijgt als API’s “erbij worden gebouwd” zonder governance, zonder afstemming, zonder eigenaarschap en zonder zicht op gebruik.
En iedereen schrikt alsof het onweer uit het niets kwam. Maar het was gewoon het voorspelbare gevolg van jarenlang negeren wat onder de motorkap gebeurde.
Waarom dit gebeurt heeft weinig met techniek te maken
We kunnen het allemaal heel complex maken, maar dit is geen technisch probleem. Techniek is niet de bottleneck. Mensen wel.
Er zit gedrag onder dat je in veel verzekeringsorganisaties terugziet.
Teams bouwen dingen zelf, omdat er geleverd moet worden en afstemming voelt als vertraging. Silo’s zijn nog steeds springlevend, en integraties trekken zich daar weinig van aan. Iedereen kijkt naar zijn eigen domein; API’s lopen dwars door al die domeinen heen.
En ondertussen ontbreekt een goed ingestelde voordeur voor nieuwe integraties. Dus bouwt men gewoon wat nodig is. Niet omdat men roekeloos is, maar omdat niemand het proces goed heeft ingericht.
De bonusoorzaak is misschien nog wel de pijnlijkste: niemand weet precies wie eigenaar is van welke data. En als niemand eigenaar is, beslist dus ook niemand wie welke data mag delen, waarom dat mag en hoe dat verantwoord wordt beheerd.
En zo ontstaat de schijn van API-first, terwijl je in werkelijkheid gewoon point-to-point koppelingen bouwt met een modern label erop.
API-first done right: geen papier, maar principes
Echte API-first vraagt niet om een duur consultancydeck of een governanceboard dat eens per kwartaal samenkomt. Het vraagt om een paar keiharde principes die altijd gelden, ook als er druk op de ketel staat.
1. Eén centrale API-catalogus die daadwerkelijk klopt
Niet iets in Confluence waar drie teams aan werken. Niet een wiki die ooit is gestart en daarna verdampt. Een echte catalogus die actueel is, gekoppeld is aan CI/CD, eigenaarschap toont, documentatie borgt en usage inzichtelijk maakt.
Als een API daar niet in staat, bestaat die niet. Punt.
2. Expliciet eigenaarschap van API én datadomein
Een API zonder eigenaar is letterlijk een risico dat geduldig wacht. Eigenaarschap betekent dat iemand aanspreekpunt is, de kwaliteit bewaakt, bepaalt of iets afgeschaft wordt en integratiewijzigingen beoordeelt.
Zonder dit ben je niet API-first, maar API-fingers-crossed.
3. Verplichte integratiereviews
Niet als bureaucratie, maar als kwaliteitsfilter.
Elke wijziging moet langs dezelfde lat: security, datakwaliteit, afhankelijkheden, lifecycle en impact op businessprocessen. Het gaat er niet om dingen moeilijk te maken, het gaat erom verrassingen te voorkomen.
4. Monitoring die meer doet dan lampjes laten branden
Monitoring hoort terug te voeren in gedrag. Niet alleen naar dashboards, maar naar acties.
Een API moet gemonitord worden, begrepen worden en opgevolgd worden. “Ja, we hadden monitoring maar niemand keek” is hetzelfde als geen monitoring.
5. API’s om point-to-point te temmen, niet te verstoppen
Verzekeraars hebben vaak veel point-to-point koppelingen. Een API-laag kan juist helpen om dit beheersbaar te maken, als je governance hebt.
Dan kun je koppelingen isoleren, verkeer knijpen, verdachte patronen blokkeren en ketens veilig doorknippen bij incidenten. Zonder governance creëer je alleen maar een nieuwe laag spaghetti bovenop de oude.
Waarom API-governance zo moeilijk van de grond komt
Als je de kern terugbrengt naar één zin, dan is het deze: governance voelt als vertraging, totdat het de enige manier blijkt om vertraging te voorkomen.
Wat je veel ziet:
- Men doet het al jaren zo, dus waarom nu anders?
- Eigenaarschap is onduidelijk, dus iedereen wijst naar elkaar.
- Teams willen niet nóg een afhankelijkheid toevoegen.
- Niemand vindt documenteren leuk.
- DevOps-teams zitten al vol, dus iets extra’s voelt onhaalbaar.
Maar hoe volwassen je API-landschap is, bepaalt rechtstreeks hoe voorspelbaar, veilig en onderhoudbaar je IT-landschap wordt. En dat bepaalt weer hoe snel je kunt innoveren.
API-first is dus geen luxe. Het is een voorwaarde.
De volwassen versie van API-first: grip, voorspelbaarheid en rust
API-first betekent niet dat je overal API’s bovenop gooit. Het betekent dat je een integratielaag bouwt die begrijpelijk, traceerbaar, beheersbaar en voorspelbaar blijft, zelfs bij verandering.
Het betekent dat teams niet meer hoeven te gokken wat de impact is van een wijziging. Dat auditteams niet langer stress krijgen van “wie weet waarvoor dit nog gebruikt wordt”. Dat businessprocessen niet meer omvallen door verrassingen. Dat development sneller én veiliger wordt.
API-first is geen technisch feestje. Het is volwassen worden.
Slotboodschap
“Een API zonder eigenaar is een incident dat geduldig wacht.”