Der teuerste Satz in Integrationsprojekten ist ein kurzer: „Und alles soll bitte in Echtzeit."
Wir hören ihn in fast jedem Erstgespräch über die Anbindung eines ERP oder CRM an Individualsoftware. Er klingt nach Gründlichkeit. Tatsächlich ist er ein Preismultiplikator, denn „alles in Echtzeit" bedeutet: Jeder Bildschirm Ihrer neuen Anwendung hängt synchron von einem System ab, das nie dafür gebaut wurde, so viele Fragen zu beantworten. Wenn das ERP langsam wird, wird Ihr Produkt langsam. Wenn der Hersteller es an einem Sonntag offline nimmt, geht Ihr Produkt mit offline. Wir betreiben Systemintegration für den deutschen Mittelstand und darüber hinaus, mit internationaler Projektleitung und einem Senior-Engineering-Team in Pakistan — und das Erste, was wir im Scoping tun, ist, diesen Satz Feld für Feld auseinanderzunehmen. Das meiste überlebt als „frisch genug". Sehr wenig davon ist wirklich Echtzeit.
Was Echtzeit wirklich kostet
Eine Live-Abfrage gegen das ERP sieht in der Demo einfach aus und wächst sich im Produktivbetrieb aus. Die Verfügbarkeit Ihrer Anwendung wird zum Minimum aus zwei Systemen. Die Wartungsfenster des Herstellers werden zu Ihren Wartungsfenstern. Rate Limits und volumenbasierte Preise variieren je nach ERP — wir wurden von beiden schon gebissen —, sodass ein guter Monat in Ihrem Produkt als Position auf einer Herstellerrechnung landen kann; die Limits des gewählten ERP gehören zu den ersten Dingen, die wir im Scoping prüfen. Und jeder Testlauf braucht das andere System wach und kooperativ, was das Team, das Ihr Produkt baut, noch lange nach Auslieferung der Integration ausbremst.
Nichts davon steht in dem Angebot, das „Echtzeit" verkauft hat. Es taucht im vierten Monat auf, wenn das Projekt, das Wochen dauern sollte, immer noch läuft, und die Begründung ist immer dieselbe: das andere System. Wir wurden schon geholt, um Integrationen fertigzustellen, die so begonnen haben — und die Rettung sieht meist auch gleich aus. Die synchrone Kopplung kappen, die zwei oder drei Flows behalten, die sie wirklich brauchen, den Rest als Kopien neu bauen.
Das Muster, von dem wir ausgehen: das Read-Model
Unsere Standardarchitektur ist ein Read-Model. Ihre Anwendung hält eine eigene Kopie der Daten, die sie anzeigt — geformt für ihre eigenen Bildschirme, aktualisiert aus dem führenden System nach Zeitplan oder per Events. Das ERP bleibt die Single Source of Truth für Schreibzugriffe. Ihre App liest aus ihrem eigenen Speicher: Sie kann aus der lokalen Kopie antworten, ohne auf das ERP zu warten, sie übersteht einen ERP-Ausfall, und sie kann Daten zusammenführen, die das ERP getrennt hält — etwa Kunde, offene Bestellungen und Zahlungsstatus auf einem Bildschirm —, ohne bei jedem Seitenaufruf die API des Herstellers zu hämmern.
Martin Fowlers Artikel zu CQRS bringt den zugrunde liegenden Punkt gut auf den Punkt: Das Modell, mit dem Sie lesen, muss nicht das Modell sein, mit dem Sie schreiben. In der Integrationsarbeit amortisiert sich diese Idee am schnellsten.
Der Nachteil, offen ausgesprochen: veraltete Daten plus eine Pipeline, die Ihnen jetzt gehört. Die Veraltung ist beherrschbar — Sie entscheiden pro Feld, wie alt die Daten sein dürfen, und zeigen diese Entscheidung dort in der Oberfläche, wo sie zählt. Die Pipeline sind die echten Kosten. Jemand muss den Sync besitzen, ihn beim Scheitern beobachten und ihn reparieren, wenn sich das ERP darunter verändert. Budgetieren Sie diese Verantwortung ab Tag eins, sonst verrottet das Read-Model still vor sich hin.
Wo Events sich ihren Platz verdienen
Event-getriebene Synchronisation ist genau dort das richtige Werkzeug, wo eine Änderung in einem System eine Aktion in einem anderen auslösen muss. Eine im ERP als bezahlt markierte Rechnung löst das Provisioning in Ihrem Produkt aus. Ein im CRM freigegebener Auftrag löst die Auslieferung aus. Das sind Flows, keine Anzeigen — und sie verdienen Events: Webhooks oder eine Message Queue, idempotent konsumiert und im Fehlerfall wiederholt.
Der Fehler, den wir sehen: Diese Maschinerie wird auf Daten angewendet, die nur gelesen werden. Event-Infrastruktur für eine Preisliste, die sich zweimal im Monat ändert, ist ein Cronjob im Kostüm.
Wann ein nächtlicher Batch wirklich reicht
Batch hat einen schlechten Ruf bei Leuten, die noch nie Echtzeit-Plumbing betreiben mussten. Hier ist der ehrliche Test: Was verliert das Unternehmen, wenn diese Zahl vier Stunden alt ist? Bei Produktkatalogen, Preislisten, Reporting-Aggregaten und dem Export, den Ihr Steuerberater zum Monatsende abholt, lautet die Antwort: nichts — und ein nächtlicher Export mit Diff und Abgleichsbericht ist langweilig und korrekt. Bei Lagerbestand, der einem Kunden an der Kasse zugesagt wird, lautet die Antwort: Geld — und Batch ist falsch.
Rechnen Sie das pro Feld durch, schriftlich, im Scoping. Es ist die mit Abstand günstigste Stunde des gesamten Projekts — und der Unterschied zwischen einer Integration, die in einem Quartal ausliefert, und einer, die ein Jahr braucht.
Die deutschen Besonderheiten: DATEV, XRechnung und die Frage, wo die Daten liegen
Drei Dinge tauchen in fast jeder Integration auf, die wir für einen deutschen Kunden kalkulieren — und sie verändern das Design.
Zuerst DATEV. Wenn Ihre Individualsoftware Rechnungen verschickt, will Ihr Steuerberater die Buchungsdaten zum Monatsende im DATEV-Format — das ist meist die erste Integration, die die Buchhaltungsseite einfordert. Es ist ein Dateiexport mit strikter Spezifikation, was Batch hier zum buchstäblich korrekten Muster macht. Teams, die das als Live-Sync überbauen, haben echtes Geld dafür ausgegeben, den monatlichen Import eines Steuerberaters komplizierter zu machen.
Zweitens XRechnung. Seit 2025 müssen deutsche Unternehmen B2B-E-Rechnungen empfangen können; die Pflicht zum Versand wird bis 2028 stufenweise eingeführt, so die Koordinierungsstelle für IT-Standards. Wenn Ihr ERP oder Ihre Fakturierungssoftware deutsches B2B berührt, sind Empfang und Verarbeitung von E-Rechnungen eine Integrationsanforderung mit gesetzlicher Frist, kein Backlog-Item. Dieselbe Stelle pflegt auch die XRechnung-Spezifikation selbst. Wir behandeln das inzwischen bei jedem fakturierungsnahen Umfang als Grundausstattung.
Drittens Datenresidenz. Nach DSGVO werden Ihre Rechtsberatung und Ihre Kunden dieselben Fragen stellen: Wo liegt Ihr Read-Model physisch, und wer hat Zugriff auf die Sync-Pipeline? Wir betreiben diese Workloads standardmäßig in EU-Regionen und beschränken die synchronisierte Kopie auf die Felder, die die Anwendung tatsächlich anzeigt. Den kompletten Kundendatensatz in eine zweite Datenbank zu kopieren, weil das einfacher war als Spalten auszuwählen, ist ein Datenschutzproblem, das Sie sich selbst gebaut haben.
Zum Leistungsvermögen: Das Fakturierungsprodukt aus unserer QuickBilling-Fallstudie hat seine REST-API, Webhooks für über 30 Event-Typen, eine Sandbox-Umgebung und Idempotency Keys ausgeliefert, bevor die Oberfläche fertig war — ein Abrechnungsprodukt existiert, um in den Buchhaltungs-Workflows anderer zu stecken. So sieht „built for integration" in der Praxis aus, und es ist der Standard, nach dem wir auch bauen, wenn wir auf der anderen Seite der Leitung stehen.
Tests entscheiden, ob Integrationsprojekte leben oder sterben
Integrationscode ist einfach. Vertrauen in die Integration ist das eigentliche Lieferergebnis — und es entsteht aus drei Gewohnheiten, die wir in jedem Projekt anwenden.
Sandbox zuerst, aber mit offenen Augen. Jede Entwicklung beginnt gegen die Sandbox des Herstellers, nicht gegen Produktion. Rechnen Sie damit, dass Sandboxes lügen: Sie laufen mit älteren Daten, lockereren Rate Limits und ohne die seltsamen Datensätze, die fünfzehn Jahre echtes Geschäft produziert haben. In der Sandbox lernen Sie die API. Ob die Integration funktioniert, lernen Sie dort nicht.
Idempotenz überall. Viele Anbieter, Stripe darunter, dokumentieren At-least-once-Zustellung von Webhooks — Ihr Consumer wird dasselbe Event zweimal empfangen und muss mit den Schultern zucken können; prüfen Sie die Doku jedes Anbieters, bevor Sie etwas anderes annehmen. Stripes Dokumentation zu idempotenten Requests ist die klarste öffentliche Beschreibung dieser Disziplin, und wir messen unsere eigenen Webhooks daran: Dedupe-Keys beim Empfang, Unique Constraints in der Datenbank und ein Test, der dasselbe Event wiederholt feuert und prüft, dass es genau einmal verarbeitet wird.
Replay als First-Class-Feature. Jedes Event und jeder Batch-Lauf wird protokolliert, damit Sie ihn erneut ausführen können. An dem Tag, an dem der ERP-Hersteller ein Feld umbenennt, ohne es jemandem zu sagen, ist Replay der Unterschied zwischen einem Nachmittag Neuverarbeitung und einer Woche manuellen Abgleichs. Teams, die das Log weglassen, lernen zum schlechtestmöglichen Zeitpunkt, wofür es existierte.
Wie die ersten zwei Wochen aussehen
Wenn wir eine Integration kalkulieren, entsteht in den ersten zwei Wochen kein Integrationscode. Entstehen tun ein Feldinventar für jeden Bildschirm, den die neue Anwendung braucht, ein Frische-Budget pro Feld und eine Fehlerfallen-Karte: Was passiert, wenn ein System ausfällt oder Ihnen Müll liefert. Daraus ergibt sich die Architektur fast von selbst — Read-Model für die Anzeigen, Events für die Handvoll Flows, die Aktionen auslösen, Batch für den Steuerberater und den Katalog.
Zeigt das Scoping, dass das ERP selbst das Problem ist, ist das eine andere Entscheidung — unser Leitfaden zu Neuaufbau, Refactoring oder Wrapper beschreibt, wie wir sie treffen. Lautet das Urteil, dass Ihr alterndes System größtenteils funktioniert und eine moderne Oberfläche braucht, ist das genau der Zweck unserer Software-Modernisierungsprojekte. Und wenn Sie eine Integration haben, die seit sechs Monaten „fast fertig" ist, schicken Sie uns die Feldliste. Wir sagen Ihnen, welche zwei Felder wirklich Echtzeit brauchen. Es sind selten mehr als zwei.
Häufige Fragen
Brauchen wir wirklich Echtzeit-Sync zwischen unserem ERP und unserem Kundenportal?
Fast nie — und diese Frage kommt in fast jedem ersten Gespräch, das wir führen. Was Sie meist brauchen, ist Frische, die Sie in Zahlen ausdrücken können, mit den Planungswerten, die wir im Scoping festhalten: Bestand minutengenau, Preise tagesgenau, Rechnungsstatus stundengenau. Hinter jedem dieser Werte steht ein günstiges Muster. Echtzeit heißt: Ihr Portal fällt aus, wann immer das ERP ausfällt — diese Kopplung ist das, was Sie tatsächlich kaufen.
Wie lange dauert eine ERP- oder CRM-Integration?
Als Planungsannahme aus unseren Projekten: Ein Read-Model plus ein Event-Flow gegen eine dokumentierte API läuft sechs bis zehn Wochen, inklusive Tests. Kommt ein zweites System oder eine undokumentierte Legacy-Schnittstelle dazu, wächst es von dort aus. Der Zeitplan wird weniger von unserem Code bestimmt als von der Qualität der Hersteller-Sandbox und davon, wie schnell die ERP-Seite Fragen beantwortet — deshalb kalkulieren wir zuerst die Discovery.
Sollten wir das ERP modernisieren, bevor wir es mit neuer Software integrieren?
In der Regel nein. Hüllen Sie es hinter eine saubere API, integrieren Sie dagegen und lassen Sie das System weiter Geld verdienen. Die Entscheidung Neuaufbau versus Modernisierung ist eine eigene Frage mit eigenen Kriterien — wir haben einen separaten Entscheidungsleitfaden dafür geschrieben. Unsere Faustregel für die Planung: Ein Modernisierungsprogramm zu starten, weil man eine Integration braucht, ist der Weg, auf dem aus einem Zehn-Wochen-Job ein Zweijahresprojekt wird.
Können Sie unsere Fakturierung für unseren Steuerberater an DATEV anbinden?
Ja. Der DATEV-Export für den Steuerberater ist eine der häufigsten Integrationsanfragen, die wir von deutschen Kunden bekommen — eine Batch-Datei mit striktem Format, was sie zu einem guten ersten Liefergegenstand macht. Wir übernehmen auch den XRechnung-Empfang und die umliegenden E-Rechnungs-Pflichten und können beides innerhalb eines normalen Integrationsprojekts kalkulieren.
