Wie LEGO seinen Marketing-Stack auf einer Composable-Architektur neu aufgebaut hat

2021 betrieb die LEGO Group eine der Spielzeug-Retail-Seiten mit dem höchsten Traffic weltweit und verarbeitete jährlich Millionen Transaktionen in mehr als 30 Märkten. Das Problem lag in der Architektur. LEGO.com lief auf einer eng gekoppelten monolithischen Plattform, bei der Änderungen am Content-Layer Releases erforderten, die den Commerce-Layer berührten, und umgekehrt. Marketing-Teams in Kopenhagen warteten Wochen auf Kampagnenseiten, die ein Wettbewerber in Tagen aufsetzen konnte. Personalisierung at scale, also unterschiedliche Produkterlebnisse für die Eltern eines Siebenjährigen in Deutschland gegenüber einem Sammler in Japan, war praktisch unmöglich ohne Custom Development, das eine ohnehin überlastete Engineering-Queue weiter aufstaute.

Der Druck aus dem Geschäft war klar: LEGOs Direct-to-Consumer-Ambitionen brauchten ein digitales Setup, das im Tempo des Kampagnenkalenders arbeitet und nicht im Tempo der Release-Zyklen des Legacy-CMS.

Was LEGO konkret getan hat

Die Technologie- und Marketing-Teams von LEGO entschieden sich bewusst dafür, den Monolithen in einzelne, austauschbare Services zu zerlegen, die über APIs verbunden sind. Die Architektur, auf die sie zugegangen sind, folgt den sogenannten MACH-Prinzipien: Microservices, APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-first, Cloud-native und Headless. Contentful, Anbieter eines Headless CMS, nennt LEGO als Referenzkunden (Hinweis: Contentful ist ein kommerzieller Anbieter mit einem Interesse daran, diese Partnerschaft öffentlich zu machen, Details sollten also gegen unabhängige Quellen geprüft werden).

Praktisch hat LEGO den Content-Management-Layer von der Commerce-Engine getrennt. Content-Redakteure konnten Kampagnenseiten nun veröffentlichen und weiterentwickeln, ohne ein vollständiges Commerce-Deployment auszulösen. Der Front-end-Presentation-Layer, also das Erlebnis, das ein Besucher tatsächlich sieht, wurde zum Konsumenten von APIs statt zum Produkt eines einzigen integrierten Systems. Damit konnten LEGOs interne Engineering-Teams für jede Funktion das beste Tool wählen: einen Anbieter für Search, einen anderen für Personalisierung, einen weiteren für Checkout, anstatt zu akzeptieren, was eine einzelne Plattform gebündelt mitliefert.

Die Migration war keine Rip-and-Replace-Aktion über ein Wochenende. LEGO fuhr einen phasenweisen Übergang und behielt zentrale Commerce-Funktionalität auf der bestehenden Infrastruktur, während neue Content-Erlebnisse schrittweise auf den Composable-Layer migriert wurden. Dieses Strangler-Fig-Pattern, bei dem neue Komponenten die alten allmählich ersetzen ohne einen einzigen Big-Bang-Cutover, ist bei großen Architekturänderungen Standard und senkt das Risiko gleichzeitiger Ausfälle über mehrere Systeme hinweg.

Lokalisierung war ein konkreter Treiber. Mit einem Headless-Setup lassen sich Inhalte, die als strukturierte Daten gespeichert sind, an unterschiedliche Front-ends für unterschiedliche Märkte ausliefern, ohne pro Locale Page-Templates neu zu bauen. LEGOs Präsenz in über 30 Märkten machte das besonders wertvoll. Ein Produktlaunch in Skandinavien erforderte nicht länger einen separaten Content-Build gegenüber einem Launch in Südostasien.

Die organisatorische Dimension

Die technische Veränderung erzwang eine organisatorische. LEGO stellte die Content-Workflows so um, dass Marketing-Redakteure mehr vom Publishing-Prozess direkt verantworteten, was die Abhängigkeit von Entwicklern bei Routine-Updates reduzierte. Diese Verschiebung erforderte Training und neue Tools für nicht-technische Mitarbeiter, und sie erzeugte zunächst Reibung. Governance-Modelle für einen Composable Stack sind tatsächlich komplexer als für einen Monolithen: Wenn eine Personalisierungs-API von Anbieter A mit einem CMS von Anbieter B und einer Commerce-Engine von Anbieter C verbunden ist, erfordert das Debuggen eines gestörten Kundenerlebnisses Koordination über drei Anbieterbeziehungen und mehrere interne Teams hinweg.

