Composable Commerce bleibt aus guten Gründen attraktiv: mehr Beweglichkeit, weniger Lock-in, bessere Spezialisierung von PIM, CMS, Search, Checkout, OMS oder CRM.

In der Praxis zeigt sich jedoch ein anderes Muster. Viele Programme scheitern nicht an einzelnen Tools, sondern an den Übergängen zwischen ihnen. APIs, Events und Webhooks schaffen zwar Konnektivität, aber noch keine belastbare Betriebsarchitektur.

Aus Management-Sicht ist daher nicht die Frage entscheidend, ob ein Stack best of breed ist. Relevant ist, ob die Abhängigkeiten, Verantwortlichkeiten und Fallbacks zwischen den Systemen sauber definiert wurden.

Der Markt hat sich deutlich verschoben. Die Diskussion lautet heute weniger Sollten wir MACH einführen?, sondern eher Wie viel Composability brauchen wir wirklich, an welcher Stelle und unter welcher Governance?

Parallel steigt der Druck durch AI im Ecommerce. Agenten, Automatisierung und datengetriebene Prozesse funktionieren nur dann verlässlich, wenn Systeme konsistent zusammenarbeiten. Fragmentierte Landschaften bremsen damit nicht nur Customer Journeys, sondern auch Automatisierung und operative Skalierung.

Diese Entwicklung macht Integration zu einer strategischen Fähigkeit. Nicht als Nebenprojekt, sondern als Voraussetzung für Wachstum, Stabilität und AI-Readiness.

Viele Integrationsprojekte starten auf der Ebene von Feldmapping, Schnittstellen und Connectoren. Das ist notwendig, reicht aber nicht aus. Die eigentliche Frage ist nicht, ob Systeme Daten austauschen können, sondern ob sie dieselbe fachliche Bedeutung teilen.

Was ist in welchem System ein Produkt? Was ist ein verkaufbarer SKU? Wann gilt eine Bestellung als bestätigt, reserviert oder erfüllbar? Welche Bestandszahl ist für Checkout relevant: physischer Bestand, verfügbarer Bestand oder reservierbarer Bestand?

Wenn diese Begriffe nicht vorab geklärt sind, entsteht ein typisches Muster moderner Commerce-Architekturen: technisch verbunden, aber geschäftlich fehleranfällig.

Die Versprechen von Composable Commerce sind nachvollziehbar. Die operative Realität ist jedoch oft härter als erwartet. Release-Zyklen unterschiedlicher Anbieter, API-Änderungen, Schema Drift, Monitoring-Aufwand und ungeklärte Zuständigkeiten summieren sich über die Zeit.

Viele Unternehmen erleben deshalb keine Reduktion von Komplexität, sondern deren Verlagerung. Statt einer großen Plattform entstehen viele kleinere Abhängigkeiten, die koordiniert, getestet und abgesichert werden müssen.

Die Folge ist häufig kein technisches Scheitern, sondern ein organisatorisches. Modularisierte Software ohne modularisierte Betriebsdisziplin erzeugt Reibung statt Geschwindigkeit.

Gerade im ipaas retail Umfeld zeigt sich, wie schnell Integrationen falsch priorisiert werden. Ein Shop muss mit Payment und OMS anders gekoppelt werden als mit CRM oder Marketing-Systemen.

Wenn Payment erfolgreich autorisiert wurde, aber die OMS-Anlage fehlschlägt, braucht es definierte Kompensations- und Reconciliation-Prozesse. Wenn das CRM nicht erreichbar ist, darf Checkout trotzdem nicht stehen. Wenn PIM-Daten verzögert eintreffen, sollte ein letzter valider Stand den Verkauf weiterhin ermöglichen.

Die Architekturfrage lautet deshalb: Welche Flows sind umsatzkritisch, welche operativ wichtig und welche nur unterstützend? Diese Entscheidung bindet Sie langfristig.

iPaaS adressiert ein reales Problem: Punkt-zu-Punkt-Integrationen skalieren schlecht. Mit jeder zusätzlichen Anwendung steigen Wartungsaufwand, Fehleranfälligkeit und Intransparenz. Eine zentrale Integrationsschicht verspricht hier mehr Ordnung.

Gut eingesetzt standardisiert iPaaS Konnektivität, Orchestrierung, Monitoring, Retry-Mechanismen und Governance. Das ist besonders im Retail sinnvoll, wenn Shop, ERP, PIM, OMS, Fulfillment und CRM parallel zusammenspielen müssen.

