Composable Unternehmensarchitektur: wie integrierst du ERP, CRM und Datenplattformen, ohne neue technische Schulden zu schaffen

Beginnen Sie mit einem expliziten Integrationsmodell und erlauben Sie keine Varianten

Technische Schulden entstehen weniger durch einen Fehler, sondern vor allem durch Variation. Das eine Team baut Echtzeit-APIs, das andere arbeitet mit Batch-Exports, ein drittes führt Event-Streaming ein, und ein viertes nutzt File-Drops, weil es einmal so begonnen hat. Die Landschaft wird zu einer Mischung von Mustern, die alle verwaltet werden müssen, mit jeweils eigenen Fehlerarten.

Wählen Sie daher ein begrenztes Integrationsmodell und legen Sie genau fest, wann welches Muster erlaubt ist. Verwenden Sie APIs für Befehls- und Abfrageinteraktionen, die eine direkte Antwort erfordern. Verwenden Sie Events für asynchrone Prozesse und die Verteilung von Zustandsänderungen. Verwenden Sie Batch nur dort, wo es nachweislich nötig ist und ausdrücklich innerhalb der Anforderungen zur Datenaktualisierung passt. Wenn Sie das nicht durchsetzen, schafft jede neue Integration eine neue Ausnahme.

Integrieren Sie über Verträge, nicht über Datenmodelle

ERP und CRM haben interne Datenmodelle, die historisch gewachsen sind. Wenn nachgelagerte Systeme direkt an diese Modelle angeschlossen werden, machen Sie Ihre Architektur abhängig von internen Strukturen, die unweigerlich verändern. Contract-First-Integration löst das Problem. Sie definieren Schnittstellen und Events als explizite Verträge mit eigener Semantik, Versionsverwaltung und Lebenszyklus.

Die Regel ist einfach. Nachgelagerte Systeme dürfen niemals von Tabellen, Feldern oder technischen Objekten aus ERP oder CRM abhängig sein. Sie dürfen nur von stabilen Verträgen abhängen, die das Geschäftskonzept beschreiben, wie z.B. Kunde erstellt, Bestellung bestätigt, Rechnung gebucht, Produkt aktualisiert. Damit kann das Kernsystem intern evolvieren, ohne dass die Kette bricht.

Bestimmen Sie für jedes Daten-Domain, wo die Wahrheit liegt und machen Sie das nicht verhandelbar

Neue technische Schulden entstehen nahezu immer rund um Daten. Nicht rund um Transport, sondern rund um Unklarheiten über Stammdaten, Eigentum und Synchronisation. Wenn mehrere Systeme dieselbe Entität verwalten, bekommen Sie Rekoncilierungen, Ausnahme-Logik und Diskussionen darüber, welche Quelle stimmt.

Treffen Sie für jede Entität explizite Entscheidungen. Wo ist die Quelle der Wahrheit für Kunden, Produkte, Preise, Verträge, Rechnungen, Mitarbeiter und Assets? Legen Sie fest, welche Systeme schreiben dürfen und welche nur lesen dürfen. Stellen Sie sicher, dass der Schreibzugriff eingeschränkt ist und dass die Synchronisation kein Kompromiss für politische Bequemlichkeit wird. Wenn dies nicht hart umgesetzt wird, wird die Integration früher oder später in das Konfliktmanagement verschoben.

Entkoppeln Sie Prozesse mit Events statt mit direkten Abhängigkeiten

Viele Integrationen sind heimlich Prozessketten. Eine Aktion in CRM löst direkt ein Update in ERP aus, das wiederum ein Update in der Datenplattform auslöst und schließlich eine Benachrichtigung an ein drittes System sendet. Wenn dies über synchrone Aufrufe geschieht, werden Systeme zu Verfügbarkeits- und Leistungsgrenzen des jeweils anderen. Dann gibt es Wiederholungen, Timeouts, teilweise Updates und schwer reproduzierbare Vorfälle.

Event-getriebene Integration trennt diese Ketten. Ein Kernsystem veröffentlicht ein Event, wenn sich der Geschäftsstatus ändert. Andere Systeme reagieren darauf, ohne dass das Kernsystem weiß, wer zuhört. Dies ist das Herz der komposierbaren Architektur. Sie ermöglichen Erweiterungen, ohne bestehende Verbindungen zu ändern.

