Überblick
Application Integration (Anwendungsintegration) ist die Architekturdisziplin, die unabhängig voneinander entwickelte Anwendungen, Datenbanken, Cloud-Services und Feldgeräte über eine gemeinsame Datensprache sicher und konsistent miteinander kommunizieren lässt. Wenn eine Bestellung vom Onlineshop ins ERP, von dort in das Lagerverwaltungssystem und an die API des Paketdienstleisters gelangt oder Sensordaten einer Produktionslinie in Echtzeit auf eine Reporting-Plattform fließen, ist das das Ergebnis einer gut konzipierten Integrationsschicht. Indexline entwirft, implementiert und betreibt diese Schicht im Managed-Service-Modell.
Das Anwendungsportfolio von Unternehmen wächst jedes Jahr – doch diese Anwendungen arbeiten oft, ohne voneinander zu wissen. Dieselben Kundendaten werden in drei Systemen in drei unterschiedlichen Formaten gepflegt, Berichte werden manuell über Excel-Dateien zusammengeführt, und eine Änderung in einem System erscheint erst Stunden später im anderen. Diese Brüche kommen als Dateninkonsistenz, operative Verzögerungen und sinkende Entscheidungsqualität zurück. Integration ist die unsichtbare, aber entscheidendste Infrastrukturkomponente der digitalen Transformation: Eine durchgängige Automatisierung von Geschäftsprozessen ist nur möglich, wenn Systeme zuverlässig miteinander verbunden sind.
Das moderne Integrationsökosystem beruht auf zwei grundlegenden Kommunikationsmodellen. Bei der synchronen Kommunikation werden REST-, GraphQL- oder gRPC-basierte APIs mit OpenAPI dokumentiert und über API-Gateways wie Kong oder Apache APISIX mit Authentifizierung, Rate Limiting und Versionierung bereitgestellt. Bei der asynchronen Kommunikation kommen Messaging-Infrastrukturen wie MQTT, Apache Kafka und RabbitMQ zum Einsatz. MQTT ist dank seiner schlanken Struktur und des Publish/Subscribe-Modells ideal für IoT-Geräte und Verbindungen mit geringer Bandbreite; Kafka wird für hochvolumige Event-Streams, RabbitMQ für zuverlässige Job-Queues bevorzugt.
Eine ungeplant wachsende Integration hat ihren Preis. Punkt-zu-Punkt-Verbindungen, die bei jedem Bedarf direkt zwischen zwei Systemen programmiert werden, entwickeln sich mit der Zeit zur sogenannten „Spaghetti-Integration“ – einer fragilen Struktur, deren vollständige Landkarte niemand kennt. Ein Versions-Upgrade eines einzigen Systems kann Dutzende Verbindungen unterbrechen, fehlerhafte Nachrichten können unbemerkt verloren gehen, und personenbezogene Daten können über unverschlüsselte Kanäle fließen. Daraus entstehen sowohl ein erhebliches Compliance-Risiko im Hinblick auf das KVKK (türkisches Datenschutzgesetz) als auch eine Sichtbarkeitslücke, die eine Ursachenanalyse im Ernstfall nahezu unmöglich macht.
Indexline betrachtet Integration nicht als einmaliges Softwareprojekt, sondern als lebendige Plattform, die kontinuierlich betrieben werden muss. Zunächst wird die bestehende Landkarte der Anwendungen und Datenflüsse erstellt, anschließend wird eine Zielarchitektur auf Basis von API-First- und ereignisgesteuerten (Event-driven) Prinzipien entworfen. API-Gateway, MQTT-Broker und Message Queues werden hochverfügbar auf Kubernetes aufgebaut; jeder Datenfluss wird nachvollziehbar, wiederholbar und auditierbar gestaltet. Nach der Inbetriebnahme übernimmt das Indexline-Team im Rahmen des SLA das 24/7-Monitoring, das Kapazitätsmanagement, Versionsupdates sowie die Bearbeitung neuer Integrationsanforderungen.
So funktioniert es
Analyse und Inventarisierung: Bestehende Anwendungen, Datenbanken, Feldgeräte, externe Services und die Datenflüsse zwischen ihnen werden erfasst. Punkt-zu-Punkt-Verbindungen, manuelle Datenübertragungen und kritische Abhängigkeiten werden dokumentiert.
Entwurf der Zielarchitektur: Es wird festgelegt, welcher Datenfluss über synchrone APIs und welcher über asynchrones Messaging laufen soll. Eine Referenzarchitektur aus API-Gateway, MQTT-Broker, Event-Streaming-Plattform und Integrationsservices wird erstellt.
Datenmodell und Verträge: Gemeinsame Datenmodelle, OpenAPI- und AsyncAPI-Verträge, die MQTT-Topic-Hierarchie und Nachrichtenschemata werden definiert. Regeln für Versionierung und Abwärtskompatibilität werden festgelegt.
Sicherheitskonzept: Authentifizierung mit OAuth 2.0 / OpenID Connect, Verschlüsselung zwischen Services mit mTLS, gerätebezogenes Zertifikatsmanagement und Autorisierungsrichtlinien auf Topic-Ebene (ACL) werden umgesetzt.
Plattformaufbau: API-Gateway, MQTT-Broker-Cluster und Message Queues werden hochverfügbar auf Kubernetes aufgebaut. Die gesamte Konfiguration wird nach dem IaC- und GitOps-Ansatz unter Versionskontrolle gehalten.
Integrationsentwicklung: Konnektoren, Transformationsregeln, Fehlerbehandlung sowie Retry- und Dead-Letter-Queue-Mechanismen werden entwickelt. Die Datenflüsse werden in der Testumgebung End-to-End validiert.
Schrittweise Migration: Bestehende Punkt-zu-Punkt-Verbindungen werden nach Priorität auf die neue Plattform überführt. Durch Parallelbetrieb und vergleichende Validierung erfolgt die Migration ohne Betriebsunterbrechung.
Managed Operations: Nachrichtenlatenz, Fehlerrate, Queue-Tiefe und API-Antwortzeiten werden rund um die Uhr (24/7) überwacht. Incident-Management, Kapazitätsplanung, Versionsupdates und neue Integrationsanforderungen werden von Indexline im Rahmen des SLA verantwortet.
Wichtigste Funktionen
API-Gateway-Management
REST-, GraphQL- und gRPC-Services werden über ein einziges Gateway bereitgestellt. Authentifizierung, Rate Limiting, Caching und Versionierung werden zentral verwaltet.
MQTT-Broker-Infrastruktur
Über einen im Cluster betriebenen MQTT-Broker kommunizieren Tausende von Geräten und Anwendungen nach dem Publish/Subscribe-Modell. QoS-Stufen, persistente Sessions und Retained Messages werden entsprechend den geschäftlichen Anforderungen konfiguriert.
Ereignisgesteuerte Architektur
Mit Apache Kafka oder RabbitMQ kommunizieren Systeme lose gekoppelt über Ereignisse. Verlangsamt sich ein System oder befindet es sich in Wartung, werden die übrigen nicht angehalten.
Vorgefertigte Konnektoren und Transformation
Für ERP, CRM, Datenbanken, Fileserver und SaaS-Anwendungen werden Konnektoren eingesetzt. Zwischen Formaten wie JSON, XML, CSV und EDI erfolgen Transformation und Datenanreicherung.
End-to-End-Nachvollziehbarkeit
Jede Nachricht und jeder API-Aufruf wird über eine Korrelations-ID verfolgt. Mit verteiltem Tracing auf Basis von OpenTelemetry lässt sich innerhalb von Minuten feststellen, in welchem System ein Vorgang hängt.
Fehlertoleranz und Wiederholung
Automatische Wiederholungen bei temporären Fehlern, eine Dead Letter Queue bei dauerhaften Fehlern und idempotente Verarbeitung stellen sicher, dass keine Nachricht unbemerkt verloren geht oder doppelt verarbeitet wird.
Mehrschichtige Sicherheit
Mit TLS-verschlüsselten Kanälen, mTLS, OAuth 2.0, Gerätezertifikaten und Topic-basierter Autorisierung wird die Integrationsschicht nach Zero-Trust-Prinzipien geschützt.
Entwicklerportal
Über ein Entwicklerportal mit API-Katalog, interaktiver Dokumentation und Schlüsselverwaltung können interne Teams und Geschäftspartner Integrationen im Self-Service starten.
Vorteile & Nutzen
Manuelle Datenübertragungen und doppelte Dateneingaben entfallen; die operative Fehlerquote und die Arbeitslast der Mitarbeitenden sinken deutlich.
Der Datenfluss zwischen Systemen nähert sich der Echtzeit an; Management- und Außendienstteams entscheiden auf Basis aktueller Daten.
Da anstelle von Punkt-zu-Punkt-Verbindungen eine zentrale Integrationsschicht aufgebaut wird, verkürzt sich die Zeit für das Hinzufügen neuer Anwendungen oder das Ablösen von Altsystemen.
Dank ereignisgesteuerter Architektur legen Störungen oder Wartungsarbeiten in einem System die anderen Systeme nicht lahm; die Geschäftskontinuität steigt.
Da alle Datenflüsse zentral überwacht und protokolliert werden, lassen sich Nachweise für KVKK- und interne Auditprozesse leichter erbringen.
Da Aufbau, Monitoring und Aktualisierung der Integrationsplattform an Indexline übergeben werden, kann sich die interne IT auf wertschöpfende Projekte konzentrieren.
Dokumentierte APIs und ein Entwicklerportal beschleunigen die digitale Zusammenarbeit mit Geschäftspartnern, Händlern und Lieferanten.
Anwendungsfälle nach Branche
Fertigung & Industrie
SPS- und Sensordaten wurden über industrielle Teltonika-Gateways per MQTT an einen zentralen Broker übertragen; durch die Zusammenführung der Produktionsdaten mit MES und ERP wechselte das OEE-Reporting von einer täglichen manuellen Zusammenstellung zu einer Echtzeitansicht.
Einzelhandel / E-Commerce
Marktplätze, Onlineshop, ERP und Lagerverwaltungssystem wurden über eine ereignisgesteuerte Architektur verbunden; die Verzögerung bei der Bestandssynchronisation sank von Stunden auf Sekunden, Stornierungen aufgrund von Verkäufen ohne Lagerbestand gingen um 60 % zurück.
Finanzwesen / Banken
Verstreute interne Services wurden hinter einem API-Gateway gebündelt; für Geschäftspartner geöffnete APIs wurden mit OAuth 2.0 und Rate Limiting geschützt, und die Integrationszeit für neue Geschäftspartner sank von Wochen auf Tage.
Gesundheitswesen
Krankenhausinformationssystem, Labor- und Bildgebungssysteme wurden über eine HL7-FHIR-konforme API-Schicht integriert; Patientenergebnisse erreichen die Ärztinnen und Ärzte schneller, und sämtliche Datenzugriffe sind auditierbar.
Energie
Felddaten aus dezentralen Energieanlagen wurden per MQTT erfasst und in eine Zeitreihendatenbank übertragen; durch die Verknüpfung von Störungsalarmen mit SCADA und dem Auftragsmanagementsystem verkürzte sich die Reaktionszeit um 40 %.
Logistik
Fahrzeugortungsgeräte, APIs von Paketdienstleistern und das Auftragsmanagementsystem wurden in einer einzigen Integrationsschicht zusammengeführt; durch Echtzeit-Benachrichtigungen zum Lieferstatus an Kunden sank die Belastung des Callcenters um 35 %.
Der Indexline-Ansatz
Die meisten Integrationsprojekte geraten nicht wegen der Technologie ins Stocken, sondern wegen unklarer Verantwortlichkeiten und undokumentierter Schnittstellenverträge. Deshalb beginnt Indexline jedes Projekt nicht mit der Auswahl technischer Werkzeuge, sondern mit der gemeinsamen Erfassung der Datenflüsse und Geschäftsprozesse mit deren Verantwortlichen. Eine Integration, die aufgebaut wird, bevor geklärt ist, welches System für welche Daten als „Single Source of Truth“ gilt, welche Latenz ein Datenfluss tolerieren kann und wer im Fehlerfall informiert wird, wird beim ersten Problem fragil.
In unserer Architektur kombinieren wir den API-First- und den ereignisgesteuerten Ansatz. Für Abfragen und Transaktionsschritte, die eine sofortige Antwort erfordern, setzen wir gut konzipierte, mit OpenAPI dokumentierte APIs ein; für Szenarien, in denen sich Zustandsänderungen auf mehrere Systeme verteilen müssen, konzipieren wir Event-Streams auf Basis von MQTT oder Kafka. Statt jedes Problem mit einer einzigen Technologie lösen zu wollen, führt die Wahl des richtigen Kommunikationsmodells für jeden Datenfluss langfristig zum besten Ergebnis – sowohl bei der Performance als auch bei den Wartungskosten.
Sicherheit betrachten wir als festen Bestandteil der Integrationsschicht. Die Integrationsplattform ist eine Autobahn, über die die wertvollsten Daten des Unternehmens laufen – und damit auch ein attraktives Ziel für Angreifer. Deshalb arbeiten wir nach dem Zero-Trust-Prinzip, das jede Verbindung standardmäßig als nicht vertrauenswürdig einstuft; wir setzen mTLS zwischen Services, kurzlebige Tokens, Gerätezertifikate, Topic- und Endpoint-basierte Autorisierung sowie die Maskierung personenbezogener Daten ein. Alle Zugriffe werden protokolliert und können an eine SIEM-Infrastruktur übergeben werden.
In unserem Managed-Service-Modell endet die Verantwortung nicht mit der Inbetriebnahme. Signale wie wachsende Queues, steigende Fehlerraten, eine langsamer werdende externe API oder ein bald ablaufendes Zertifikat werden proaktiv überwacht; Probleme werden behoben, bevor die Fachbereiche sie bemerken. Versionsupdates von Broker und Gateway, Kapazitätserweiterungen und Disaster-Recovery-Übungen werden im Rahmen eines geplanten Wartungskalenders durchgeführt. In monatlichen Berichten werden Datenflussvolumen, Erfolgsquote und SLA-Einhaltung transparent dargestellt.
Jedes Unternehmen hat einen anderen Reifegrad bei der Integration. Manche möchten zunächst einige kritische Datenflüsse zuverlässig machen, andere streben direkt ein API-Ökosystem für Geschäftspartner oder eine IoT-Datenplattform mit Tausenden angebundener Geräte an. Indexline erstellt eine schrittweise Roadmap, die mit schnellen Erfolgen beginnt und in jeder Phase messbaren Mehrwert liefert – ohne das Unternehmen in eine Komplexität zu drängen, die es nicht benötigt. Ziel ist es, dass Integration kein Engpass, sondern eine Kompetenz wird, mit der sich neue Geschäftsideen schnell umsetzen lassen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen MQTT und einer REST-API, und was sollten wir einsetzen?
Eine REST-API arbeitet nach dem Request-Response-Modell: Der Client fragt Daten an, wenn er sie benötigt, und erhält eine Antwort. MQTT arbeitet dagegen nach dem Publish/Subscribe-Modell: Die datenerzeugende Seite veröffentlicht eine Nachricht in einem Topic, und der Broker leitet sie an alle interessierten Abonnenten weiter. Für Echtzeitabfragen und Transaktionsschritte eignet sich REST; für Geräte, die kontinuierlich Daten erzeugen, für Verbindungen mit geringer Bandbreite und für Szenarien, in denen ein Ereignis an viele Systeme verteilt werden muss, ist MQTT besser geeignet. In den meisten Unternehmensarchitekturen werden beide gemeinsam eingesetzt.
Was bedeuten die QoS-Stufen bei MQTT?
QoS 0 bedeutet, dass eine Nachricht höchstens einmal zugestellt und keine Bestätigung erwartet wird; dies ist die schnellste, jedoch verlusttolerante Option. QoS 1 garantiert, dass eine Nachricht mindestens einmal zugestellt wird; da es zu erneuten Zustellungen kommen kann, muss der Empfänger Duplikate tolerieren. QoS 2 stellt sicher, dass eine Nachricht genau einmal zugestellt wird; dies ist die zuverlässigste Option mit dem höchsten Overhead. Für Telemetriedaten wird in der Regel QoS 0 oder 1, für Befehle und kritische Geschäftsereignisse QoS 1 oder 2 gewählt.
Sind MQTT und Apache Kafka Alternativen zueinander?
Nicht ganz – sie ergänzen sich. MQTT ist dafür konzipiert, sehr viele Geräte und Clients über ein schlankes Protokoll anzubinden. Kafka hingegen ist eine Event-Streaming-Plattform, die hochvolumige Event-Streams persistent speichert, wiederholt abspielbar (Replay) macht und skalierbar an mehrere Consumer-Gruppen verteilt. In einer verbreiteten Architektur verbinden sich die Geräte mit dem MQTT-Broker, die Daten werden über eine MQTT-Kafka-Bridge oder einen Kafka-Connect-Konnektor an Kafka übergeben, und Analyse-, Reporting- und Geschäftsanwendungen werden über Kafka versorgt.
Lassen sich unser bestehendes ERP und unsere Altsysteme (Legacy) integrieren?
Ja. Systeme mit modernen APIs werden direkt angebunden. Für Altsysteme ohne API werden Konnektoren über Change Data Capture auf Datenbankebene (CDC, z. B. Debezium), dateibasierte Übertragung, SOAP-Services oder andere vom System unterstützte Schnittstellen entwickelt. Ziel ist es, das Altsystem sicher in die moderne Integrationsschicht einzubinden, ohne es ändern zu müssen.
Was passiert, wenn in der Integrationsschicht eine Nachricht verloren geht?
In einer gut konzipierten Integrationsplattform gehen Nachrichten nicht unbemerkt verloren. Persistente Queues, Broker-Replikation, Zustellbestätigungen (Acknowledgements) und automatische Wiederholungsmechanismen fangen temporäre Fehler ab. Nachrichten, die trotz einer festgelegten Anzahl von Versuchen nicht verarbeitet werden können, werden in eine Dead Letter Queue verschoben, und es wird ein Alarm ausgelöst. Durch idempotente Verarbeitung wird zudem verhindert, dass eine erneut gesendete Nachricht einen doppelten Datensatz erzeugt.
Wie wird die Sicherheit der Integrationsplattform gewährleistet?
Der gesamte Datenverkehr wird mit TLS verschlüsselt, zwischen Services kommt mTLS zum Einsatz. Anwendungen authentifizieren sich über OAuth 2.0 / OpenID Connect, IoT-Geräte über X.509-Zertifikate. Auf MQTT-Seite wird eine Topic-basierte, auf API-Seite eine Endpoint- und Scope-basierte Autorisierung umgesetzt. Rate Limiting und WAF verhindern Missbrauch; alle Zugriffsprotokolle werden zentral gespeichert und können an ein SIEM-System übergeben werden.
Läuft die Plattform in der Cloud oder in unserem eigenen Rechenzentrum?
Beide Modelle sind möglich. Da die Integrationskomponenten containerbasiert auf Kubernetes laufen, können sie in der Indexline-Infrastruktur, im eigenen Rechenzentrum des Unternehmens, in einer Public Cloud oder in einer hybriden Struktur betrieben werden. Wenn Daten aufgrund des KVKK oder branchenspezifischer Vorschriften im Inland verbleiben müssen, wird die Architektur entsprechend ausgelegt.
Was übernimmt Indexline im Rahmen des Managed Service?
Der Umfang wird bedarfsgerecht festgelegt, umfasst in der Regel jedoch das 24/7-Monitoring der Plattform, die Reaktion auf Incidents, Kapazitäts- und Performance-Management, Versionsupdates von Broker und Gateway, Zertifikatserneuerung, Backup- und Disaster-Recovery-Übungen, monatliches SLA-Reporting sowie die Analyse und Entwicklung neuer Integrationsanforderungen. So muss das Unternehmen kein eigenes Expertenteam für den Betrieb der Integrationsplattform aufbauen.