Wichtig ist aber die Einordnung: iPaaS ersetzt keine Architektur. Es verbessert die Ausführung, aber nicht automatisch die Qualität der fachlichen Entscheidungen dahinter.

Ein häufiger Irrtum lautet: Wenn ein iPaaS vorhanden ist, ist Integration beherrschbar. In Wirklichkeit kann auch eine moderne Plattform nur das sauber ausführen, was fachlich und architektonisch klar entschieden wurde.

Ein iPaaS löst keine unklaren Zuständigkeiten, keine schlechten Semantiken und keine falsch platzierten Abhängigkeiten. Es entscheidet nicht, welches System führend ist, welche Daten in Echtzeit nötig sind oder welche Services den Checkout niemals blockieren dürfen.

Aus Entscheider-Sicht sollte die Auswahl deshalb nicht nur auf Connectoren basieren. Relevanter sind Observability, asynchrone Muster, Versionierung, Dead-Letter-Handling, Governance und die Isolation kritischer Flows.

Die aktuelle AI-Welle verändert die Rolle der Integrationsschicht. Moderne Plattformen positionieren sich nicht mehr nur als Middleware, sondern als Orchestrierungsebene für Workflows, Regeln, Agenten und menschliche Freigaben.

AI kann heute bereits bei Feldmapping, Drift-Erkennung, Routing-Empfehlungen, Incident-Triage und Support-Prozessen helfen. Das reduziert manuellen Aufwand und verbessert die Reaktionsfähigkeit im Betrieb.

Aber auch hier gilt: AI ersetzt keine Architektur. Sie entscheidet nicht über Source of Truth, macht schwache Transaktionslogik nicht sicher und beseitigt keine operativen Zielkonflikte. Schlechte Prozesse werden durch AI eher sichtbarer als besser.

Der Glue Framework verschiebt den Blick von Connectoren auf Entscheidungsdisziplin. Ziel ist, Integrationen nicht als technische Verkabelung zu behandeln, sondern als gesteuerte Architektur über mehrere Ebenen hinweg.

Im Kern beantwortet der Framework sechs Fragen: Wie sprechen Systeme miteinander? Wann und in welchem Muster tauschen sie Daten aus? Was bedeuten diese Daten fachlich? Wo liegt die Integration im kritischen Architekturpfad? Was passiert bei Fehlern? Und wer trägt die operative Verantwortung?

Diese Struktur macht Risiken vor dem Go-live sichtbar. Sie reduziert Überengineering, weil nicht jeder Flow gleich behandelt werden muss, und sie schafft eine gemeinsame Sprache für Business und Technik.

• Connectivity: API, Event, Webhook, Datei, Adapter, Authentifizierung, Push oder Polling
• Interaction: Echtzeit oder Batch, synchron oder asynchron, Reihenfolge, Timeouts, Idempotenz
• Semantics: Bedeutung von Produkt, Kunde, Auftrag, Bestand und Ownership der Daten
• Tiering: Trennung zwischen umsatzkritischen, operativen und unterstützenden Integrationen
• Resilience: Retry, Queue, Caching, Dead Letter, Fail-open oder Fail-closed, Reconciliation
• Operating Model: SLA, Monitoring, Alerting, Release-Disziplin, Support-Ownership und Eskalation

Diese sechs Ebenen helfen besonders dort, wo Composable Commerce schnell eingeführt wurde, aber der Betrieb noch zu stark von implizitem Wissen abhängt.

Für viele Unternehmen ist nicht maximale Modularität das Ziel, sondern ein beherrschbarer und entwicklungsfähiger Commerce-Stack. Das spricht für pragmatische Composability statt architektonischer Reinheitslehre.

Der transaktionale Kernpfad sollte so dünn und robust wie möglich bleiben. Payment, Checkout und OMS-nahe Prozesse brauchen andere Standards als CRM-Enrichment, Analytics oder Marketing-Automation. Unterstützende Flows gehören aus dem Hot Path herausgelöst.

iPaaS ist dabei sinnvoll als Orchestrierungs- und Governance-Ebene. AI im Ecommerce sollte Setup, Monitoring und Betrieb beschleunigen, aber nur innerhalb klarer Leitplanken. Die eigentliche Frage ist nicht, wie viele Tools integriert werden können, sondern wie gut das Zusammenspiel geführt wird.