Die Konsequenz ist ebenfalls klar. Events müssen semantisch und nicht technisch sein. Veröffentlichen Sie keine Datenbankänderungen. Veröffentlichen Sie Geschäftsänderungen.

Verwenden Sie eine Integrationsschicht, die Governance durchsetzt, nicht nur den Transport

Viele Organisationen haben API-Management oder iPaaS, behandeln es jedoch als Durchgangsstation. Dann verändert sich wenig. Die Integrationsschicht muss Governance durchsetzen. Denken Sie an zentrale Authentifizierung und Autorisierung, Drosselung, Schema-Validierung, Versionsverwaltung, Audit-Logging und standardisierte Fehlerbehandlung.

Ohne diese zentrale Durchsetzung wird jede Integration zu einer eigenen Miniplattform mit eigenen Sicherheitsentscheidungen, eigenem Wiederholungsverhalten und eigenem Logging. Das ist technische Schuld im Design.

Machen Sie Versionsverwaltung und Rückwärtskompatibilität verbindlich

Die meisten Schulden entstehen bei Veränderungen. Nicht bei der ersten Implementierung. Sobald ein ERP-Update ein Feld ändert oder ein CRM-Workflow angepasst wird, brechen nachgelagerte Systeme oder Teams bauen schnelle Lösungen.

Machen Sie Schnittstellen-Versionierung und Rückwärtskompatibilität zu einer strengen Anforderung. Brechende Änderungen dürfen nur über eine kontrollierte Migration mit parallelen Versionen und klaren Abkündigungsfristen erfolgen. Veröffentlichen Sie nicht einfach neue Payloads. Führen Sie neue Felder auf rückwärtskompatible Weise ein. Machen Sie den Empfänger verantwortlich für die Annahme innerhalb eines vereinbarten Zeitrahmens. Ohne dieses Disziplin-Element verwandelt sich jede Änderungsanfrage in ein Kettenrisiko.

Setzen Sie Observability auf Integrationsströmen höher als Monitoring auf Systemen

Sie können ein perfektes Monitoring auf ERP und CRM haben und dennoch keine Ahnung haben, warum Bestellungen nicht ankommen oder warum Kundendaten inkonsistent sind. In einer komposierbaren Landschaft ist der Integrationsstrom die kritische Einheit, nicht das individuelle System.

Implementieren Sie End-to-End-Traceability über API-Aufrufe, Eventflows und Batch-Pipelines. Machen Sie sichtbar, wo Latenz entsteht, wo Wiederholungen ansteigen, wo Dead Letters wachsen und wo Datenqualitätsprüfungen fehlschlagen. Ohne diese Sichtbarkeit wird Troubleshooting zu einem menschlichen Netzwerkproblem und die Abhängigkeit von bestimmten Experten wächst.

Behandeln Sie die Datenplattform wie ein Produkt mit Verträgen, nicht wie einen Datenfriedhof

Datenplattformen sind oft der Punkt, an dem sich technische Schulden konzentrieren. Teams werfen Daten ab, weil es praktisch ist, bauen eigene Modelle und erstellen eigene Definitionen derselben KPIs. Dann entsteht eine zweite Wahrheit neben ERP und CRM.

Machen Sie Datenverträge verbindlich zwischen Quelle und Datenplattform. Legen Sie fest, was geliefert wird, wie oft, mit welchen Qualitätsanforderungen und was die Semantik ist. Stellen Sie sicher, dass Herkunft nachvollziehbar ist und dass das Daten-Eigentum beim Domain-Explicit bleibt. Die Datenplattform muss den Verbrauch ermöglichen, nicht Bedeutung erfinden.

Verhindern Sie, dass komposable Architektur eine Ausrede für neue Tool-Sprawl wird

Composable bedeutet nicht, dass jedes Team neue Services und Tools einführen darf. Das führt zu Plattform-Sprawl und erneut zu technischen Schulden, nur jetzt verteilt auf Mikroservices und Integrationswerkzeuge.

Begrenzen Sie die Anzahl der Standardbausteine. Eine API-Management-Schicht. Eine Event-Plattform. Eine iPaaS, wo nötig. Ein Standard für Datenverträge. Je weniger Variation, desto weniger Schulden.