Die Ergebnisse

Präzise Performance-Zahlen aus LEGOs Composable-Migration sind nicht öffentlich geprüft, konkrete Zahlen sollten also mit der entsprechenden Vorsicht behandelt werden. Was LEGO öffentlich kommuniziert hat und was Contentful in seinen Marketing-Materialien anführt (auch hier eine Anbieterquelle), umfasst eine kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ürzere Time-to-publish für Kampagnen-Content und eine bessere Fähigkeit, parallele Marktlaunches zu fahren. Das Wachstum des Direct-to-Consumer-Umsatzes von 2021 bis 2023 war stark, spiegelt aber mehrere Faktoren wider, darunter die generelle Markenstärke und die Produktperformance, nicht allein die Architektur.

Wo unabhängige Analysen vorliegen: Untersuchungen von Gartner zu Composable-Commerce-Architekturen (in früheren Jahren veröffentlicht, 2026 aber weiterhin breit zitiert) zeigten, dass Organisationen nach dem Wechsel auf Composable-Setups im Durchschnitt 80 % schnellere Feature-Deployment-Zyklen berichteten, wobei Gartners eigene Methodik auf erhebliche Varianz je nach organisatorischer Reife hinweist. Diese Zahl deckt sich in der Richtung mit dem, was LEGOs Teams in Konferenzvorträgen qualitativ beschrieben haben, sie sollte aber nicht als verifizierte LEGO-spezifische Zahl gelesen werden.

Das Kostenbild ist weniger schmeichelhaft, als Anbieter-Case-Studies üblicherweise zugeben. Ein Composable Stack bedeutet, mehrere SaaS-Verträge parallel zu bezahlen, mehr Anbieterbeziehungen zu managen und den Integrations-Kleber zwischen den Services zu pflegen. Für LEGO, eine Organisation mit hunderten Engineers und einem substanziellen Technologiebudget, ist diese Komplexität beherrschbar. Für eine Mid-Market-Marke mit einem Team von acht Entwicklern kann die gleiche Architektur leicht mehr Probleme schaffen als lösen.

Was übertragbar ist und was nicht

Die zentrale übertragbare Lehre ist die Trennung der Zuständigkeiten. Wenn die Geschwindigkeit Ihres Content-Publishings durch Ihren Commerce-Release-Zyklus begrenzt wird, haben Sie ein Architekturproblem, das kein MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ß an Projektmanagement löst. Wenn der Output Ihres Marketing-Teams von Engineering-Deployments abhängt, lohnt es sich, das strukturell zu prüfen und nicht nur operativ.

Das Lokalisierungsargument trägt gut. Jede Marke, die in mehreren Märkten mit deutlich unterschiedlichem Content-Bedarf arbeitet, wird feststellen, dass strukturierter, per API ausgelieferter Content Duplikate weit stärker reduziert als template-basierte Monolithen.

Was sich nicht automatisch übertragen lässt:

• LEGOs Engineering-Kapazität. Das Unternehmen hat die internen Talente, um Integrationen zu bauen und zu pflegen. Die meisten Marken haben das nicht, und die Lücke zwischen „composable in der Theorie" und „composable in Produktion" wird von Entwicklern gefüllt, die Ihre Organisation vielleicht noch nicht eingestellt hat.
• Die Reife des Anbieter-Ökosystems schwankt je nach Funktion. Headless CMS ist ein entwickelter Markt mit glaubwürdigen Optionen. Composable Loyalty-Plattformen oder composable Customer-Data-Infrastruktur stehen früher, und die Integrationskomplexität ist höher.
• Organisatorische Reife zählt mehr als die Technologieauswahl. LEGO musste Marketing-Mitarbeiter neu schulen und Workflows umbauen. Marken, die Composability als reines IT-Projekt behandeln und Marketing Operations unverändert lassen, werden hinter dem Modell zurückbleiben.

Die Entscheidung für composable ist ernsthaft zu prüfen, wenn Ihre aktuelle Plattform eine echte Begrenzung für den Marketing-Output darstellt, Sie die Engineering-Ressourcen haben, um die Integrationskomplexität zu managen, und Ihre Markt- oder Produktkomplexität den Overhead rechtfertigt. Sind nicht alle drei Bedingungen erfüllt, liefert eine stärker integrierte Plattform mit etwas API-Flexibilität praktisch oft bessere Ergebnisse als eine vollständige MACH-Architektur. Die Architektur sollte dem Geschäftsbedarf folgen, nicht ihm vorausgehen.