Middleware vs Point-to-Point Integratie: Welke Architectuur Past bij jouw Bedrijf?
Door Clen Mourik
Bij 3 systemen zijn 3 koppelingen beheersbaar. Bij 10 systemen heb je er plots 45 nodig. Wanneer wordt point-to-point een probleem en is middleware de oplossing? Een eerlijke vergelijking.
Hoeveel verschillende softwarepakketten gebruik je eigenlijk? ERP, boekhouding, planning, CRM, voorraad, webshop... Tel ze maar eens. De meeste MKB-bedrijven zitten tussen de 4 en 6 systemen. En elk systeem moet natuurlijk met de andere praten.
Daar begint het. Je eerste koppeling werkt prima. De tweede ook. Maar ergens tussen systeem vijf en tien wordt het een wirwar. Elke nieuwe toevoeging betekent niet één, maar meerdere nieuwe koppelingen. En plots ben je meer tijd kwijt aan het repareren van kapotte integraties dan aan het runnen van je bedrijf.
De vraag is niet óf je moet integreren. De vraag is: welke architectuur past bij jouw situatie? Point-to-point werkt fantastisch voor sommige bedrijven. Voor andere is het een ramp. Middleware kan een uitkomst zijn, maar ook totale overkill.
Laten we eerlijk zijn over beide opties.
Inhoudsopgave
- Belangrijkste punten
- Wat is point-to-point integratie precies?
- Het spaghetti-probleem: wanneer point-to-point escaleert
- Middleware en hub-and-spoke uitgelegd
- Kostenvergelijking: waar ligt het omslagpunt?
- Wanneer is point-to-point nog steeds de beste keuze?
- Wanneer wordt middleware noodzakelijk?
- Praktijkvoorbeelden uit verschillende sectoren
- De hybride aanpak: het beste van beide werelden
- Veelgestelde vragen
Belangrijkste punten
| Punt | Details |
|---|---|
| Complexiteit groeit exponentieel | Bij point-to-point heb je bij 3 systemen 3 koppelingen nodig, bij 10 systemen zijn dat er 45 |
| Omslagpunt ligt rond 5-7 systemen | Tot 5 systemen is point-to-point vaak goedkoper en sneller, daarboven wordt middleware interessanter |
| Onderhoud is de verborgen kostenpost | Bij point-to-point besteed je 20-40% van je IT-budget aan onderhoud van bestaande koppelingen |
| Middleware is niet altijd het antwoord | Voor eenvoudige koppelingen (order → email) is een tool als Zapier vaak effectiever dan zware middleware |
| Hybride aanpak werkt het beste | Combineer eenvoudige point-to-point voor simpele taken met middleware voor complexe datastromen |
Wat is point-to-point integratie precies?
Point-to-point betekent: systeem A praat rechtstreeks met systeem B. Je webshop stuurt een nieuwe order direct naar je boekhouding. Je ERP pusht een voorraadwijziging naar je webshop. Directe verbinding, geen tussenschakel.
Dit gebeurt meestal via API's — een technische manier waarop systemen data uitwisselen. De ene stuurt een bericht (bijvoorbeeld "nieuwe order #12345"), de ander leest dat bericht en verwerkt het. Moderne systemen gebruiken meestal REST API's met JSON-data, oudere systemen nog wel eens SOAP of XML.
Voor veel bedrijven begint het met een plugin of standaard koppeling. Je gebruikt WooCommerce en installeert de Exact Online plugin. Klaar. Orders stromen automatisch naar je boekhouding. Het werkt, het is betaalbaar, je bent binnen een middag live.
En dat is ook precies de kracht van point-to-point: snelheid en eenvoud bij een beperkt aantal systemen.
Wat ik in de praktijk zie: bedrijven die starten met 2-3 systemen hebben met point-to-point vaak binnen een week werkende koppelingen. Bij middleware ben je al snel 3-4 weken bezig met alleen het opzetten van de hub.
De techniek achter point-to-point is relatief simpel. Systeem A heeft een "connector" (of plugin, of custom script) die weet hoe systeem B werkt. Die connector vertaalt data van A naar het formaat dat B begrijpt. Elke koppeling heeft zijn eigen vertaallaag.
Het spaghetti-probleem: wanneer point-to-point escaleert
Hier wordt het interessant. Bij elke toevoeging van een systeem heb je niet één nieuwe koppeling nodig, maar meerdere. Waarom? Omdat nieuwe systemen vaak met alle bestaande systemen moeten praten.
De wiskundige formule is: n(n-1)/2, waarbij n het aantal systemen is.
| Aantal systemen | Benodigde koppelingen | Verschil met vorige |
|---|---|---|
| 3 systemen | 3 koppelingen | - |
| 5 systemen | 10 koppelingen | +7 |
| 7 systemen | 21 koppelingen | +11 |
| 10 systemen | 45 koppelingen | +24 |
| 15 systemen | 105 koppelingen | +60 |
Neem een installatiebedrijf dat start met AFAS (ERP) en Twinfield (boekhouding). Eén koppeling. Later komen er bij: planning software, urenregistratie app, CRM, klantportaal, en facturatie-tool. Dat zijn 7 systemen. Opeens heb je 21 mogelijke koppelingen nodig.
Niet alle 21 koppelingen zijn nodig, maar stel je hebt er 12 actief. Dan betekent een update in AFAS dat je potentieel 6 verschillende koppelingen moet controleren. Een API-wijziging in Twinfield? Nog eens 5 koppelingen testen.
Volgens het CBS gebruiken Nederlandse MKB-bedrijven gemiddeld 4-6 verschillende softwarepakketten. Bij bedrijven met 50+ medewerkers loopt dat op naar 10-15 applicaties. Het spaghetti-probleem is dus niet hypothetisch — het raakt het merendeel van het groeiende MKB.
Middleware en hub-and-spoke uitgelegd
Middleware draait het probleem om. In plaats van dat elk systeem met elk ander systeem praat, introduceer je een centrale hub. Alle systemen praten alleen met die hub. De hub zorgt voor de vertaling en routering.
Het heet ook wel "hub-and-spoke" architectuur. De hub is het middelpunt, de systemen zijn de spaken. Voeg je een nieuw systeem toe? Dan bouw je één nieuwe koppeling: van dat systeem naar de hub. Klaar.

