Das Muster ist vorhersagbar. Ein Konzern mit mehreren Marken kündigt eine „einheitliche Plattform“ an. Das technische Team entwirft ein gemeinsames Backend, eine Component Library, eine einzige Deployment-Pipeline. Achtzehn Monate später gibt es drei Plattformen: die „einheitliche“ plus zwei markenspezifische Forks, die entstanden sind, als sich die Stakeholder nicht einigen konnten.
Das gemeinsame Backend hat funktioniert. Der Streit ging darum, wem was gehört.
Jede Marke und jede Business Unit hält ihre Customer Journey für einzigartig. Ganz unbegründet ist das nicht: Markenidentität, Preisstrategie, regulatorischer Kontext und Kundenerwartungen unterscheiden sich durchaus. Meist ist der Unterschied trotzdem kleiner als behauptet. Die darunterliegenden Commerce-Abläufe (Warenkorb, Checkout, Bestand, Fulfillment) sind über die Marken hinweg weitgehend identisch.
Das Engineering-Team sieht die Überschneidung und entwirft auf Wiederverwendung. Die Markenführung sieht den Unterschied und will nicht nachgeben. Das Projekt bleibt dazwischen stecken.
Die Architektur muss zuerst das politische Problem lösen, indem sie den Markenverantwortlichen etwas gibt, das sichtbar ihnen gehört, damit sie aufhören, das gemeinsame Backend zu blockieren.
Bei Volkswagen sollten fünf Automarken (VW, Audi, Skoda, Seat, Porsche) über eine gemeinsame Commerce-Plattform direkt an Endkunden verkaufen, mit über einer Million Nutzern in fünf Märkten. Was jede Markenführung brauchte, war der Beleg im eigenen Reporting, dass die gemeinsame Plattform ihrer Marke dient. Also berichtete die Plattform Marke für Marke: Order Intake, Bestand und Auslieferung auf gemeinsamen Definitionen, sodass eine Markenleitung ihre eigenen Zahlen auf derselben Grundlage sah wie alle anderen. Darunter übernahm ein Commerce-Rückgrat Warenkorb-Logik, Zahlungsabwicklung, Bestandsführung und Auftragsabwicklung für alle fünf.
Jede Markenführung konnte auf Ergebnisse zeigen, die eindeutig ihre waren, und das Engineering pflegte ein Backend.
Architektur ist notwendig und reicht nicht. Die zweite Anforderung: Jeder Stakeholder muss auf etwas in der Plattform zeigen und es als Erfolg verbuchen können. Das Plattform-Team muss auf politische Lesbarkeit hin entwerfen: Namenskonventionen, Dashboards, Reporting-Strukturen und Governance-Modelle, die jedem Beteiligten Sichtbarkeit und Anerkennung geben.
Wenn deine einheitliche Plattform ein einziges Dashboard mit „Plattform-Kennzahlen“ ohne Aufschlüsselung nach Marke hat, hast du schon verloren. Jede Marke muss ihre Zahlen sehen, in ihrem Kontext, präsentiert als ihr Erfolg.
Deine Multi-Brand-Architektur muss einen Stakeholder überstehen, der sie ablehnt. Wenn sie das nicht kann, hast du einen Vorschlag, und die Forks werden bereits geplant.
Die Leute, die die Macht haben, zu forken, zu verzögern oder das Projekt zu beenden, müssen ihre Interessen im Entwurf wiederfinden. Ohne das übersteht eine einheitliche Plattform selten ihr erstes Jahr.