Unser Kunde betreibt eine Multimobilitaetsplattform, mit der Unternehmen saemtliche Mobilitaetsformen zentral verwalten koennen: Leasingfahrzeuge, Dienstraeder, OEPNV-Karten, Carsharing und Homeoffice-Zuschlaege. Die Idee ist einfach. Die technische Umsetzung ist es nicht.
Das Problem: 150 Quellen, 150 Formate
Jeder Mobilitaetsanbieter liefert Daten auf seine eigene Art und Weise. Leasinggesellschaft A sendet CSV-Dateien per E-Mail. OEPNV-Anbieter B stellt eine REST-API bereit. Fahrradlieferant C arbeitet mit SFTP-Uploads. Und alle definieren ihre eigenen Felder, Datumsformate und Statuswerte. Manchmal aendern Anbieter ihr Datenformat ohne Vorwarnung -- was bedeutet, dass jede Pipeline robust genug sein muss, um unerwartete Schemaaenderungen zu verkraften.
Manuelle Integration war keine Option. Bei 150+ Anbietern und wachsendem Volumen haette das Team mehr Zeit fuer Datenverarbeitung als fuer Produktentwicklung aufgewendet. Die Mathematik ist einfach: Wenn jede manuelle Integration zwei Wochen dauert, brauchen Sie bei 150 Anbietern fast sechs Jahre, nur um den aktuellen Stand abzuarbeiten -- und bis dahin haben sich die Anforderungen laengst geaendert.
Die Loesung: standardisierte Adapter
Wir haben ein Adapter-Framework entwickelt, das jeden Anbieter ueber eine standardisierte Schnittstelle an die Fleet-Plattform anbindet. Jeder Adapter uebersetzt anbieterspezifische Daten in ein einheitliches Format. Das Kernprinzip: Trennung von Datenerfassung und Geschaeftslogik. Die Adapter kuemmern sich nur um die Uebersetzung, die Plattform nur um die Verarbeitung.
Die Orchestrierung laeuft ueber n8n: Datenstroeme werden geplant, ausgefuehrt, validiert und bei Fehlern automatisch erneut versucht. Wir haben ein mehrstufiges Retry-System implementiert: sofortiger Retry bei Netzwerkfehlern, verzoegerter Retry bei Rate-Limiting, und Eskalation an das Operations-Team bei strukturellen Fehlern. Alle Daten werden in PostgreSQL gespeichert und stehen der Plattform in Echtzeit zur Verfuegung.
Fuer die Datenvalidierung setzen wir auf JSON Schema. Jeder Adapter definiert ein Schema, das die erwartete Datenstruktur beschreibt. Eingehende Daten werden gegen dieses Schema geprueft, bevor sie in die Datenbank geschrieben werden. So fangen wir fehlerhafte oder unvollstaendige Lieferungen ab, bevor sie Probleme verursachen.
Ergebnisse
Die Integrationszeit fuer einen neuen Anbieter sank von durchschnittlich zwei Wochen auf zwei Tage. In der Praxis bedeutet das: Ein Entwickler konfiguriert den Adapter, schreibt die Mapping-Regeln und testet gegen Beispieldaten. Alle 150+ Datenstroeme laufen autonom ohne manuelle Eingriffe. Die Plattform bedient inzwischen mehr als 45 Unternehmen mit vollstaendigen, aktuellen Mobilitaetsdaten.
Ein besonders wichtiger Aspekt: Die Fehlerrate sank auf unter 0,3%. Frueher waren Dateninkonsistenzen an der Tagesordnung -- falsche Waehrungsformate, fehlende Pflichtfelder, doppelte Eintraege. Das standardisierte Validierungssystem faengt diese Probleme jetzt automatisch ab.
Was andere Plattformen daraus lernen koennen
Skalierbarkeit beginnt mit Standardisierung. Nicht jedes Problem ist ein KI-Problem. Manchmal ist die Antwort ein gut durchdachtes Datenmodell, standardisierte Schnittstellen und zuverlaessige Orchestrierung. Die Technologie muss nicht spektakulaer sein, um spektakulaere Ergebnisse zu liefern. Was zaehlt, ist die Architektur: Wenn Sie heute 10 Anbieter haben und morgen 200 haben wollen, muss die Grundstruktur das hergeben, ohne dass Sie alles neu bauen muessen.
Der zweite Punkt: Investieren Sie in Monitoring. Wir haben fuer jeden Datenstrom Dashboards gebaut, die zeigen, wann die letzte erfolgreiche Synchronisation war, wie viele Datensaetze verarbeitet wurden und ob Anomalien auftreten. Wenn ein Anbieter sein Format aendert, wissen wir das innerhalb von Minuten -- nicht erst, wenn ein Kunde sich beschwert.