Bij 7 systemen heb je nu 7 koppelingen in plaats van 21. Bij 15 systemen: 15 koppelingen in plaats van 105. Het scheelt enorm in complexiteit.
Maar er is meer. Een goede middleware-hub doet niet alleen routeren. Hij biedt ook:
- Canonical data model — de hub definieert wat een "klant" is, wat een "order" is. Alle systemen vertalen hun data naar dat standaardmodel. Geen 6 verschillende versies van hetzelfde klantadres.
- Message queue — berichten worden gebufferd. Als je boekhouding even offline is, wacht het bericht gewoon tot het systeem weer beschikbaar is.
- Transformatie-engine — complexe databewerkingen gebeuren centraal. "Als order > €500, check kredietlimiet, vraag goedkeuring manager, boek in voorraad" — dat soort logica hoeft niet in 5 verschillende koppelingen.
- Monitoring dashboard — één plek waar je ziet welke koppelingen draaien, waar fouten zitten, hoeveel berichten verwerkt zijn.
Er zijn verschillende middleware-oplossingen. Zware enterprise platforms zoals MuleSoft of Dell Boomi kosten al snel €30.000-200.000 per jaar. Voor het MKB zijn lichtere oplossingen als Make, Celigo, of maatwerk middleware (zoals SyncIT bouwt) realistischer.
Een productiebedrijf vertelde me: sinds we een middleware-hub hebben, duren nieuwe integraties een fractie van de tijd. We koppelen nu een nieuw systeem in 3 dagen in plaats van 3 weken, omdat de hub-infrastructuur er al ligt.
Kostenvergelijking: waar ligt het omslagpunt?
Laten we eerlijk rekenen. Point-to-point is goedkoper bij weinig systemen. Middleware is goedkoper bij veel systemen. Maar waar ligt de grens?
Stel: een standaard point-to-point koppeling kost €2.000 om te bouwen en €50/maand onderhoud. Een middleware-hub opzetten kost €8.000 en elke nieuwe connector kost €1.500 + €30/maand. Hoe ziet dat eruit?
| Aantal systemen | Point-to-point (eenmalig) | Point-to-point (jaar 1 totaal) | Middleware (eenmalig) | Middleware (jaar 1 totaal) |
|---|---|---|---|---|
| 3 systemen | €6.000 | €7.800 | €12.500 | €14.820 |
| 5 systemen | €20.000 | €26.000 | €15.500 | €17.620 |
| 7 systemen | €42.000 | €54.600 | €18.500 | €21.020 |
| 10 systemen | €90.000 | €117.000 | €23.000 | €26.620 |
Het omslagpunt ligt dus ergens tussen 4 en 6 systemen, afhankelijk van je specifieke situatie. En dat zijn alleen de directe kosten. Onderhoudskosten lopen bij point-to-point veel harder op.
Volgens Gartner liggen onderhoudskosten bij middleware-platforms 30-50% lager bij 5+ systemen. De reden? Updates hoef je maar één keer door te voeren (in de hub), niet in 10 verschillende koppelingen.
Daar komt nog iets bij. Bij point-to-point bouw je vaak via verschillende leveranciers. De webshop-koppeling door bureau A, de ERP-integratie door leverancier B, de custom API-koppeling door developer C. Bij een storing weet niemand waar te zoeken. Bij middleware heb je één aanspreekpunt.
Wanneer is point-to-point nog steeds de beste keuze?
Middleware klinkt geweldig, maar het is niet altijd de oplossing. Er zijn situaties waar point-to-point simpelweg logischer is.
Bij een beperkt aantal systemen
Als je 2-3 systemen hebt en die de komende jaren niet uitbreidt, is point-to-point vaak de snelste en goedkoopste optie. Een Shopify-webshop koppelen aan Exact Online? Gebruik gewoon de standaard app. Werkt binnen een uur.
Voor simpele, eenrichtingsverkeer koppelingen
"Nieuwe order → stuur email naar magazijn" of "Factuur betaald → update CRM status". Dat soort simpele triggers zijn perfect voor tools als Zapier of Make. Je hebt geen zware middleware nodig voor een actie die uit twee stappen bestaat.

