Ihre Integration laeuft jede Stunde und betet
Und hofft, dass in den 59 Minuten nichts passiert ist.
Irgendwo in Ihrer Infrastruktur läuft alle 60 Minuten ein Cron Job. Seine Aufgabe ist es, System A mit System B zu verbinden. Er zieht Daten aus dem einen, transformiert sie und schiebt sie in das andere. Er wurde von einem Entwickler geschrieben, der vor zwei Jahren gegangen ist. Er läuft auf einem Server, den seitdem niemand neu gestartet hat. Er funktioniert. Meistens.
Bei Minute 0 läuft der Sync. Er kopiert Ihr Inventory vom Warehouse-System in Ihr Sales Tool. Bei Minute 12 wird ein Gerät verkauft. Das Warehouse-System markiert es als verkauft. Das Sales Tool weiß es noch nicht — es wird es erst bei Minute 60 wissen. Bei Minute 35 sieht ein Käufer im Sales Tool das Gerät, hält es für verfügbar und startet eine Verhandlung. Bei Minute 47 macht der Käufer ein Angebot auf ein Gerät, das seit 35 Minuten verkauft ist.
Bei Minute 60 läuft der Sync erneut. Das Gerät verschwindet aus dem Sales Tool. Das Angebot des Käufers verweist jetzt auf einen Geist. Jemand muss telefonieren. Das Gespräch beginnt mit "Es tut mir leid, dieses Gerät ist nicht mehr verfügbar" und endet damit, dass der Käufer sich fragt, warum Ihr Inventory immer falsch ist.
Die 59-Minuten-Lücke
Jede Sync-basierte Integration hat eine Lücke — die Zeit zwischen einer Änderung in einem System und dem Moment, in dem das andere System davon weiß. Bei stündlichen Syncs beträgt diese Lücke bis zu 59 Minuten. Bei täglichen Syncs sind es 23 Stunden und 59 Minuten. Bei der Integration, die "normalerweise nachts läuft, aber manchmal fehlschlägt und niemand prüft, bis sich jemand beschwert", ist die Lücke existenziell.
Die Lücke ist kein Bug. Sie ist die Architektur. Sync Jobs kopieren einen Snapshot. Zwischen Snapshots verändert sich die Welt. Geräte verkaufen sich. Grades ändern sich. Orders werden versandt. Preise werden angepasst. Der Sync weiß nichts davon, bis er wieder läuft, auf die Source schaut und den aktuellen Zustand kopiert. Alles, was zwischen dem letzten Sync und diesem passiert ist, wird in ein einziges Update komprimiert. Die Granularität der Änderung geht verloren. Die Reihenfolge der Ereignisse geht verloren. Nur der Endzustand bleibt.
Ein Sync Job integriert nicht zwei Systeme. Er gibt ihnen ein gemeinsames Gedächtnis, das sich einmal pro Stunde aktualisiert, und hofft, dass diese Stunde ereignislos war.
Der Fehler, den Sie nicht sehen
Wenn ein Sync Job erfolgreich ist, bemerkt es niemand. Wenn er fehlschlägt, bemerkt es manchmal ebenfalls niemand. Der Job läuft, trifft auf ein Timeout, schreibt einen Fehler in eine Datei, die niemand überwacht, und die beiden Systeme driften leise auseinander. Inventory in System A sagt 47 Geräte. Inventory in System B sagt 52. Der Unterschied: fünf Geräte, die während des Sync-Fehlers verarbeitet wurden. Bis es jemand bemerkt — meist weil ein Käufer nach einem Gerät fragt, das in einem System existiert und im anderen nicht — sind die Daten weit genug auseinander, dass Reconciliation manuelle Arbeit erfordert.
Manuelle Reconciliation auseinander gelaufener Systeme ist eine dieser Aufgaben, die alle furchtbar finden und deren Kosten niemand misst. Sie dauert eine Stunde. Oder drei. Oder einen ganzen Tag, je nachdem, wie lange der Sync kaputt war und wie viele Änderungen aufgelaufen sind. Sie ist immer dringend, weil jemand auf die Daten wartet. Sie ist immer frustrierend, weil sie keine "echte" Arbeit ist — sie ist Arbeit, die durch Infrastruktur entsteht, die nicht funktioniert hat.
Die Alternative
Die Alternative zu Sync-basierter Integration ist eventbasierte Integration: Wenn sich etwas ändert, wird die Änderung sofort kommuniziert. Ein Gerät verkauft sich — jedes verbundene System weiß es innerhalb von Sekunden. Ein Grade ändert sich — das Listing zeigt es sofort. Eine Order wird versandt — das Kundenportal zeigt die Trackingnummer, bevor der Warehouse-Operator den Scanner abgelegt hat.
Das ist keine Wunschvorstellung. Das passiert, wenn Ihre Systeme eine Datenbank teilen, statt Daten zwischen Datenbanken zu kopieren. Wenn Warehouse, Sales Tool, Kundenportal und Settlement Engine alle aus derselben Source of Truth lesen und in sie schreiben, gibt es keine Sync-Lücke, weil nichts zu synchronisieren ist. Die Daten sind schon da. Sie sind immer aktuell. Niemand muss beten.
Ihre Integration läuft jede Stunde. In dieser Stunde verändert sich Ihr Warehouse. Ihr Inventory verändert sich. Ihre Sales Pipeline verändert sich. Und Ihre Integration ignoriert all das pflichtbewusst, bis die Uhr sagt, dass es Zeit ist hinzusehen. Der Cron Job ist keine Lösung. Er ist ein Bewältigungsmechanismus für Systeme, die von Anfang an ein System hätten sein sollen.