Middleware bezeichnet eine Softwareschicht, die zwischen zwei oder mehreren Anwendungen oder Systemen vermittelt und deren Kommunikation ermöglicht, ohne dass diese Systeme direkt miteinander verbunden sein müssen. Sie fungiert als technischer Vermittler: Sie empfängt Nachrichten oder Daten von einem System, transformiert sie bei Bedarf in das Format des Empfängers und leitet sie weiter – ähnlich einem Dolmetscher, der zwei Parteien mit unterschiedlichen Sprachen ermöglicht, miteinander zu sprechen.
Middleware ist ein breit verwendeter Begriff, der verschiedene Technologietypen umfasst – von Message Brokern über API-Gateways bis zu Integrations-Plattformen. In der modernen Unternehmens-IT und Automatisierungsarchitektur spielt Middleware eine zentrale Rolle: Sie löst das Problem der Systemheterogenität – dass verschiedene Systeme unterschiedliche Protokolle, Formate und Schnittstellen verwenden und nicht direkt miteinander kommunizieren können oder sollen.
Middleware als Vermittlungsschicht
Quellsystem
ERP, CRM, Webshop, Legacy-System – sendet Daten in eigenem Format
Middleware
Empfängt, transformiert, routet, protokolliert – vermittelt zwischen allen Systemen
Zielsystem
ERP, Datenbank, Reporting – empfängt Daten im eigenen erwarteten Format
Arten von Middleware
- Message Broker: Empfängt Nachrichten von Sendern und leitet sie asynchron an Empfänger weiter – entkoppelt Sender und Empfänger zeitlich und räumlich. Bekannte Beispiele: Apache Kafka, RabbitMQ
- API-Gateway: Zentrale Eintrittspunkt für alle API-Anfragen – verwaltet Authentifizierung, Rate Limiting, Routing und Logging für alle APIs eines Systems
- Enterprise Service Bus (ESB): Klassisches Enterprise-Integrationsmuster – ein zentraler Bus, über den alle Systeme miteinander kommunizieren. Leistungsfähig, aber komplex
- iPaaS (Integration Platform as a Service): Cloud-basierte Integrationsplattform – Automationsplattformen wie Make oder MuleSoft sind moderne Formen von iPaaS-Middleware
- ETL-Tools: Extract, Transform, Load – spezialisierte Middleware für Datenpipelines zwischen Datenquellen und Datenziele
Middleware vs. direkte API-Integration
Bei einer direkten API-Integration kommunizieren System A und System B direkt miteinander – schnell und einfach, aber jede neue Verbindung zu einem weiteren System erfordert eigene Implementierung. Bei n Systemen entstehen theoretisch n×(n−1) direkte Verbindungen – ein Wartungsalbtraum. Middleware reduziert das auf n Verbindungen zur Middleware – jedes System spricht nur mit der Middleware, die das Routing übernimmt. Das ist der klassische Hub-and-Spoke-Vorteil.
Praxisbeispiel
Ein Handelsunternehmen betreibt sieben verschiedene Systeme: Webshop, Warenwirtschaft, CRM, Versanddienstleister, Buchhaltung, BI-Tool und Kundenkommunikationsplattform. Ohne Middleware: 42 potenzielle direkte Verbindungen zwischen allen Systemen – jede mit eigener Authentifizierung, eigenem Format und eigener Fehlerbehandlung. Mit Make als iPaaS-Middleware: Jedes der sieben Systeme ist einmal mit Make verbunden. Make orchestriert alle Datenflüsse – wenn eine Bestellung eingeht, verteilt Make die relevanten Daten an Warenwirtschaft, Versanddienstleister und Buchhaltung in den jeweils erwarteten Formaten. Wenn ein neues System hinzukommt, wird nur eine neue Verbindung zur Middleware aufgebaut – nicht sechs neue Verbindungen zu allen anderen Systemen.
