Es ist Ende Juli. Black Friday ist der 27. November 2026, Cyber Monday der 30. Das klingt nach reich…
Von DXP zu Composable Commerce: Die Architektur-Evolution, die jede Brand verstehen muss
Wie Brands Commerce-Erlebnisse bauen und ausliefern, hat einen seismischen Shift hinter sich. Was als Versprechen monolithischer Digital Experience Platforms begann, hat sich zu etwas weit Flexiblerem, Mächtigerem und letztlich besser zu modernen Businesses Passendem entwickelt. Diese Reise zu verstehen ist keine reine technische Neugier. Sie ist fundamental für solide Investitions-Entscheidungen für deine Commerce-Infrastruktur.
Bei Laioutr haben wir Hunderte von Brands durch diesen Übergang begleitet. Wir haben Companies mit den Beschränkungen von Legacy-Systemen kämpfen sehen, sie mit fragmentierten Headless-Ansätzen experimentieren beobachtet und ihnen geholfen, die Eleganz wirklich composable Architektur zu entdecken. Diese Evolution sagt uns etwas Kritisches: Es gibt keine einzelne „richtige" Antwort, nur die richtige Antwort für dein Business in deinem konkreten Moment.
Das Versprechen und die Limits von Digital Experience Platforms
Zwei Jahrzehnte lang dominierten DXPs die Commerce-Landschaft. Diese Plattformen kamen mit einer attraktiven Prämisse: eine unifizierte Suite, die alles handhabt, was ein Marketer, Merchandiser und Developer brauchen könnte. Content Management, Personalization, Analytics, Asset Management, Workflow-Tools und Publishing-Capabilities, alle in einem Ökosystem gebündelt.
Für Business-User, vor allem Marketer, fühlte sich das wie Befreiung an. Sie konnten endlich Kontrolle über ihre Digital Experiences übernehmen, ohne bei jeder kleinen Änderung auf Developer-Ressourcen zu warten. Keine Backlogs mehr. Keine Bottlenecks mehr. Das Business konnte sich im Tempo bewegen, das es brauchte.
Aber es gab einen Haken.
Hinter den Kulissen erbten Developer eine andere Art Beschränkung. Custom-Funktionalität zu bauen hieß, innerhalb der proprietären Frameworks und Sprachen zu arbeiten, die diese Plattformen vorgaben. Du willst das neueste JavaScript-Framework nutzen? Pech. Du willst einen modernen Third-Party-Service integrieren? Navigiere die Approval-Matrix. Du willst Performance mit aufkommenden Technologien optimieren? Die meisten DXP-Architekturen wurden nicht für diese Flexibilität gebaut.
Das schuf ein interessantes Paradox: Die Plattformen, die behaupteten, sowohl Business- als auch Technik-Teams zu ermächtigen, schufen tatsächlich eine neue Art Spaltung. Marketer bekamen Kontrolle, Developer verloren Autonomie. Business bewegte sich schneller, aber Innovation kam ins Stocken. Während Wettbewerbs-Druck stieg und Customer-Erwartungen sich entwickelten, fühlten sich diese Beschränkungen weniger wie Features an und mehr wie Handschellen.
Headless entstand als die Antwort der Developer
Die Headless-Bewegung entstand als direkte Reaktion auf diese Limits. Statt alles zu bündeln, trennte Headless-Architektur die Präsentations-Schicht von der Business-Logik. Eine entkoppelte Content-API und ein komplett unabhängiges Frontend bedeuteten, dass Developer endlich ihre eigenen Tools, Frameworks und Technologien wählen konnten.
Plötzlich konnten Engineers mit React, Vue, Next.js, Svelte oder welchem Framework auch immer bauen, das am besten zu ihren Projekt-Anforderungen passte. Performance-Optimierung wurde möglich. Echte Innovation konnte passieren. Brands, die Headless-Architekturen adoptierten, sahen bemerkenswerte Verbesserungen bei Site-Speed, Developer-Produktivität und ihrer Fähigkeit, moderne User Experiences auszuliefern.
Aber Headless brachte eigene Probleme.
Die Trennung, die Developer befreite, schuf Chaos für Marketer. Ohne den integrierten Experience-Builder, an den sie gewöhnt waren, fanden sich Business-User in einem Alptraum fragmentierter Tools und verstreuter Workflows gefangen. Du willst eine Kampagne über mehrere Channels veröffentlichen? Koordiniere zwischen drei verschiedenen Systemen. Du musst prüfen, wie eine Experience aussieht, bevor sie live geht? Hoffe, dass dein Developer dir beim Preview helfen kann. Jeder Routine-Task wurde zur Developer-Anfrage. Marketing-Teams sahen ihre Agilität in einem wachsenden Backlog verschwinden.
Das sollte nicht passieren. Headless sollte die Antwort sein. Stattdessen hatte es das Problem nur verschoben: Jetzt waren Developer glücklich, aber Business-User frustriert.
Composable entstand als das Ideal, aber die Umsetzung war komplex
Bis Anfang der 2020er hatte sich das Industrie-Denken weiterentwickelt. Die Antwort war nicht die Wahl zwischen DXP und Headless. Die Antwort war Composability. Bau einen Custom-Stack, der auf deine exakten Bedürfnisse zugeschnitten ist, und zieh die besten Komponenten verschiedener Vendors. Behalte, was funktioniert, ersetze, was nicht, ergänze neue Technologien, sobald sie auftauchen.
In der Theorie war das elegant. Jeder Vendor sah eine Chance und behauptete plötzlich, „composable" zu sein. Aber während wir mit Brands arbeiteten, die versuchten, diese Stacks zusammenzustellen, trafen wir auf eine hartnäckige Realität: Composable Architecture ist außergewöhnlich schwer gut umzusetzen.
Das Problem? Integration-Glue-Code.
Wenn du disparate Systeme verbindest, brauchst du Custom-Integrations-Schichten, damit sie zusammenarbeiten. Diese Verbindungen werden brüchig. Sie verlangsamen Entwicklung. Sie schaffen Abhängigkeiten, die dich davon abhalten, Komponenten ohne massives Rework zu wechseln. Manche Organisationen versuchten das zu lösen, indem sie an Agenturen mit „Accelerators" outsourcten, aber das tauschte nur Technical Debt gegen Agentur-Abhängigkeit ein.
Eine Brand hatte eine wunderschöne Vision: eine spitzen Commerce-Engine hier, eine branchenführende Content-Plattform dort, ein mächtiges Personalization-System woanders. Aber die Realität waren Schichten über Schichten Custom-Code, die das Ganze zusammenhielten, konstante Wartung erforderten und es nahezu unmöglich machten, den Stack ohne signifikante Investition weiterzuentwickeln.
Die schmerzhafte Wahrheit: Composable-Tools komponieren sich nicht selbst.
Composable-Commerce-Evolution: Vom Stack zur Orchestrierung
Was in den letzten Jahren entstanden ist, ist eine wichtige Verfeinerung darin, wie wir über Composable-Systeme denken. Der Durchbruch liegt nicht im Bauen verbundenerer Tools. Er liegt im Schaffen intelligenter Orchestrierungs-Schichten, die zwischen deinen verschiedenen Komponenten sitzen und sie nahtlos zusammenarbeiten lassen, ohne Custom-Integrations-Code für jede Verbindung zu brauchen.
Das steht für einen fundamentalen Denk-Shift. Statt zu fragen „Welche Tools sollten wir kaufen?", wird die Frage zu „Wie orchestrieren wir die Tools, die wir haben?". Es ist der Unterschied zwischen horizontalem und vertikalem Blick auf deinen Stack.
Eine echte Composable-Commerce-Lösung enthält heute mehrere kritische Schichten:
Erstens eine Integrations-Schicht, die deine bestehenden Systeme ohne Custom-Code verbindet. Ob du mit deinem Product-Information-Management-System, deiner Marketing-Automation-Plattform, deinem Content-Repository oder deiner Analytics-Engine sprichst, diese Verbindungen sollten deklarativ sein, nicht gecodet. Das System sollte diese gängigen Muster verstehen und sie ohne Developer-Overhead handhaben.
Zweitens eine Orchestrierungs-Schicht, die über deinen verschiedenen Datenquellen und Systemen sitzt und eine unifizierte Oberfläche für deine Marketing- und Merchandising-Teams liefert. Das ist es, was eine echte Composable-Plattform von einem reinen API-Aggregator unterscheidet. Business-User brauchen Sichtbarkeit und Kontrolle. Sie müssen verstehen, was sie bauen, woher Content kommt und wie Experiences für Customer erscheinen.
Drittens eine Frontend-Schicht, die Developer-Autonomie respektiert. Wenn deine Developer Next.js, Nuxt oder ein anderes modernes Framework nutzen wollen, sollten sie das können. Die Orchestrierung sollte Content und Komponenten an ihr Frontend ihrer Wahl liefern, ob das eine Single Page Application, eine Server-Side-Rendered Application oder eine Static-Site-Generated Experience ist.
Wenn diese drei Schichten richtig zusammen arbeiten, entsteht Magie. Marketer komponieren neue Experiences in Minuten statt Wochen. Developer behalten die Flexibilität, mit welchen Technologien auch immer zu innovieren. Das Business kann auf Marktveränderungen reagieren ohne teure, zeitaufwendige Migrationen. Und vielleicht am wichtigsten: Das Team kämpft nicht ständig gegen seine eigenen Technologie-Entscheidungen.
Der Business-Case für Composable Architecture
Was diese Evolution wichtig macht, ist nicht architektonische Reinheit. Es sind Business-Outcomes.
Brands, die erfolgreich zu Composable-Commerce-Architekturen gewechselt sind, berichten von dramatischen Verbesserungen bei Time-to-Market. Eine Kampagne, die drei Wochen brauchte, um konzeptioniert, entwickelt, getestet und gelauncht zu werden, passiert jetzt in Tagen. Eine neue Produktlinie kann hinzugefügt werden ohne Fragen, ob das System es bewältigen kann. Personalization und Real-Time-Optimierung werden möglich, weil du nicht auf Batch-Prozesse und Scheduled Jobs wartest.
Es gibt auch einen Resilienz-Vorteil. Mit einem monolithischen DXP, wenn du eine Komponente upgraden oder ein System komplett ersetzen musst, bist du oft zu teuren, riskanten Replatforming-Projekten gezwungen, die Monate oder Jahre dauern können. In einer Composable Architecture ist der Wechsel chirurgisch. Du kannst eine einzelne Komponente tauschen, während der Rest deines Stacks normal weiterläuft. Das reduziert Risiko und hält dein Business bei voller Geschwindigkeit.
Auch die Kostenstruktur verändert sich. Statt Enterprise-Lizenz-Fees für Capabilities zu zahlen, die du vielleicht nicht voll nutzt, erlaubt dir Composable Architecture, genau für das zu zahlen, was du brauchst. Und während sich deine Bedürfnisse entwickeln, kannst du deinen Stack anpassen ohne massive Investition.
Den Übergang erfolgreich gestalten
Wir haben gesehen, wie dieser Übergang spektakulär gelingt und leider auch, wie er scheitert. Der Unterschied liegt meist am Ansatz.
Erfolgreiche Übergänge starten nicht mit Tool-Auswahl. Sie starten mit einer klaren Einschätzung deiner Business-Anforderungen, deiner aktuellen Capability-Lücken und der Komfort deines Teams mit verschiedenen Technologien. Du musst deine aktuelle Architektur gründlich verstehen, inklusive aller versteckten Abhängigkeiten und undokumentierten Customizations, die deine Systeme am Laufen halten.
Dann nehmen erfolgreiche Implementierungen einen inkrementellen Ansatz. Du reißt nicht alles auf einmal raus und ersetzt es. Du identifizierst die Bereiche, die am meisten Reibung verursachen, die Systeme, die am dringendsten Ersatz brauchen, und du fokussierst deine initiale Implementierung dort. Du beweist, dass das Modell funktioniert, mit kleinerem Scope, bevor du es über die gesamte Operation skalierst.
Über den gesamten Prozess brauchst du Partner, die sowohl technische als auch Business-Seiten verstehen. Composable-Architecture-Entscheidungen beeinflussen deine Team-Struktur, deine Workflows, deine Vendor-Beziehungen und deine Wettbewerbspositionierung. Du brauchst Guidance von Leuten, die andere Brands genau diese Reise navigieren ließen.
Die Reife von Composable Commerce heute
Was bemerkenswert ist daran, wo der Markt 2026 steht, ist die Reife von Composable-Lösungen. Integrations-Patterns, die vor fünf Jahren Custom-Entwicklung erforderten, werden jetzt von vorgebauten Konnektoren gehandhabt. Orchestrierungs-Schichten, die theoretische Konzepte waren, sind jetzt erprobte, battle-tested Plattformen, die Commerce für Hunderte von Brands managen. Developer-Tools haben sich entwickelt, sodass es wirklich einfach ist, moderne Experiences zu bauen.
Die Technologie ist nicht mehr der Bottleneck. Die Herausforderung ist organisatorisch und strategisch. Bist du bereit, anders über deine Commerce-Infrastruktur zu denken? Kannst du von „welchen Mega-Vendor sollten wir kaufen" zu „wie orchestrieren wir Best-of-Breed-Komponenten" wechseln? Hast du die Expertise intern, oder brauchst du Partner, die dich leiten?
Die Brands, die in dieser neuen Landschaft gedeihen, verstehen etwas Fundamentales: Deine Commerce-Architektur ist ein Wettbewerbsvorteil, kein Kosten-Center. Sie bestimmt, wie schnell du auf Marktchancen reagieren kannst. Sie definiert, was deine Customer erleben. Sie formt, wie deine Teams zusammenarbeiten können.
Die Evolution von DXP zu Composable ist nicht nur eine technische Story. Sie ist eine Story über organisatorische Macht, Wettbewerbsagilität und das unermüdliche Streben nach besseren Outcomes für deine Customer und dein Business.
Wenn deine aktuelle Commerce-Architektur dein Wachstum beschränkt oder die Capabilities deines Teams limitiert, ist der Weg nach vorn klarer als je zuvor. Die Tools existieren. Die Patterns sind erprobt. Die Frage ist schlicht, ob du bereit bist, sie zu nutzen.
Weiterführende Inhalte aus der Laioutr-Plattform
Mehr dazu: Evolution statt Umsturz: Warum deine Composable-Strategie durch organisatorisches Alignment gelingt und Composable DXP 2026: Plattformen für Composable Architecture im Vergleich.