Headless Frontend für Spryker: Wann ein FMP vor dem Enterprise-Backend die richtige Entscheidung ist…
Composable-Go-live ist nicht die Ziellinie: die Operating-Model-Lücke
Composable-Go-live ist nicht die Ziellinie: die Operating-Model-Lücke, die Mid-Market-Teams ausbremst
Der Composable-Frontend-Stack geht live, das Projektteam feiert, und am nächsten Morgen fragt niemand mehr, wer den Stack eigentlich betreibt. Genau hier sitzt die Lücke: Der Projektplan endet am Go-live, das Betriebsmodell wird nie geschrieben. Wer nach dem Launch Inhalte, Komponenten und Infrastruktur ownt, entscheidet darüber, ob aus dem neuen Frontend Tempo wird oder ein zweiter Stau.
Dieser Beitrag ist kein Migrations-Blueprint und kein Readiness-Check. Er handelt vom Tag danach: von der Frage, wer die Composable-Storefront im laufenden Betrieb steuert, und warum diese Frage im Projekt fast immer unbeantwortet bleibt.
Warum Go-live die falsche Ziellinie ist
Ein Projekt hat ein Enddatum. Eine Composable-Storefront hat keins. Sie ist keine Auslieferung, sondern eine Betriebsfläche, die ab dem ersten Live-Tag jeden Tag angefasst wird: Marketing spielt Kampagnen aus, Engineering liefert neue Komponenten, jemand hält Performance und Compliance stabil. Nichts davon steht im Projektplan, weil der Projektplan am Go-live aufhört.
2026 hat sich Composable Commerce vom Entwickler-Thema zur Business-Infrastruktur entwickelt. Governance und Editorial-Workflows sind vom technischen Detail zum Verkaufsargument geworden. Aber Infrastruktur braucht ein Betriebsmodell, kein Launch-Event. Budget, RACI und Timeline enden am Launch. Die Betriebsfläche fängt dort erst an. Diese Asymmetrie ist die Operating-Model-Lücke.
Das Muster ist erstaunlich stabil: Je sauberer das Replatforming lief, desto härter fällt der Übergang aus. Ein reibungsloses Go-live erzeugt den Eindruck, das Schwierige sei geschafft. Tatsächlich verschiebt es das Schwierige nur nach hinten, in eine Phase, für die niemand zuständig gemacht wurde.
Die drei Lager, die aneinander vorbei planen
Die Lücke entsteht nicht aus Nachlässigkeit. Sie entsteht, weil drei Lager parallel planen und jedes davon annimmt, ein anderes übernehme den laufenden Betrieb.
Editorial und Marketing
Marketing kauft Composable mit dem Versprechen, Seiten künftig selbst zu bauen. Nach dem Go-live stellt sich heraus, dass die Komponenten, die dafür nötig wären, nicht definiert sind oder Guardrails fehlen. Also landet die nächste Landingpage wieder als Ticket bei Engineering. Der Self-Service, für den das Projekt bezahlt wurde, existiert auf dem Papier, aber nicht im Alltag.
Development und Engineering
Engineering geht davon aus, dass die Arbeit erledigt ist, sobald die Plattform stabil läuft. Die Realität ist, dass jede Kampagne, jede saisonale Seite und jede A/B-Variante wieder auf dem Backlog liegt. Das Team, das sich vom Frontend-Bottleneck befreien wollte, ist erneut der Engpass, nur mit einem moderneren Stack.
Operations und Plattform
Betrieb nimmt an, Hosting sei "geregelt". Dann kommen die ersten Performance-Regressionen nach einem Deploy, ein Dependency-Update steht an, und die Frage, wer für Core Web Vitals und BFSG-Konformität im laufenden Betrieb verantwortlich ist, hat keine Antwort. Ownership für die Betriebsqualität war nie explizit vergeben.
Jedes Lager wartet auf ein anderes. Genau diese wechselseitige Annahme ist der Kern des Problems. Welche Rolle im Detail welche Verantwortung trägt, haben wir separat als Matrix aufgeschrieben: die RACI, die die meisten Teams nach dem Go-live überspringen.
Was ein Operating Model wirklich festlegen muss
Ein Betriebsmodell ist kein Org-Chart. Es ist die Antwort auf vier konkrete Fragen, die im Alltag jeden Tag auftauchen.
- Entscheidungsrechte. Wer darf was ohne Freigabe ändern? Wenn jede Textänderung ein Approval braucht, ist der Composable-Vorteil weg. Wenn jeder alles darf, entsteht Wildwuchs. Die Grenze muss gezogen sein, bevor sie im Konflikt geklärt wird.
- Change-Kadenz. Inhalte ändern sich täglich, Komponenten im Sprint-Rhythmus, Infrastruktur in Release-Fenstern. Drei Geschwindigkeiten, die getrennt gedacht werden müssen, damit die schnellste nicht auf die langsamste warten muss.
- Guardrails statt Gatekeeping. Engineering definiert Komponenten und ihre Grenzen. Innerhalb dieser Grenzen komponiert Editorial frei. Der Unterschied zwischen einem Guardrail und einem Gatekeeper entscheidet, ob Marketing beschleunigt oder wieder ansteht.
- Eskalations- und Ownership-Pfad. Wer ownt Performance, wer Accessibility, wer reagiert auf einen Incident? Ownership, das nur implizit existiert, existiert im Ernstfall nicht.
Wer diese vier Punkte vor dem Go-live beantwortet, hat ein Betriebsmodell. Wer sie danach beantwortet, zahlt den Preis in verlorenen Wochen. Der breitere Kontext, wie sich diese Rollen verschieben, wenn Backend und Authoring zunehmend agentisch werden, steckt in unserer Analyse zum Frontend Operating Model.
Wie eine Frontend Management Platform das Operating Model konkret macht
Die saubere Trennung der drei Lager bleibt Theorie, solange sie nur im Confluence-Dokument steht. Eine Frontend Management Platform (FMP), die Software-Kategorie, die Laioutr geprägt hat, gießt das Betriebsmodell in die Plattform selbst.
Editorial arbeitet im Studio: Marketing komponiert Seiten mit Live-Preview, ohne Deploy und ohne Engineering-Ticket. Development ownt die zentrale Komponenten-Bibliothek und die Guardrails: Engineering definiert, was komponierbar ist, und legt die Grenzen fest, innerhalb derer Editorial frei arbeitet. Operations wird zur Plattform-Eigenschaft statt zur Dauerlast: managed Hosting, CI/CD, Performance-Monitoring und EU-Hosting laufen als Betriebsmodell, das du nicht selbst zusammensetzen musst. Genau dieses Betriebsmodell fürs Commerce-Frontend beschreiben wir als Frontend as a Service.
Das ist kein Ersatz für organisatorische Klarheit, aber es macht sie durchsetzbar. Wenn die Plattform die Entscheidungsrechte, Kadenzen und Guardrails abbildet, muss das Team sie nicht in jedem Sprint neu verhandeln. Die Operating-Model-Lücke schließt sich nicht durch ein weiteres Meeting, sondern dadurch, dass Betrieb ein definierter Layer wird und kein Zufall.
Nächste Schritte
Wenn dein Composable-Frontend live ist und sich der Alltag trotzdem wieder wie Ticket-Stau anfühlt, ist selten die Technik das Problem. Es ist das fehlende Betriebsmodell. Der erste Schritt ist eine ehrliche Zuordnung: Wer ownt Inhalte, wer Komponenten, wer Betriebsqualität, und wo warten alle aufeinander?
Wenn du den Betriebs-Layer nicht selbst zusammenbauen willst, sieh dir an, wie Laioutr Studio, Storefront, Connect, Cloud und Agents als ein Betriebsmodell zusammenspielen. Buch dir eine Demo, in der wir das an deinem Stack durchgehen, statt an einer generischen Beispielseite.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er arbeitet mit Mid-Market-Teams in DACH an der Frage, wie Composable-Frontends nicht nur live gehen, sondern im Betrieb Tempo halten.