Spryker Oryx vs. produktionsreifes Frontend: was 2026 wirklich zähltSpryker hat mit Oryx einen eigen…
Wann ihr nicht komplett composable werden solltet
Seit einigen Wochen kursiert ein Satz durch Branchenmedien wie CX Today, Elogic und VDPL, der für die Sommerruhe ungewöhnlich viel Diskussion auslöst: Composable Commerce ist eine Business-Architektur-Entscheidung, kein Standard-Setup. Die Kernthese des Diskurses lautet, dass die meisten Unternehmen nicht vollständig composable werden sollten. Das ist kein Abgesang auf MACH-Architektur, sondern eine Reifungs-Aussage nach mehreren Jahren Composable-Hype. Der Markt wird nüchterner, und das ist gut so.
Für Retailer ergibt sich daraus eine unbequeme, aber wichtige Frage: Wenn nicht jeder komplett composable werden muss, wer dann? Und was macht ihr, wenn ihr die Vorteile wollt, ohne die volle Transformation zu stemmen?
Was der Sommer-2026-Diskurs eigentlich sagt
Der aktuelle Branchen-Diskurs ist kein Einzelfall-Take, sondern eine wiederkehrende Beobachtung mehrerer Publikationen: Composable-Architektur bringt reale Vorteile, Backend-Agnostik, Best-of-Breed-Auswahl, Skalierbarkeit über Märkte hinweg. Sie verlangt aber auch reale Voraussetzungen: dedizierte Platform-Teams, hohe Change-Frequenz, ein Backend, das API-first denkt, und Governance-Prozesse für viele Services statt für ein System. Fehlen diese Voraussetzungen, wird aus Composable Commerce ein Integrationsprojekt ohne Ende statt einer Wachstums-Architektur.
Wir teilen diese Einschätzung, mit einer Ergänzung: Die Entscheidung ist selten binär. Zwischen "alles composable" und "alles im Monolithen lassen" liegt ein dritter Weg, den der aktuelle Diskurs selten benennt, den wir aber täglich mit Kunden sehen: Frontend-First.
Wann composable wirklich gewinnt und wann nicht
Composable Commerce ist kein Ja/Nein-Feature, sondern eine Passform-Frage. Die folgende Übersicht zeigt, wann sich der volle Umbau lohnt und wann nicht:
| Kriterium | Composable gewinnt | Composable gewinnt (noch) nicht |
|---|---|---|
| Team-Größe & Rollen | Mehrere dedizierte Frontend- und Platform-Teams vorhanden | Ein bis zwei Entwickler, keine dedizierte Platform-Rolle |
| Change-Frequenz | Mehrere Releases pro Woche über viele Touchpoints | Wenige Kampagnen-Updates pro Monat |
| Backend-Reife | API-first-Backend mit stabilen Contracts | Monolith mit enger Kopplung, laufender Umbau |
| Time-to-Value-Anspruch | Architektur-Invest über 12 bis 18 Monate akzeptiert | Ergebnis in Wochen gefordert |
| Governance-Umfang | Mehrere Marken oder Märkte, komplexe Compliance | Eine Marke, ein Markt, überschaubare Compliance |
| Budget-Realität | Dedizierter Architektur-Etat vorhanden | Marketing-Budget muss Frontend-Änderungen mittragen |
Wenn eure Antworten mehrheitlich in der rechten Spalte landen, ist ein Full-Stack-Decompose aktuell das falsche Projekt, nicht das falsche Ziel. Composable bleibt eine valide Zielarchitektur, nur eben nicht der nächste Schritt.
Der Frontend-First-Shortcut
Der Teil des Composable-Stacks, der die meisten Kundenprobleme tatsächlich löst, ist selten das Backend. Es ist das Frontend: Wie schnell könnt ihr eine Landingpage live schalten, ein Kampagnen-Layout anpassen oder ein neues Markt-Setup ausrollen, ohne auf ein Entwickler-Ticket zu warten?
Genau hier setzt Frontend as a Service an: Ihr adoptiert die Frontend-Ebene, marketer-editierbar und schnell, ohne den vollständigen Backend-Umbau vorzuziehen. Das Backend bleibt, was es ist, Shopify, Shopware, ein Monolith oder ein Custom-Build, während das Frontend unabhängig davon modernisiert wird. Entsteht später tatsächlich der Bedarf für einen vollständigen Composable-Umbau, ist das Frontend bereits entkoppelt und muss nicht neu gebaut werden.
Das ist der praktische Unterschied zwischen einem Composable Headless Frontend als Einstiegspunkt und einer vollständigen MACH-Transformation als Fernziel. Beides ist composable im technischen Sinn, aber nur eines davon verlangt sofort ein eigenes Platform-Team.
Wie ihr die Entscheidung trefft
Vier Fragen reichen für eine erste Einschätzung:
- Wie oft ändert sich euer Frontend pro Monat, und wie oft blockiert ein Entwickler-Ticket diese Änderung?
- Ist euer Backend heute schon API-first, oder bräuchte ein Composable-Umbau zuerst einen Backend-Umbau?
- Habt ihr ein Team, das eine Multi-Service-Architektur dauerhaft betreiben kann, oder wäre das eine einmalige Projekt-Anstrengung?
- Braucht ihr das Ergebnis in Wochen, oder ist ein 12-Monats-Invest realistisch budgetiert?
Landen zwei oder mehr Antworten bei "noch nicht bereit", ist das kein Scheitern, sondern ein guter Grund, beim Frontend anzufangen und den Rest später zu entscheiden.
Wo Laioutr reinpasst
Laioutr ist auf den Frontend-Layer spezialisiert, nicht auf den vollständigen Composable-Stack. Wenn ihr eine komplette MACH-Suite mit PIM, OMS und Payment-Orchestrierung ersetzen wollt, ist das nicht unser Einsatzgebiet. Wenn ihr den Frontend-Layer modernisieren wollt, ohne das Backend zu wechseln, ist genau dafür Laioutr gebaut: als Frontend Management Platform, die auf jedem Backend läuft und composable-fähig bleibt, falls ihr später weitergeht.
Weiterlesen
Wer den Composable-Stack vollständig verstehen will, findet zwei vertiefende Perspektiven: warum Composable Commerce eine Frontend Management Platform braucht, um erfolgreich zu sein, und welche Fallstricke bei einer MACH-Migration typischerweise vermieden werden sollten.
Wer die eigene Entscheidung lieber im Gespräch durchgeht als in vier Fragen, findet Ansprechpartner und weitere Details auf der Laioutr-Startseite.