Middleware of losse koppelingen: wanneer kies je wat?

De meeste koppelingen ontstaan zonder plan. De webshop moet orders naar het ERP sturen, dus de webshopbouwer maakt een koppeling. Het CRM moet klantgegevens uit het ERP halen, dus de CRM-partner maakt er ook een. Elke koppeling op zich is logisch. Samen vormen ze na een paar jaar een web dat niemand meer overziet.

De vraag is dan niet of koppelen goed is. De vraag is of je elk systeem rechtstreeks aan elk ander systeem blijft knopen, of dat je een centrale laag ertussen zet: middleware.

Wat is het verschil tussen een losse koppeling en middleware?

Een losse koppeling (ook wel punt-tot-punt) verbindt twee systemen rechtstreeks. Systeem A weet waar systeem B zit, in welk formaat B de gegevens wil en wat er moet gebeuren als B niet antwoordt.

Middleware is een verbindingslaag tussen al je systemen. Elk systeem praat alleen met die laag. De laag bepaalt welke gegevens waarheen gaan, welke controles erop zitten en wat er gebeurt als iets misgaat. Andere namen zijn integratieplatform of integratielaag.

Het idee is oud en goed beschreven. In Enterprise Integration Patterns, het naslagwerk van Gregor Hohpe en Bobby Woolf, heet het de Message Broker: een centraal punt dat berichten ontvangt, bepaalt waar ze heen moeten en ze doorstuurt. Dat patroon beantwoordt precies de vraag hoe je de ontvanger loskoppelt van de afzender en tegelijk centraal grip houdt op de stroom van gegevens. Het wordt ook wel hub-and-spoke genoemd.

Waarom losse koppelingen knellen als je groeit

Met twee systemen heb je één koppeling. Met vier systemen die allemaal gegevens delen, kunnen het er zes zijn. Met zes systemen vijftien, met acht systemen achtentwintig. Het aantal mogelijke koppelingen groeit veel harder dan het aantal systemen.

Via een integratielaag heeft elk systeem één verbinding: zes systemen, zes verbindingen. Dat is minder bouwwerk, en vooral minder beheer.

Het aantal systemen is wel maar de helft van het verhaal. Tussen twee systemen kunnen tientallen stromen lopen: orders, klanten, artikelen, prijzen, voorraad, statussen. Elke stroom heeft eigen regels over wat er wanneer mag gebeuren. Zit die logica verspreid over losse koppelingen, dan weet niemand meer precies waar welke regel staat. Een ERP en een webshop die veel met elkaar uitwisselen, kunnen dus al genoeg reden zijn voor een centrale laag.

IBM beschrijft het probleem van punt-tot-punt in zijn uitleg over iPaaS: elke koppeling wordt met de hand gebouwd en onderhouden, dat is lastig te beheren en op te schalen, en systemen raken zo nauw aan elkaar vast dat je weinig kunt hergebruiken.

In de praktijk zien we drie gevolgen:

• Niemand overziet het geheel. Elke koppeling heeft een eigen bouwer, een eigen manier van loggen, of helemaal geen logging.
• Een storing valt pas op als een klant belt. Er is geen plek waar je ziet dat een order is blijven hangen.
• Een systeem vervangen wordt een groot project. Wie het ERP vervangt, moet elke koppeling met het ERP opnieuw bouwen, vaak met andere leveranciers.

Vijf signalen dat middleware loont

Middleware is geen doel op zich. Deze signalen laten zien dat het de moeite waard wordt:

• Er zijn veel processen tussen systemen te automatiseren. Denk aan een order die van de webshop naar het ERP gaat, daarna naar het WMS, en met een status terugkomt. Hoe meer van zulke stromen, hoe meer het loont om ze op één plek te bouwen en te bewaken. Dat geldt ook als het maar om twee of drie systemen gaat.
• Een gegeven of een stuk logica is in meer dan één systeem nodig. Klanten, artikelen of prijzen die in het ERP, het CRM en de webshop moeten kloppen. Of een bedrijfsregel, zoals een kortingsafspraak of een controle op een order, die anders in elk systeem apart wordt nagebouwd.
• Medewerkers zetten gegevens nog met de hand over. Waar een koppeling ontbreekt, zit een collega met twee schermen naast elkaar.
• Je weet niet van elke koppeling wie hem beheert. Of hoe je hoort dat hij niet werkt.
• Er staat een systeemvervanging of overname op de planning. Dan wil je de nieuwe systemen op één plek aansluiten, in plaats van alle oude koppelingen na te bouwen.