Als er native integraties bestaan
Veel moderne cloud-software heeft ingebouwde koppelingen. Picqer heeft standaard koppelingen met alle grote webshop-platforms. Sendcloud integreert out-of-the-box met tientallen systemen. Gebruik die. Het is getest, het wordt onderhouden door de leverancier, en het kost je alleen een maandelijks bedrag.
Bij real-time, hoog-volume datastromen
Soms wil je juist géén tussenlaag. Een kassasysteem dat elke seconde transacties naar een database pusht, werkt vaak beter point-to-point dan via een middleware-hub. De extra vertaalslag kost tijd.
Wat werkt is: start met point-to-point voor je eerste koppelingen. Evalueer na elk nieuw systeem of je architectuur nog schaalbaar is. Migreer naar middleware zodra je merkt dat onderhoud meer tijd kost dan het ontwikkelen van nieuwe functionaliteit.
Wanneer wordt middleware noodzakelijk?
Er komt een moment dat point-to-point niet meer werkt. Herken je een van deze situaties?
Je hebt dezelfde data in 4+ systemen
Klantgegevens staan in je ERP, CRM, webshop, en boekhouding. Bij elke adreswijziging update je 4 plekken handmatig. Of je update één plek en de rest loopt uit de pas. Een middleware-hub definieert: het CRM is eigenaar van klantdata, alle andere systemen halen het daar vandaan.
Je verliest het overzicht
Orders komen binnen via je webshop, maar ook via email, telefoon, en Bol.com. Elke bron heeft een andere koppeling naar je voorraad. Één koppeling loopt vast en niemand merkt het tot een klant belt dat zijn order niet verstuurd is. Bij middleware zie je in één dashboard: welke koppelingen draaien, waar fouten zitten, hoeveel orders verwerkt zijn.
Elke systeemupdate breekt 3 andere koppelingen
Je ERP-leverancier brengt een nieuwe API-versie uit. Opeens werken je koppelingen met boekhouding, webshop, en CRM niet meer. Je bent een week bezig met repareren. Bij middleware update je één connector (ERP → hub), de rest blijft gewoon draaien.
Je wilt complexe bedrijfslogica toevoegen
"Als een B2B-klant meer dan €10.000 bestelt, check kredietlimiet in ERP, vraag goedkeuring bij manager, reserveer voorraad, stuur order naar productie, update CRM, en boek voorschot in boekhouding." Dat soort workflows bouw je niet in 6 verschillende point-to-point koppelingen. Dat doe je centraal in een middleware-hub.
Je schaalt snel
Bedrijven die groeien voegen snel systemen toe. Dit jaar een nieuw CRM, volgend jaar een productieplanning-tool, daarna een klantportaal. Bij point-to-point betekent elk nieuw systeem N nieuwe koppelingen. Bij middleware: 1 nieuwe koppeling en klaar. Zie ook onze branche-specifieke oplossingen voor voorbeelden uit verschillende sectoren.
Praktijkvoorbeelden uit verschillende sectoren
Groothandel bouwmaterialen
Start met webshop, voorraadsysteem, en boekhouding. Drie point-to-point koppelingen via plugins. Werkt prima tot ze een B2B-portal toevoegen, verzendplatform, en inkoop-tool. Opeens 15 koppelingen, allemaal verschillend gebouwd. Overstap naar middleware: elk systeem één keer gekoppeld aan de hub, nieuwe leverancier toevoegen kost nu 2 dagen in plaats van 2 weken.
Installatiebedrijf
ERP voor projectadministratie, planning-app voor monteurs, urenregistratie, boekhouding, en klantportaal. Bij point-to-point moest een order handmatig uit ERP naar planning, van planning naar urenregistratie, van uren naar boekhouding. Met middleware loopt een order automatisch door alle systemen, inclusief statusupdates naar het klantportaal.
Productiebedrijf
Gebruikt AFAS, productieplanning-software, kwaliteitscontrole-systeem, machinedata (IoT), en BI-rapportage. Bij 7 systemen waren 21 point-to-point koppelingen theoretisch mogelijk. In praktijk waren er 12 actief, gebouwd door 4 verschillende leveranciers. Een API-wijziging in AFAS betekende 6 andere partijen bellen. Middleware maakte het beheersbaar: één AFAS-connector, alle data stroomt via de hub naar de juiste plekken.
Meer voorbeelden? Bekijk onze klantverhalen of verken populaire integratie-combinaties voor jouw sector.
De hybride aanpak: het beste van beide werelden
Hier is waar het interessant wordt. Je hoeft niet te kiezen tussen alleen point-to-point of alleen middleware. De meeste succesvolle MKB-bedrijven gebruiken een combinatie.
De vuistregel: gebruik point-to-point voor eenvoudige, lage-volume koppelingen. Gebruik middleware voor complexe datastromen en systemen die met meerdere andere systemen praten.
Praktisch voorbeeld:
- Point-to-point: Webshop → Sendcloud (verzendlabels printen). Simpel, eenrichtingsverkeer, standaard koppeling beschikbaar.
- Via middleware: ERP ↔ Webshop ↔ Voorraad ↔ Boekhouding. Complexe data, meerdere systemen, bedrijfslogica nodig.
- Point-to-point: Nieuwe factuur → email naar klant. Trigger-based, geen complexe transformatie.
- Via middleware: Order → kredietcheck → goedkeuring → productie → facturatie. Multi-step workflow over 5 systemen.
Een transportbedrijf werkt bijvoorbeeld met Zapier voor simpele notificaties ("rit voltooid → update klant"), maar middleware voor de kernprocessen (ritten → facturatie → boekhouding → salarisadministratie). Simpel waar het kan, robuust waar het moet.
Deze hybride aanpak geeft je flexibiliteit. Je kunt snel experimenteren met nieuwe tools via een point-to-point koppeling. Werkt het? Migreer dan naar de middleware-hub voor betrouwbaarheid en schaalbaarheid. Werkt het niet? Verwijder de koppeling zonder je hele architectuur aan te passen.
Veelgestelde vragen
Wat is het verschil tussen middleware en een API?
Een API is een interface waarmee systemen met elkaar kunnen praten. Middleware is een laag die tussen systemen zit en de communicatie coördineert. Alle middleware gebruikt API's, maar niet elke API-koppeling is middleware. Point-to-point koppelingen gebruiken ook API's, maar zonder centrale hub.
Is middleware altijd duurder dan point-to-point?
Nee. Bij 2-3 systemen is point-to-point goedkoper. Vanaf ongeveer 5-7 systemen wordt middleware voordeliger, vooral door lagere onderhoudskosten. Een middleware-hub kost meer om op te zetten, maar bespaart op de lange termijn bij groei en systeemwijzigingen.
Kunnen we later nog overstappen van point-to-point naar middleware?
Ja, maar het is wel werk. Je moet bestaande koppelingen migreren naar de middleware-hub. Dat kan gefaseerd: start met de belangrijkste datastromen via middleware, laat eenvoudige koppelingen voorlopig point-to-point. Volledig migreren duurt vaak 2-6 maanden afhankelijk van complexiteit.
Welke middleware-oplossing is het beste voor MKB?
Dat hangt af van je situatie. Zapier of Make voor eenvoudige workflows (€20-200/maand). Celigo of Workato voor groeiend MKB met complexere behoeften (€500-3000/maand). Maatwerk middleware voor bedrijven met specifieke eisen of veel legacy-systemen. Enterprise platforms zoals MuleSoft zijn meestal overkill voor MKB.
Hoeveel systemen kan je koppelen voordat je middleware nodig hebt?
Er is geen hard getal, maar de praktijk wijst uit: tot 4-5 systemen is point-to-point vaak prima. Bij 6-8 systemen wordt het lastig. Boven de 10 systemen is middleware bijna altijd noodzakelijk. Het hangt ook af van hoe complex je datastromen zijn — 3 systemen met complexe bedrijfslogica kan al middleware rechtvaardigen.
Wat zijn de risico's van te veel point-to-point koppelingen?
Het grootste risico is technische schuld. Onderhoud kost steeds meer tijd en geld. Bij een systeemupdate moeten meerdere koppelingen aangepast worden. Niemand heeft meer overzicht wie welke koppeling gebouwd heeft. Data raakt inconsistent tussen systemen. En bij een storing is het onduidelijk waar het probleem zit.
Wil je weten welke architectuur het beste past bij jouw situatie? Plan een adviesgesprek en we denken mee over de optimale integratie-strategie voor jouw bedrijf — zonder verplichtingen, gewoon eerlijk advies op basis van wat echt werkt in de praktijk.