Zes systemen die elkaar allemaal rechtstreeks moeten kennen, leveren vijftien mogelijke koppelingen op. Voeg er een zevende systeem aan toe en het worden er 21. Op dat punt gaan veel IT managers op zoek naar middleware, vaak zonder precies te weten wat de term inhoudt en of ze het werkelijk nodig hebben.
Middleware is software die tussen je applicaties in zit en berichten, data en processen tussen systemen doorgeeft en vertaalt. Elk systeem praat alleen met de middleware in plaats van met alle andere systemen afzonderlijk. Zo houd je het aantal koppelingen beperkt en regel je vertaling, foutafhandeling en logging op één centrale plek.
Hieronder lees je waarom losse koppelingen uitgroeien tot spaghetti, welke soorten middleware er zijn, wanneer een enkele API koppeling volstaat en wat je moet regelen als je kiest voor een integratieplatform of een eigen integratielaag. Geschreven voor IT managers en operationeel verantwoordelijken, dus elke technische term krijgt een uitleg in gewone taal.
Waarom middleware: losse koppelingen groeien uit tot spaghetti
Software koppelen begint overzichtelijk: de webshop stuurt orders naar het ERP, klaar. De tweede en derde koppeling gaan meestal ook nog goed. Het probleem ontstaat als elk systeem rechtstreeks met elk ander systeem praat, want dan groeit het aantal koppelingen sneller dan het aantal systemen.
De rekensom is simpel. Bij drie systemen zijn er drie mogelijke koppelingen, bij vier zijn het er zes en bij zes systemen al vijftien. Elke koppeling heeft eigen scripts, eigen foutafhandeling en eigen aannames over de data. Verandert er een veld in het ERP, dan moet je al die koppelingen één voor één nalopen.
Mark, IT manager bij een technische groothandel met 120 medewerkers, herkent dit. Zijn organisatie draait op een ERP, een webshop, een WMS dat het magazijn aanstuurt en een boekhoudpakket. In vijf jaar zijn er elf koppelingen ontstaan, gebouwd door drie verschillende leveranciers en één inmiddels vertrokken collega. Toen het ERP een nieuw formaat voor artikelnummers kreeg, vielen drie koppelingen stil en wist niemand welk script waar draaide. Het duurde vier dagen voordat de orders weer doorliepen naar het magazijn.
Met middleware ziet dat er anders uit. Elk systeem levert zijn data af bij de integratielaag en haalt daar op wat het nodig heeft. De vertaling van artikelnummers gebeurt op één plek, de logging staat op één plek en bij een storing zie je in één overzicht welk bericht is blijven hangen. Op onze pagina over software integratie lees je hoe we ERP, webshop en magazijnsystemen aan elkaar knopen.
Soorten middleware in gewone taal
De term middleware dekt een familie van oplossingen. Ze pakken allemaal hetzelfde probleem aan, elk op een andere schaal en met een andere manier van werken. Dit zijn de vijf soorten die je in de praktijk tegenkomt.
- API gateway. Eén centrale voordeur waar alle aanvragen van buitenaf binnenkomen, die controleert wie er aanklopt en de aanvraag doorstuurt naar het juiste systeem.
- Message queue. Een wachtrij waarin systemen berichten achterlaten, zodat de ontvanger ze in eigen tempo ophaalt en niets verloren gaat als een systeem even offline is.
- ESB (enterprise service bus). Een centrale bus waarop alle systemen zijn aangesloten en die berichten routeert, vertaalt en bewaakt; vooral in gebruik bij grote organisaties met tientallen applicaties.
- iPaaS (integration platform as a service). Een integratieplatform in de cloud, zoals Alumio of Boomi, waarin je met standaardconnectoren koppelingen tussen gangbare pakketten inricht zonder alles zelf te programmeren.
- Eigen integratielaag. Maatwerksoftware die precies de vertalingen, regels en controles bevat die jouw organisatie nodig heeft, en waar je zelf eigenaar van bent.
Deze soorten sluiten elkaar niet uit. Een iPaaS gebruikt intern vaak een message queue, en een eigen integratielaag kan achter een API gateway hangen. De vraag is welke combinatie past bij het aantal systemen, de hoeveelheid data en de eisen aan betrouwbaarheid.
Onder al deze varianten ligt hetzelfde bouwblok: de API. Een API is de afgesproken manier waarop een systeem vragen beantwoordt en data afgeeft; Wikipedia legt het begrip uitgebreid uit. Middleware gebruikt die API's en voegt er de laag bovenop die vertaalt, bewaakt en herstelt. In ons artikel over de API koppeling lees je hoe zo'n enkele koppeling werkt.
Wanneer volstaat een API koppeling en wanneer heb je middleware nodig
Middleware is een investering in structuur, en die investering moet je terugverdienen. Bij twee systemen die één soort bericht uitwisselen, is een rechtstreekse API koppeling bijna altijd de betere keuze. Die is eenvoudiger, sneller gebouwd en makkelijker te begrijpen voor de volgende beheerder.
De balans slaat om zodra een van deze vier factoren gaat knellen:
- Aantal systemen. Vanaf vier of vijf systemen die onderling data delen, wordt het overzicht sneller een probleem dan de techniek.
- Volumes. Duizenden berichten per uur vragen om een wachtrij en om buffering, anders houdt het traagste systeem de rest op.
- Foutafhandeling. Als een mislukte order stilzwijgend verdwijnt en pas opvalt bij de klant, heb je een centrale plek nodig die fouten vangt en opnieuw aanbiedt.
- Monitoring. Zodra de vraag of een bericht is aangekomen een zoektocht door vier logbestanden oplevert, verdient centrale monitoring zich snel terug.
Ook verouderde systemen spelen een rol. Joris, operationeel directeur bij een machinebouwer met 80 medewerkers, werkt met een productiesysteem uit 2009 dat niemand meer durft aan te raken. De nieuwe planningstool moet er toch mee praten. In plaats van het oude systeem open te breken, zet Joris er een integratielaag omheen die de verouderde bestandsexport vertaalt naar berichten die de planningstool begrijpt. Het productiesysteem blijft ongemoeid, de rest van de organisatie werkt met actuele data en de vervanging kan later stap voor stap.
Dezelfde volgorde hanteren we bij legacy modernisering: eerst de koppelvlakken, dan de modules. Hoe je zulke systemen herkent en wanneer je ze vervangt, lees je in ons artikel over legacy systemen. Het NCSC beschrijft de risico's van legacy systemen vanuit het oogpunt van beveiliging.
Voor Deron koppelden we RFID scanners aan de productcatalogus en het ERP, zodat productiedata zonder handmatig overtypen in het ERP terechtkomt. Die case en andere integratieprojecten vind je bij onze klantcases.
Standaardplatform of eigen integratielaag
Kies je voor middleware, dan volgt de keuze tussen een standaard integratieplatform en een eigen laag die je laat bouwen. Deze tabel helpt bij de afweging.
| Situatie | Meestal de beste keuze |
|---|---|
| Vooral standaardpakketten (Exact, AFAS, Shopify, Salesforce) met bestaande connectoren | iPaaS |
| Eigen bedrijfsregels bepalen hoe data vertaald en gecontroleerd wordt | Eigen integratielaag |
| Hoge volumes of strenge eisen aan doorlooptijd | Eigen laag met message queue |
| Weinig eigen ontwikkelcapaciteit en snel resultaat gewenst | iPaaS |
| Data mag de eigen omgeving niet verlaten (zorg, overheid) | Eigen laag op eigen infrastructuur |
Een iPaaS rekent meestal per connector of per berichtvolume, dus bij groeiende aantallen berichten loopt het abonnement mee omhoog. Een eigen integratielaag kost vooraf meer bouwtijd en is daarna van jou. Vaak is de combinatie het sterkst: standaardconnectoren voor de gangbare pakketten en maatwerk API's voor de stukken waar jouw proces afwijkt van de rest van de markt.
Wat je moet regelen: logging, retry, versiebeheer en eigenaarschap
Middleware lost het spaghettiprobleem alleen op als je een paar dingen vanaf dag één goed regelt. Anders verplaats je de chaos naar één centrale plek, en dat is nauwelijks een verbetering.
- Logging. Elk bericht krijgt een uniek kenmerk, zodat je van een order kunt terugvinden wanneer hij binnenkwam, waar hij naartoe ging en waar hij eventueel is blijven hangen.
- Retry. Een mislukt bericht wordt automatisch opnieuw aangeboden, met een oplopende wachttijd, en belandt na een vast aantal pogingen in een aparte lijst die iemand bekijkt.
- Versiebeheer. Systemen veranderen. Een nieuwe versie van de ERP API mag de oude koppeling pas vervangen als de nieuwe getest is, en dat vraagt om versies die tijdelijk naast elkaar draaien.
- Eigenaarschap. Eén persoon of team is verantwoordelijk voor de integratielaag, kent de vertaalregels en beslist over wijzigingen. Zonder eigenaar wordt middleware binnen twee jaar opnieuw een zwarte doos.
Dat laatste punt wordt in onze ervaring het vaakst onderschat. In 100+ projecten over ruim dertig jaar zagen we dat de techniek zelden het probleem is; het gaat mis als de kennis over de koppelingen bij één persoon zit of bij een leverancier die inmiddels verdwenen is. Daarom bouwen we integratielagen met hetzelfde team dat ze daarna beheert, met 30+ engineers in Nijmegen en Sarajevo en een werkwijze die ISO 9001 en ISO 27001 gecertificeerd is.
Veelgestelde vragen
Wat is middleware in eenvoudige taal?
Middleware is de tussenlaag die je systemen met elkaar laat praten. Elk systeem levert zijn berichten af bij die laag en haalt daar op wat het nodig heeft, in plaats van rechtstreeks met alle andere systemen te koppelen. De tussenlaag vertaalt de data, bewaakt of berichten aankomen en biedt ze opnieuw aan als er iets misgaat.
Wat is het verschil tussen middleware en een API?
Een API is de afgesproken ingang van één systeem: de manier waarop dat systeem vragen beantwoordt en data afgeeft. Middleware gebruikt de API's van meerdere systemen en voegt er een laag bovenop die vertaalt, routeert en fouten afhandelt. Een API koppeling verbindt twee systemen; middleware beheert de verbindingen tussen veel systemen tegelijk.
Wanneer heb je middleware nodig?
Zodra vier of meer systemen onderling data delen, de volumes oplopen of een verdwenen bericht directe schade oplevert. Bij twee systemen met één soort bericht volstaat meestal een rechtstreekse API koppeling. Het kantelpunt ligt waar het onderhoud van losse koppelingen meer tijd kost dan het inrichten van één centrale laag.
Wat is systeemintegratie?
Systeemintegratie is het geheel van maatregelen waarmee je losse applicaties als één samenhangend geheel laat werken: koppelingen, datavertaling, procesafspraken en beheer. Middleware is een van de hulpmiddelen daarvoor, naast API koppelingen, bestandsuitwisseling en het opschonen van stamdata. De termen software integratie en systeemintegratie worden in de praktijk door elkaar gebruikt.
Samengevat
- Middleware zit tussen je applicaties en geeft berichten, data en processen door, met vertaling en foutafhandeling op één plek.
- Rechtstreekse koppelingen groeien sneller dan het aantal systemen: zes systemen betekenen vijftien mogelijke koppelingen.
- API gateway, message queue, ESB, iPaaS en een eigen integratielaag zijn verschillende antwoorden op hetzelfde probleem; vaak combineer je ze.
- Bij twee systemen volstaat een API koppeling; vanaf vier of vijf systemen, hoge volumes of strenge eisen aan foutafhandeling verdient middleware zich terug.
- Logging, retry, versiebeheer en een duidelijke eigenaar bepalen of de integratielaag over drie jaar nog te beheren is.
De volgende stap is een inventarisatie: welke systemen je hebt, welke berichten ertussen stromen en waar het nu misgaat. Met dat overzicht op tafel is de keuze tussen een API koppeling, een integratieplatform of een eigen laag meestal snel gemaakt. Stuur ons je systeemlandschap en we denken vrijblijvend mee over de aanpak die past. Neem contact op voor een verkennend gesprek; we zeggen het ook eerlijk als een enkele API koppeling volstaat.