Wil je later ook AI inzetten, dan telt dat mee: een AI-workflow werkt alleen goed op gegevens die betrouwbaar samenkomen, en heeft een plek nodig waar hij in je processen kan meedraaien.

Herken je er twee of meer, dan is het tijd om het koppelen als één geheel te ontwerpen, en niet meer per koppeling. De signalen lijken op die uit vijf signalen dat je IT-landschap je groei remt: dubbel invoeren en koppelingen die ongemerkt uitvallen komen in beide terug.

Wanneer losse koppelingen prima zijn

Er zijn situaties waarin middleware meer kost dan het oplevert:

• Er lopen maar een paar eenvoudige stromen tussen je systemen, en er komen er voorlopig niet meer bij.
• Elk gegeven en elke bedrijfsregel heeft één vaste plek; de koppeling geeft alleen iets door.
• Het gaat om een standaardkoppeling die de leverancier zelf onderhoudt, bijvoorbeeld tussen je boekhoudpakket en je bank.
• De stroom is eenvoudig en niet bedrijfskritisch: als hij een dag stilligt, merkt niemand het in de omzet.

Een goede integratielaag verbiedt standaardkoppelingen ook niet. Het gaat erom dat je weet welke koppelingen er zijn, wie ze beheert en welke stromen zo belangrijk zijn dat ze centraal bewaakt moeten worden.

Welke koppeling pak je als eerste aan?

Wie besluit tot een integratielaag, hoeft niet alles tegelijk om te bouwen. Integratiekansen prioriteren is juist de eerste stap. Wij kijken per gegevensstroom naar drie dingen:

1. Tijdwinst. Hoeveel uur per week gaat er nu op aan overtypen, controleren en samenvoegen?
2. Foutkans. Hoe vaak gaat het mis, en wat kost een fout? Een verkeerd afleveradres of een gemiste factuur weegt zwaarder dan een verouderd telefoonnummer.
3. Schaalbaarheid. Groeit het werk mee met het aantal orders, klanten of vestigingen? Dan wordt het probleem elk jaar groter.

Daarnaast tellen twee praktische vragen mee: welke stromen zijn afhankelijk van andere stromen, en wanneer kunnen de leveranciers van de betrokken systemen meewerken?

Alle koppelingen komen zo in één lijst, een integratiebacklog: welke informatie gaat tussen welke systemen, wanneer, en voor welk proces. De stromen met de meeste impact komen eerst. Zo zie je al vooraf wat er gebouwd moet worden, in plaats van halverwege een implementatie.

Waarom wij kiezen voor een eigen integratielaag

Middleware klinkt als een zwaar enterpriseproject. Dat hoeft het niet te zijn. Wij bouwen voor bedrijven een eigen integratielaag: een lichte middleware in hun eigen cloudomgeving, met centrale logging en monitoring.

Dat doen we om drie redenen:

• Het is betaalbaar. Een lichte laag in je eigen cloud is ook voor het mkb goed bereikbaar. Je betaalt niet per connector, per gebruiker of per stroom.
• Het is van jou. De code, de logica en de documentatie staan in je eigen omgeving. Je zit niet vast aan één partij, ook niet aan ons.
• Het is bedrijfswaarde. Je integratielaag bevat hoe jouw bedrijf werkt: welke gegevens waarheen gaan, welke regels erop zitten. Dat is jouw intellectueel eigendom, en het groeit met elke koppeling die erbij komt.

