Middleware ist kein Kleber. Es ist ein Vermittler.

Viele Systeme sprechen technisch miteinander, verstehen sich aber funktional nicht. Und genau da beginnt die eigentliche Arbeit.

Ein ERP denkt in Transaktionen und finanzieller Wahrheit. Eine Produktionslinie denkt in Timing und Kontinuität. Das Management möchte Dashboards. Security möchte Auditierbarkeit. Und der Operator vor Ort möchte vor allem, dass seine Maschine morgen noch das macht, was sie heute macht.

Technisch kann man diese Welten perfekt verbinden. Eine API hier, eine Message Queue dort, etwas JSON dazwischen — fertig. So sieht es auch in Architekturdiagrammen aus.

Außer in der Praxis funktioniert es selten so.

Middleware übersetzt nicht nur Protokolle. Es übersetzt Erwartungen.

Ein ERP möchte jetzt wissen, ob ein Auftrag verarbeitet wurde. Eine Maschine in der Produktion kann darauf manchmal überhaupt nicht reagieren — nicht weil die Verbindung unterbrochen ist, sondern weil die physische Realität einen anderen Rhythmus hat als ein Transaktionssystem. Das ist kein Bug. Das ist ein fundamentaler Unterschied darin, wie diese beiden Welten Zeit betrachten.

Ich begegne solchen Mismatches ständig. Nicht als abstrakte Architekturfragen, sondern als sehr konkrete Probleme. Ein Steuerungssystem, das überlastet wird, weil ein IT-System zu aggressiv pollt. Eine Nachricht, die dreimal umgeschrieben wird, bevor sie ankommt, und niemand weiß mehr warum. Ein temporärer Workaround aus 2017, der still und heimlich zum Rückgrat einer gesamten Integration geworden ist.

In OT/IT-Umgebungen wird das noch schärfer.

IT ist auf Konsistenz, Authentifizierung und Verwaltbarkeit ausgelegt. OT läuft auf Stabilität, Verfügbarkeit und vorhersehbarem Verhalten. Eine Produktionslinie, die fünf Sekunden stoppt, weil ein Zertifikat erneuert werden muss — das ist kein kleiner Vorfall. Das ist Produktionsverlust und manchmal ein Sicherheitsrisiko.

Also muss irgendwo entschieden werden, was “Echtzeit” eigentlich bedeutet. Welche Fehler akzeptabel sind. Wer bei Konflikten Vorrang hat. Wie lange Daten gültig bleiben. Was passiert, wenn ein System ausfällt. Welche Aktionen automatisch passieren dürfen und welche nicht.

Und das passiert überraschend oft in Middleware.

Im Diagramm unten sieht man genau diese Struktur: oben die IT-Systeme mit ihrer eigenen Logik und ihren Erwartungen, unten die OT-Systeme mit einem fundamental anderen Rhythmus — und Middleware dazwischen als die Schicht, die beide Welten übersetzt.

Was man in der Praxis dort sieht:

• Validierung von Nachrichten, bevor sie eine Maschine erreichen.
• Protokollkonvertierung zwischen Systemen, die nie füreinander gedacht waren.
• Throttling zum Schutz der OT-Umgebung vor IT-Verkehr.
• Pufferung, wenn Systeme mit unterschiedlichen Geschwindigkeiten laufen.
• Audit-Logging für Compliance und Fallback-Logik, wenn eine Schnittstelle ausfällt.

Klingt nach einer sauberen Architektur. Aber in der Praxis wächst das organisch. Unter Druck, während eines Ausfalls oder einer Migration. Weil ein Problem jetzt gelöst werden muss. Und genau da wird es gefährlich.

Middleware: wo Kompromisse zusammenlaufen

Middleware wird still und leise zum Ort, wo technische und organisatorische Kompromisse zusammenlaufen. Geschäftsregeln verschwinden in Skripten. Temporäre Fixes werden permanent. Niemand dokumentiert, warum eine bestimmte Verzögerung darin ist, weil es im Moment des Bauens “nur ein schneller Fix” war. Drei Jahre später ist es versteckte Geschäftslogik geworden, und niemand traut sich mehr, es anzufassen.

Das sage ich nicht, um zu urteilen — ich habe es selbst gebaut, in Umgebungen, wo man den Luxus eines Architecture Reviews nicht hatte. Aber genau deshalb weiß ich: Middleware erfordert architektonisches Denken. Nicht nur technisch. Auch organisatorisch. Denn letztendlich geht es nicht um Daten. Es geht um Grenzen — zwischen Systemen, Teams, Verantwortlichkeiten und Realitäten.

Gute Middleware versteckt Komplexität nicht. Sie macht sie handhabbar.