Einen Storefront zu lesen, ist der einfache Teil. Model-Context-Protocol-Schnittstellen lassen Agent…
Wer besitzt die Storefront? Die Frontend Management Platform als Betriebs-Layer zwischen Marketing und Engineering
Fragen Sie fünf Personen in einem Mid-Market-E-Commerce-Unternehmen, wer die Storefront besitzt, und Sie bekommen fünf verschiedene Antworten: Marketing zeigt auf das CMS, Engineering zeigt auf die Deploy-Pipeline, die Geschäftsführung zeigt auf beide. Diese Unklarheit ist kein Kommunikationsproblem, das sich mit einem besseren Slack-Kanal lösen lässt. Es ist eine Governance-Lücke, und sie zeigt sich in langsamen Kampagnen, doppelten Komponenten und einem Backlog, den beide Teams dem jeweils anderen zuschieben. 2026, wo Storefronts zunehmend auch KI-Shopping-Agenten bedienen und nicht nur menschliche Besucher, wird die Ownership-Frage schwieriger, nicht einfacher, unbeantwortet zu lassen.
Wo Ownership heute scheitert
Drei Ausfallmuster wiederholen sich bei DACH-Mid-Market- und Enterprise-Teams, mit denen wir sprechen:
- Marketing besitzt nichts und wartet. Jeder Hero-Banner-Tausch, jede Landing-Page für eine Kampagne läuft über eine Engineering-Ticket-Warteschlange. Time-to-Launch für eine neue Landing-Page dehnt sich auf Wochen. Marketing verliert die Fähigkeit, auf einen Markt-Moment zu reagieren.
- Engineering besitzt alles und wird zum Flaschenhals. Jede Komponenten-Änderung, jedes Brand-Update, jede A/B-Test-Variante braucht einen Sprint-Slot. Engineering ärgert sich, als Freigabe-Instanz für Text-Änderungen zu fungieren, Marketing ärgert sich über die Wartezeit.
- Niemand besitzt es, und es driftet. Ohne benannten Owner forken Komponenten-Bibliotheken pro Kampagne, die Markenkonsistenz erodiert Seite für Seite, und niemand bemerkt es, bis ein Kunde sich über einen kaputten Checkout auf einer Seite beschwert, die im letzten Quartal drei Teams angefasst haben.
Keines davon ist ein Personenproblem. Es ist das vorhersehbare Ergebnis, das Frontend entweder als "Marketing-Tool" oder als "Engineering-Deliverable" zu behandeln, obwohl es strukturell beides ist.
Ein RACI-Modell für das Frontend
Die Lösung beginnt damit, zu benennen, wer für konkrete Frontend-Aufgaben Responsible, Accountable, Consulted und Informed ist, nicht für "das Frontend" als einen Block.
- Landing-Page-Komposition. Marketing: R. Engineering: C. Plattform-/FMP-Layer: A (Guardrails).
- Neuer Komponenten-Build. Marketing: I. Engineering: R/A. Plattform-/FMP-Layer: C.
- Brand-Token-/Theme-Änderungen. Marketing: C. Engineering: I. Plattform-/FMP-Layer: R/A.
- Backend-Integration, API-Verträge. Marketing: I. Engineering: R/A. Plattform-/FMP-Layer: C.
- Performance-Budget (LCP, CLS). Marketing: I. Engineering: A. Plattform-/FMP-Layer: R.
- Content-Lokalisierung (DE/EN/FR). Marketing: R/A. Engineering: I. Plattform-/FMP-Layer: C.
- A/B-Test-Rollout. Marketing: R. Engineering: C. Plattform-/FMP-Layer: A.
Lesen Sie die Tabelle spaltenweise, nicht zeilenweise: Engineering ist Accountable für alles, was Datenverträge und Performance betrifft, Marketing ist Accountable für alles, was Botschaft und Komposition betrifft, und ein gemeinsamer Plattform-Layer hält die Guardrails, innerhalb derer beide Seiten arbeiten. Genau diese dritte Spalte ist bei den meisten Organisationen die Lücke. Jemand muss sie besitzen, sonst kollidieren die ersten beiden Spalten immer wieder.
Der Betriebs-Layer: Wie eine Frontend Management Platform die Grenzen neu zieht
Genau diese Rolle füllt eine Frontend Management Platform. Engineering definiert die Komponenten-Bibliothek, die Design-Tokens, das Performance-Budget und die Backend-Anbindungen einmal. Marketing komponiert danach Seiten, tauscht Inhalte und fährt Kampagnen innerhalb dieser Guardrails, im Studio, ohne ein Ticket zu öffnen. Niemand muss zwischen "Marketing darf nichts anfassen" und "Engineering hat keine Kontrolle" wählen. Die Plattform ist der gemeinsame Betriebs-Layer, an den beide RACI-Spalten andocken.
Derselbe Layer muss zunehmend einem dritten Stakeholder gerecht werden, den weder Marketing noch Engineering allein besitzt: KI-Shopping-Agenten, die Ihre Storefront lesen. Eine von Grund auf agent-fähige Plattform behandelt strukturierte Daten, Schema-Markup und agent-lesbaren Komponenten-Output als Plattform-Verantwortung, nicht als Einzelaufgabe, die dem Team zufällt, das die Lücke zuerst bemerkt. Wie dieser gemeinsame Betriebs-Layer über Formate hinweg skaliert, haben wir in Frontend Management vs. dem Generation-Lifecycle beschrieben: Generation ist ein einmaliger Build-Schritt, Management ist die fortlaufende Betriebsdisziplin, um die es in diesem RACI-Modell eigentlich geht.
Für Teams, die die Storefront noch als Anbau an die Backend-Plattform betreiben, stellt sich dieselbe Governance-Frage auf Infrastruktur-Ebene: Wer besitzt Hosting, CI/CD und Uptime, sobald das Frontend vom Backend-Release-Zyklus entkoppelt ist? Genau das ist die Betriebsfrage hinter Frontend as a Service als Delivery-Modell, nicht nur als Hosting-Entscheidung.
Was das für Teams bedeutet
- Halten Sie das RACI für Ihre fünf häufigsten Frontend-Aufgaben in diesem Quartal schriftlich fest. Wenn Sie die Spalte "Accountable" für Landing-Page-Komposition oder Performance-Budget nicht füllen können, ist das Ihr erster Fix.
- Messen Sie Frontend-Velocity nicht länger allein an der Engineering-Sprint-Kapazität. Wenn Marketing keine Kampagnen-Seite ohne Ticket ausspielen kann, ist das Ownership-Modell der Flaschenhals, nicht das Team.
- Trennen Sie den Plattform-Layer organisatorisch von beiden Abteilungen. Ein gemeinsamer Betriebs-Layer, der nur an Engineering berichtet, optimiert auf Stabilität statt Geschwindigkeit; einer, der nur an Marketing berichtet, optimiert auf Geschwindigkeit statt Stabilität. Keiner von beiden dient dem Geschäft allein.
- Budgetieren Sie Agent-Lesbarkeit jetzt als Plattform-Verantwortung, nicht als Nachrüstung 2027. Strukturierte Daten und Schema-Pflege brauchen heute einen Owner.
Häufige Fragen
Sollte Marketing oder Engineering die Storefront besitzen? Keins von beiden allein. Marketing sollte Komposition, Content und Kampagnen-Geschwindigkeit besitzen. Engineering sollte die Komponenten-Bibliothek, Datenverträge und das Performance-Budget besitzen. Ein gemeinsamer Betriebs-Layer, die Frontend Management Platform, besitzt die Guardrails, innerhalb derer beide Seiten arbeiten.
Was ist das deutlichste Zeichen, dass unser RACI-Modell kaputt ist? Landing- oder Kampagnen-Seiten, die für eine Text- oder Bildänderung ein Engineering-Ticket brauchen. Das zeigt, dass Engineering Aufgaben besitzt, für die Marketing Responsible sein sollte.
Verliert Engineering die Kontrolle, wenn wir eine FMP einführen? Nein. Engineering definiert die Komponenten-Bibliothek, die Guardrails und das Performance-Budget einmal. Marketing komponiert innerhalb dieser Grenzen. Engineerings Kontrolle verschiebt sich von der Freigabe jeder einzelnen Seite zur Pflege des Systems, auf dem alle Seiten laufen.
Wie ändert sich das durch KI-Shopping-Agenten? Agenten lesen inzwischen die strukturierten Daten und den Komponenten-Output Ihrer Storefront genauso, wie menschliche Shopper Ihr Layout lesen. Das ist eine neue, gemeinsame Verantwortung, die weder Marketing noch Engineering standardmäßig besitzt, und genau deshalb braucht sie eine Antwort auf Plattform-Ebene.
Nächste Schritte
Wenn Ihr Team noch jede Storefront-Änderung über den Backlog einer einzigen Abteilung leitet, sprechen Sie mit uns darüber, wie ein gemeinsamer Betriebs-Layer für Ihren Stack aussieht.
CTA: Lassen Sie sich zeigen, wie Laioutr Frontend-Ownership für Ihr Team definiert
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist CEO & Co-Founder von Laioutr. Er schreibt über Frontend-Architektur, Agentic Commerce und den Aufbau composabler Storefronts ohne Replatforming-Risiko.