Composable enterprise-architectuur: hoe integreer je ERP, CRM en dataplatformen zonder nieuwe technische schuld te creëren

Begin met één expliciet integratiemodel en sta geen varianten toe

Technische schuld ontstaat minder door één fout en vooral door variatie. Het ene team bouwt realtime API’s, het andere werkt met batch exports, een derde introduceert event streaming, en een vierde gebruikt file drops omdat het ooit zo is begonnen. Het landschap wordt een mix van patronen die allemaal beheerd moeten worden, met elk hun eigen failure modes.

Kies daarom een beperkt integratiemodel en leg exact vast wanneer welk patroon is toegestaan. Gebruik API’s voor command- en queryinteracties die directe respons vereisen. Gebruik events voor asynchrone processen en distributie van state changes. Gebruik batch alleen waar dat aantoonbaar nodig is en expliciet past binnen datavernieuwingsvereisten. Als je dit niet afdwingt, creëert iedere nieuwe integratie een nieuwe uitzondering.

Integreer via contracten, niet via datamodellen

ERP en CRM hebben interne datamodellen die historisch gegroeid zijn. Als downstream-systemen rechtstreeks op die modellen worden aangesloten, maak je je architectuur afhankelijk van interne structuren die onvermijdelijk veranderen. Contract-firstintegratie lost dat op. Je definieert interfaces en events als expliciete contracten met eigen semantiek, versiebeheer en lifecycle.

De regel is simpel. Downstream-systemen mogen nooit afhankelijk zijn van tabellen, velden of technische objecten uit ERP of CRM. Ze mogen alleen afhankelijk zijn van stabiele contracten die het businessconcept beschrijven, zoals customer created, order confirmed, invoice posted, product updated. Daarmee kan het kernsysteem intern evolueren zonder dat de keten breekt.

Bepaal per datadomein waar de waarheid zit en maak dat niet onderhandelbaar

Nieuwe technische schuld ontstaat vrijwel altijd rond data. Niet rond transport, maar rond onduidelijkheid over master data, ownership en synchronisatie. Wanneer meerdere systemen dezelfde entiteit beheren, krijg je reconciliatie, uitzonderingslogica en discussies over welke bron klopt.

Maak per entiteit expliciete keuzes. Waar is de bron van waarheid voor klanten, producten, prijzen, contracten, facturen, medewerkers en assets? Leg vast welke systemen mogen schrijven en welke alleen mogen lezen. Zorg dat write access beperkt is en dat synchronisatie geen compromis wordt voor politiek gemak. Als dit niet hard wordt gemaakt, gaat integratie vroeg of laat schuiven naar conflictmanagement.

Ontkoppel processen met events in plaats van directe afhankelijkheden

Veel integraties zijn stiekem procesketens. Een actie in CRM triggert direct een update in ERP, die weer een update in het dataplatform triggert, en uiteindelijk een notificatie naar een derde systeem. Als dit via synchrone calls gebeurt, worden systemen elkaars beschikbaarheids- en performancegrenzen. Dan krijg je retries, timeouts, gedeeltelijke updates en moeilijk reproduceerbare incidenten.

Event-drivenintegratie haalt deze ketens uit elkaar. Een kernsysteem publiceert een event wanneer de businessstatus verandert. Andere systemen reageren daarop zonder dat het kernsysteem weet wie er luistert. Dit is de kern van composable architectuur. Je maakt uitbreiding mogelijk zonder bestaande koppelingen te wijzigen.

De consequentie is ook duidelijk. Events moeten semantisch zijn en niet technisch. Publiceer geen database changes. Publiceer business changes.

Gebruik een integratielaag die governance afdwingt, niet alleen transporteert

Veel organisaties hebben API-management of iPaaS, maar behandelen het als doorgeefluik. Dan verandert er weinig. De integratielaag moet governance afdwingen. Denk aan centrale authenticatie en authorisatie, throttling, schemavalidatie, versiebeheer, audit logging, en standaard error handling.

Zonder deze centrale afdwinging wordt elke integratie een eigen miniplatform met eigen security keuzes, eigen retry gedrag en eigen logging. Dat is technische schuld by design.

Maak versiebeheer en backward compatibility verplicht

De meeste schuld ontstaat bij verandering. Niet bij de eerste implementatie. Zodra een ERP-upgrade een veld verandert of een CRM-workflow wordt aangepast, breken downstream-systemen of gaan teams quick fixes bouwen.

Maak interfaceversioning en backward compatibility een harde eis. Breaking changes mogen alleen via een gecontroleerde migratie met parallelle versies en duidelijke deprecatie­deadlines. Publiceer niet zomaar nieuwe payloads. Introduceer nieuwe velden op een backward compatible manier. Maak de afnemer verantwoordelijk voor adoptie binnen een afgesproken termijn. Zonder dit discipline-element verandert elk change request in een ketenrisico.

Zet observability op integratiestromen hoger dan monitoring op systemen

Je kunt perfecte monitoring hebben op ERP en CRM en toch geen idee hebben waarom orders niet aankomen of waarom klantendata inconsistent is. In een composable landschap is de integratiestroom de kritische eenheid, niet het individuele systeem.

Implementeer end-to-endtraceability over API-calls, eventflows en batchpipelines. Maak zichtbaar waar latency ontstaat, waar retries oplopen, waar dead letters groeien en waar data quality checks falen. Zonder deze zichtbaarheid wordt troubleshooting een menselijk netwerkprobleem en groeit de afhankelijkheid van specifieke experts.

Behandel het dataplatform als product met contracten, niet als datakerkhof

Dataplatformen worden vaak het punt waar technische schuld zich concentreert. Teams dumpen data omdat het handig is, bouwen eigen modellen en maken eigen definities van dezelfde KPI’s. Dan krijg je een tweede waarheid naast ERP en CRM.

Maak datacontracten verplicht tussen bron en dataplatform. Leg vast wat wordt geleverd, hoe vaak, met welke kwaliteitseisen en wat de semantiek is. Zorg dat lineage inzichtelijk is en dat data ownership expliciet blijft bij het domein. Het dataplatform moet consumptie faciliteren, niet betekenis verzinnen.

Voorkom dat composable architectuur een excuus wordt voor nieuwe tooling sprawl

Composable betekent niet dat ieder team nieuwe services en tools mag introduceren. Dat leidt tot platformsprawl en opnieuw technische schuld, alleen nu verdeeld over microservices en integratietools.

Beperk het aantal standaardbouwblokken. Eén API-managementlaag. Eén eventplatform. Eén iPaaS waar nodig. Eén standaard voor datacontracten. Hoe minder variatie, hoe minder schuld.