Composable Frontend Ownership nach dem Go-Live: das RACI, das die meisten Teams überspringen

Composable Commerce Ownership entscheidet sich nicht im Architektur-Workshop, sondern am ersten Montag nach dem Go-Live. Die harte Frage lautet nicht „welche Bausteine kombinieren wir", sondern „wer betreibt das Frontend, wenn die Migration abgehakt ist". Genau dieses RACI überspringen die meisten Teams, und die Rechnung kommt in Woche drei.

Was ist Composable Frontend Ownership nach dem Go-Live?

Ownership nach dem Go-Live bedeutet: klar zugeordnete Verantwortung für alles, was am Composable Frontend im laufenden Betrieb passiert. Component-Library, SEO- und GEO-Tuning, Core Web Vitals, Content-Änderungen, Connector-Health und Deploy-Rhythmus. Ein Composable Stack verteilt Fähigkeiten auf mehrere Services. Wer die Verantwortung nicht genauso explizit verteilt wie die Services, bekommt ein Frontend, das technisch entkoppelt, organisatorisch aber niemandem zugeordnet ist.

RACI ist dafür das nüchternste Werkzeug: Responsible (macht die Arbeit), Accountable (trägt die Entscheidung, genau eine Rolle pro Zeile), Consulted (wird gefragt), Informed (wird informiert). Kein Framework-Zauber, nur eine Tabelle, die eine unbequeme Frage beantwortet: Wenn der LCP am Freitag auf 3,4 Sekunden springt, wessen Kalender wird geblockt?

Das Problem: das RACI, das die meisten Teams überspringen

Im Projektmodus ist alles klar. Es gibt einen Implementierungspartner, einen Sprint-Plan und ein Go-Live-Datum. Nach dem Go-Live löst sich diese Klarheit auf. Der Partner ist raus oder im Support-Retainer, das interne Team wechselt aufs nächste Projekt, und das Frontend gehört plötzlich „irgendwie allen".

Das ist die Phase, in der aus Architektur-Versprechen Betriebs-Schmerz wird. Wer den Sprung vor zwei Jahren gewagt hat, kennt das inzwischen: Genau darüber schreiben wir in Composable Regret nach der Woche der 30-Minuten-Storefronts. Die Storefront steht in Rekordzeit, aber die Frage „wer hält sie am Laufen" wurde nie beantwortet.

Typische Symptome eines fehlenden Post-Launch-RACI:

• Der SEO-Toten-Winkel. Meta-Tags, Schema.org und interne Verlinkung verrotten, weil niemand accountable ist. Marketing denkt, das macht Engineering. Engineering denkt, das ist Content.
• Die Performance-Regression ohne Owner. Ein neues Third-Party-Skript kippt die Core Web Vitals. Es gibt einen Alarm, aber keine Rolle, die den Alarm besitzt.
• Der Content-Stau. Eine Kampagnen-Landingpage braucht drei Freigaben und ein Dev-Ticket, weil unklar ist, wer im Frontend was ändern darf.
• Die Integrations-Schuld. Jeder Connector wird beim Bau gefeiert und danach vergessen. Wie das eskaliert, haben wir in den versteckten Kosten der Composable-Integrations-Schuld aufgeschrieben.

Das gemeinsame Muster: nicht die Technik ist das Problem, sondern die fehlende Accountable-Rolle pro Betriebsaufgabe.

Wie ein Composable Frontend RACI nach dem Go-Live aussieht

Vier Rollen reichen für den Start: Frontend-Engineering (Component-Library, Build, Deploy), Product- oder Marketing-Owner (Content, Kampagnen, Conversion), Platform-Owner (Connector-Health, Betrieb, Security) und SEO/GEO-Verantwortliche (Sichtbarkeit, Schema, AI-Overview-Zitierfähigkeit). Wichtig ist nicht die Anzahl der Rollen, sondern dass in jeder Zeile genau ein A steht.

Diese Tabelle klärt die Freitag-Nachmittag-Frage. Sie sagt auch, wer nicht gefragt werden muss, was mindestens genauso wertvoll ist.

Der zweite Schritt: Ownership technisch tragbar machen. Ein RACI auf Papier bleibt Theorie, wenn jede Content-Änderung ein Dev-Ticket auslöst. Deshalb koppeln wir die Rollen an eine Composable Headless Frontend-Ebene, auf der Marketing im Studio publiziert, Engineering die Component-Library reviewt und der Platform-Owner die Connector-Health im Blick behält, alles auf einer Komponenten-Basis. Bug einmal gefixt, überall live. Das macht das A pro Zeile erst wirklich haltbar.

Was Du gewinnst

FAQ

Ist RACI nicht Overkill für ein kleines Team? Nein. Bei kleinen Teams tragen zwei Personen mehrere Rollen. Der Punkt ist nicht die Organigramm-Größe, sondern dass jede Betriebsaufgabe genau ein A hat. Eine Zeile mit zwei A ist schlimmer als keine Tabelle.

Wer sollte den Platform-Owner stellen, intern oder der Partner? Nach dem Go-Live gehört Accountability nach innen. Ein Partner kann Responsible bleiben (Retainer), aber die Entscheidung über den Betrieb sollte im eigenen Haus liegen, sonst wiederholt sich der Projekt-Cliff beim nächsten Vertragsende.

Wie schnell lässt sich das aufsetzen? Das RACI selbst ist ein 90-Minuten-Workshop. Die technische Tragbarkeit (Publishing ohne Dev-Ticket, zentrale Component-Library) hängt an der Frontend-Ebene. Auf Laioutr ist das der Standardbetrieb, kein Sonderprojekt.

Nächste Schritte

Setz das RACI auf, bevor der Implementierungspartner das Projekt verlässt, nicht danach. Wenn Du sehen willst, wie klare Ownership technisch tragbar wird, wirf einen Blick auf die Composable Headless Frontend-Ebene und die Agentic Frontend Management Platform.

Weitere Themen aus der Laioutr-Plattform

• Composable Headless Frontend
• Composable Digital Experience Platform
• Agentic Frontend Management Platform
• SEO and GEO
• Was ist eine Frontend Management Platform

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und arbeitet mit DACH-Teams an Composable-Frontends, die nach dem Go-Live betreibbar bleiben. Mehr auf LinkedIn.