Een iPaaS, een integratieplatform als dienst, werkt anders. IBM omschrijft het als een reeks cloudtools om applicaties, systemen en databronnen met elkaar te verbinden. Je bent er snel mee aan de slag, maar je stromen en je logica staan op het platform van een leverancier. Wil je later weg, dan bouw je alles opnieuw. En de prijs en de plannen van dat platform bepaal je niet zelf. Daarom adviseren we dat niet.

Op de pagina Integraties lees je hoe we een integratielaag opzetten.

Vijf ontwerpkeuzes voor een integratielaag die blijft werken

Het verschil tussen een laag die blijft werken en een nieuw soort spaghetti zit in het ontwerp. Als we een doellandschap uittekenen, gaan we uit van vijf principes.

1. Eén leidend systeem per domein. Het ERP is leidend voor financiën en orders, het CRM voor klantcontact, het WMS voor de fysieke voorraad. Andere systemen halen hun gegevens bij die bron, via de integratielaag. Zo staat elk gegeven op één plek, en weet iedereen welk systeem gelijk heeft.
2. Standaardkoppelingen waar ze bestaan, de laag vult de gaten. Een goede standaardkoppeling tussen twee pakketten hoef je niet na te bouwen. De integratielaag neemt de stromen voor zijn rekening waar geen standaard voor is, of waar logica over meerdere systemen loopt.
3. Gebeurtenissen in plaats van overdrachten. Een afgeronde werkorder, een goedgekeurde factuur, een ontvangen betaling: zodra het gebeurt, reageren de andere systemen vanzelf. Niemand hoeft een status door te mailen of een lijst bij te houden.
4. In- en uitpluggen. Omdat elk systeem alleen met de laag praat, vervang je een systeem door zijn aansluiting op de laag te vervangen. De andere stromen blijven draaien. Elke koppeling die je bouwt, blijft zo bruikbaar, ook als er een pakket wisselt.
5. Zien wat er gebeurt. Logging en monitoring op één plek, zodat je een fout ziet voordat een klant of collega hem merkt. Een koppeling die even geen antwoord krijgt, probeert het later opnieuw en geeft pas een melding als dat ook niet lukt. Microsoft beschrijft dat als het retry-patroon. In een centrale laag regel je dat één keer goed.

Wat we in de praktijk zagen

Bij visgroothandel Visco groeide de organisatie hard. Gegevens stonden op verschillende plekken en medewerkers zetten informatie met de hand over. Om te voorkomen dat rond de nieuwe systemen opnieuw losse koppelingen zouden groeien, bouwden we een centrale integratielaag in de eigen cloudomgeving van Visco, met logging en monitoring. Een systeem is later toe te voegen of te vervangen zonder het hele landschap opnieuw op te bouwen.

Bij Fletcher Hotels was de aanleiding een nieuw PMS. Dat was het moment om de andere systemen niet opnieuw één voor één aan te sluiten, maar via een complete middleware: revenue management, de booking engine, channel management, e-mail en de BI-omgeving met het datawarehouse, en meer. Het doel: dit moest de laatste grote IT-transformatie zijn. Een nieuw hotel is nu zonder handmatige actie aangesloten op de keten.

In beide gevallen was het moment hetzelfde: een grote vernieuwing van systemen. Dat is het beste moment om ook het koppelen anders te organiseren.

Zo begin je

Begin niet met de keuze voor een platform. Begin met een lijst:

• welke systemen je hebt, en welke er de komende twee jaar bij komen of verdwijnen;
• welke gegevens tussen die systemen gaan, en hoe dat nu gebeurt: automatisch, met een export of met de hand;
• welk systeem voor elk gegeven leidend is, of zou moeten zijn;
• wie elke koppeling beheert, en hoe je merkt dat hij niet werkt.

Zet daarna per stroom de tijdwinst, de foutkans en de schaalbaarheid ernaast. Dan zie je vanzelf of je met een paar losse koppelingen toe kunt, of dat een integratielaag loont.

Wil je hulp bij die afweging? Lees meer over de stap Integraties, of neem contact op voor een analyse van je huidige koppelingen.