From Composable to Adaptive
Die eigentliche Frage ist nicht Modularität – sondern Betrieb
Composable Commerce hat ein wichtiges Versprechen gemacht: schneller verändern, Komponenten austauschen, weniger Vendor-Lock-in.
In der Praxis scheitert der Business-Impact aber häufig nicht am Commerce-Core, sondern am Betrieb der neuen Architektur: mehr Services, mehr Verträge, mehr Monitoring, mehr Abhängigkeiten – und damit mehr Koordinationskosten.
Das ist kein Gegenargument gegen Composable – aber ein Hinweis, dass „Best-of-Breed“ alleine noch keine Geschwindigkeit garantiert.
Wo Composable kippt
Integration wird zur Hauptarbeit – vor allem bei Change
Mehr Freiheit bedeutet mehr Integrationslast. In vielen Programmen verschiebt sich der Aufwand von „Plattform bauen“ zu „Systeme zusammenhalten“.
- API-Spaghetti statt Plattform: Point-to-point Integrationen, die bei jeder Änderung brechen
- Daten-Inkonsistenzen: Produkt-, Preis-, Kunden- und Order-Daten laufen in unterschiedlichen Takten und Formaten
- Vendor- und Betriebs-Overhead: SLAs, Releases, Security, Observability, Incident-Prozesse über viele Komponenten
- Change wird teuer: Jede neue Funktion zieht eine Kette an Anpassungen und Tests nach sich
Die Diskussion um „Integration Chaos“ und steigende Betriebs-Komplexität ist inzwischen explizit Teil der MACH-/Composable-Debatte.
Complexity in the pipes
Wenn Integrationslogik das neue Monolithen-Problem wird – nur verteilt
Viele Organisationen unterschätzen, dass Integrationslogik irgendwo „landen“ muss. Wenn sie sich in ESB-/iPaaS-Flows, Custom-Services und Sonderfällen ansammelt, entsteht ein neues Monolithen-Problem – nur verteilt.
Aus Management-Sicht ist das relevant, weil sich Risiko und Change-Kosten nicht in einem Tool manifestieren, sondern im Verbundsystem: Ownership, Contracts, Release-Fenster, Regression und Incident-Prozesse.
Was mit „Adaptive Commerce Systems“ gemeint ist
Nicht mehr nur komponieren – sondern kontinuierlich anpassen
Adaptive Commerce ist kein neues Tool-Label, sondern eine Fähigkeit: Commerce-Systeme reagieren schneller auf Änderungen in Sortiment, Nachfrage, Bestand, Logistik, Pricing und Customer Behavior – ohne dass jeder Change ein Mini-Projekt wird.
Im Kern geht es um drei Eigenschaften:
- Situationsbewusstsein: Near-Real-Time Daten statt Batch
- Orchestrierung: klare Zuständigkeiten + stabile Contracts über Systeme
- Selbstanpassung: Konfiguration und Flows werden laufend optimiert
Der Begriff „adaptive“ ist in der Forschung älter als die heutige Commerce-Debatte – dort wird Adaptivität als Architekturprinzip beschrieben (z. B. Systeme, die sich an Kontext und Nutzerverhalten anpassen).
Warum KI jetzt eine neue Generation möglich macht
KI ist hier kein Frontend-Feature, sondern ein Betriebshebel
Die praktische Lücke von Composable war weniger die Architektur, sondern der Aufwand für Konfiguration, Integration und laufende Änderung. Genau dort kann KI helfen – nicht magisch, sondern handwerklich:
- Automatisierte System-Analyse: Doku, Tickets, API-Spezifikationen, Logs und Code-Artefakte zusammenführen und Abhängigkeiten sichtbar machen
- Konfigurations- und Mapping-Assistenten: Vorschläge für Mappings, Validierungsregeln und Transformationen – inklusive „Diff“ bei Änderungen
- Test- und Change-Automation: End-to-End Testfälle für teure Edge-Cases (Split-Shipments, Partial Refunds, Backorder, Stornos, B2B-Preisregeln)
- Schnellere Software-Iteration: kürzere Zyklen, höhere Qualität – relevant, weil Commerce-Organisationen faktisch Software-Fabriken sind
Entscheidend ist, dass KI den Change-Prozess verkürzt: verstehen → ändern → testen → ausrollen → überwachen.
Was das wirtschaftlich bedeutet
Change muss billiger und sicherer werden – sonst bleibt „Composable“ ein Architekturprojekt
Wenn Integration und Betrieb die Hauptarbeit werden, steigen die Kosten nicht linear, sondern überproportional: mehr Koordination, mehr Regression, mehr Abhängigkeiten.
Die relevante Management-Frage lautet deshalb: Wie reduzieren wir Unsicherheit und Rework bei Änderungen? Adaptive Commerce adressiert genau diesen Hebel, indem Contracts, Ownership und Automatisierung den Normalfall „Change“ absichern.
Pragmatischer Weg: von „Composable“ zu „Adaptive“
Ein Vorgehen, das Komplexität reduziert statt neu verteilt
- Definieren Sie 3–5 „Promises“, die Ihr System sicher liefern muss (z. B. Lieferdatum/ATP, Rückerstattung, B2B-Konditionen, Omnichannel-Retoure, Echtzeit-Verfügbarkeiten).
- Map „Source of Truth“ und Latenz je Promise: Wo entsteht Wahrheit (ERP, OMS, WMS, PIM)? Wie aktuell ist sie? Wo wird manuell korrigiert?
- Stabilisieren Sie die Contracts: Bevor Sie weitere Komponenten „komponieren“: API- und Event-Verträge, Monitoring, Reconciliation, Ownership.
- Setzen Sie KI dort ein, wo Unsicherheit am teuersten ist: Abhängigkeitsanalyse, Datenmapping, Testfälle, Regression – nicht in PowerPoint.
So wird aus Composable ein belastbarer Ansatz – und aus „Projektarchitektur“ eine Betriebsfähigkeit, die Änderungen verkraftet.
Weiterführende Links (kuratiert)
Quellen zur Debatte: Kosten, Integration und Betrieb
- Shopware: „Composable kann schnell sehr komplex werden … zahlreiche Technologielösungen kombinieren“
- CMSWire: Debatte um „integration chaos“, Kosten & Vendor-Overhead
- ITPro: MACH Architektur – Vorteile, aber auch Migration/Vendor-Kosten & Komplexität
- commercetools: Integration-Modelle & „Complexity in the pipes“
- McKinsey: AI-enabled Software Product Development Lifecycle
- McKinsey: Economic potential of Generative AI
- Springer (PDF): „An Adaptive e-Commerce System Definition“
