Veel systemen praten technisch met elkaar, maar begrijpen elkaar functioneel niet. En precies daar begint het echte werk.
Een ERP denkt in transacties en financiële waarheid. Een productielijn denkt in timing en continuïteit. Management wil dashboards. Security wil controleerbaarheid. En de operator op de vloer wil vooral dat z’n machine morgen nog steeds doet wat ‘ie vandaag doet.
Technisch kun je die werelden prima aan elkaar knopen. API hier, message queue daar, wat JSON ertussen — klaar. Zo staat het ook in de architectuurplaatjes.
Alleen werkt het in de praktijk zelden zo.
Middleware vertaalt niet alleen protocollen. Ze vertaalt verwachtingen.
Een ERP wil nu weten of een order verwerkt is. Een machine op de werkvloer kan daar soms helemaal niet op reageren — niet omdat de koppeling kapot is, maar omdat de fysieke werkelijkheid een ander ritme heeft dan een transactiesysteem. Dat is geen bug. Dat is een fundamenteel verschil in hoe die twee werelden naar tijd kijken.
Ik kom dit soort mismatches constant tegen. Niet als abstracte architectuurvraagstukken, maar als heel concrete problemen. Een besturingssysteem dat overbelast raakt omdat een IT-systeem te agressief pollt. Een bericht dat drie keer herschreven wordt voordat het aankomt, en niemand weet meer waarom. Een tijdelijke workaround uit 2017 die stilletjes de ruggengraat van een hele koppeling is geworden.
In OT/IT-omgevingen wordt dit extra scherp.
IT is gebouwd rondom consistentie, authenticatie en beheersbaarheid. OT draait om stabiliteit, beschikbaarheid en voorspelbaar gedrag. Een productielijn die vijf seconden stilvalt omdat een certificaat vernieuwd moet worden — dat is geen klein incident. Dat is productieverlies, en soms een veiligheidsrisico.
Dus moet ergens bepaald worden wat “realtime” eigenlijk betekent. Welke fouten acceptabel zijn. Wie leading is bij conflicten. Hoe lang data geldig blijft. Wat er gebeurt als een systeem wegvalt. Welke acties automatisch mogen en welke niet.
En dat gebeurt opvallend vaak in middleware.
In het diagram hieronder zie je precies die structuur: bovenaan de IT-systemen met hun eigen logica en verwachtingen, onderaan de OT-systemen met een fundamenteel ander ritme — en middleware ertussenin als de laag die beide werelden vertaalt.
Wat je daar in de praktijk ziet:
- Validatie van berichten voordat ze een machine bereiken.
- Protocolconversie tussen systemen die nooit voor elkaar bedoeld waren.
- Throttling om de OT-omgeving te beschermen tegen IT-verkeer.
- Buffering wanneer systemen op verschillende snelheden draaien.
- Auditlogging voor compliance en fallback-logica voor wanneer een koppeling uitvalt.
Klinkt als een strakke architectuur. Maar in de praktijk groeit dit organisch. Onder druk, tijdens een storing of een migratie. Omdat er nu een probleem opgelost moet worden. En dat is precies waar het gevaarlijk wordt.
Middleware: waar compromissen samenkomen
Middleware wordt stilletjes de plek waar technische én organisatorische compromissen samenkomen. Businessregels verdwijnen in scripts. Tijdelijke fixes worden permanent. Niemand documenteert waarom een bepaalde vertraging erin zit, want op het moment dat het gebouwd werd was het “even snel iets fixen.” Drie jaar later is het verborgen bedrijfslogica geworden en durft niemand het meer aan te raken.
Ik zeg dit niet om te oordelen — ik heb het zelf gebouwd, in omgevingen waar je niet de luxe had om eerst een architectuurreview te doen. Maar juist daarom weet ik: middleware vraagt om architectuurdenken. Niet alleen technisch. Ook organisatorisch. Want uiteindelijk gaat het niet over data. Het gaat over grenzen — tussen systemen, teams, verantwoordelijkheden en werkelijkheden.
Goede middleware verbergt complexiteit niet. Ze maakt het hanteerbaar.