MarketingMarTech

Composable und Headless Marketing Stacks: was CMOs wirklich verstehen müssen

Der Wechsel von monolithischen Marketing-Plattformen zu composable, headless Architekturen verändert, wie Marken digitale Erlebnisse aufbauen und ausspielen. Wer die Mechanik versteht und nicht nur die Begriffe, führt solche Entscheidungen als CMO selbst, statt sich von Anbietern führen zu lassen.

🎙️

Podcast anhören

4 min

Der Begriff „composable Marketing Stack“ fällt in Anbieterpräsentationen und Architektur-Workshops mit einer Selbstsicherheit, die selten zur Klarheit der anschließenden Erklärung passt. Die meisten CMOs haben ihn gehört. Weniger können in einfachen Worten erklären, was er für die täkliche Arbeit ihres Teams, ihr Technologiebudget oder ihre Fähigkeit bedeutet, schneller zu agieren als ein Wettbewerber mit einer Legacy-Suite. Diese Lücke lohnt es sich zu schließen.

Warum das für diese Rolle besonders relevant ist

Im letzten Jahrzehnt war die integrierte Suite das dominierende Modell für Marketing-Technologie im Enterprise-Umfeld: Salesforce Marketing Cloud, Adobe Experience Cloud, Oracle Eloqua. Diese Plattformen versprachen alles unter einem Dach, und eine Zeit lang war dieses Versprechen glaubwürdig. Der Preis dafür: „ein Dach“ bedeutete eine Roadmap, das Innovationstempo eines einzigen Anbieters und sehr hohe Wechselkosten.

Mitte der 2020er war dieser Kompromiss schwerer zu rechtfertigen. Laut Gartner (dessen Research hier unabhängige Analystenarbeit ist, kein Anbietermaterial) stellen CMOs, die auf eine Single-Vendor-Suite setzen, immer häufiger fest, dass sie Best-in-Class-Funktionen in Bereichen wie KI-getriebener Personalisierung oder Real-Time Decisioning nicht einsetzen können, ohne zu warten, bis ihr Hauptanbieter aufgeholt hat, oder erhebliche Integrationsgebühren zu zahlen, um Drittanbieter-Tools anzuflanschen.

Das composable Modell ist eine direkte Antwort auf diese Frustration. Für einen CMO sind die strategischen Konsequenzen konkret: Eine composable Architektur zu wählen bedeutet, vorab mehr Integrationskomplexität in Kauf zu nehmen, und dafür einzelne Komponenten austauschen, mit neuen Tools experimentieren und den langsamen Verfall vermeiden zu können, der entsteht, wenn man in einer Plattform gefangen ist, die sich langsamer bewegt als der eigene Markt.

Das ist keine kleine Entscheidung. Sie betrifft Procurement, Engineering-Ressourcen, Data Governance und die Fähigkeit Ihres Teams, Kampagnen auszuliefern, ohne immer auf die IT zu warten.

Wie es tatsächlich funktioniert: die Mechanik in einfachen Worten

Das Wort „headless“ ist leichter zu erklären. In einem klassischen Content-Management-System sind die Front-End-Präsentationsschicht (was Nutzer im Browser oder in der App sehen) und das Back-End-Content-Repository eng gekoppelt. Ändert man das Aussehen einer Seite, arbeitet man im selben System, das auch die Inhalte speichert. Diese Kopplung macht schnelle Iteration über mehrere Kanäle hinweg, eine Website, eine Mobile App, ein Kiosk im Store, ein Voice Assistant, extrem mühsam.

Ein Headless CMS entkoppelt diese beiden Schichten. Das Back-End speichert und verwaltet Inhalte, liefert sie aber über eine API aus. Jedes Front-End kann diese Inhalte dann abrufen und so rendern, wie es sie braucht. Contentful, Sanity und Storyblok gehören zu den Anbietern in diesem Feld. Eine Marke wie Spotify oder Burberry, die headless arbeitet, kann Produkttexte einmal aktualisieren und sie über ein Dutzend Touchpoints erscheinen lassen, ohne dass ein Entwickler jeden einzelnen neu aufbaut.

„Composable“ ist die breitere Architekturphilosophie, in die headless eingebettet ist. Ein composable Stack besteht aus einzelnen, austauschbaren Komponenten, jede best-of-breed für ihre Funktion: ein Headless CMS für Content, eine separate CDP (Customer Data Platform) wie Segment oder mParticle für die Datenzusammenführung, eine eigenständige Personalisierungs-Engine wie Optimizely oder Dynamic Yield, eine unabhängige E-Mail- und Push-Plattform und so weiter. Diese Komponenten kommunizieren über APIs und immer häufiger über Event-Streaming-Schichten wie Confluent oder AWS EventBridge.

Ein konkretes Beispiel: Ein mittelgroßer Händler wie Joules (die britische Bekleidungsmarke), der hypothetisch von Salesforce Commerce Cloud auf ein composable Setup wechselt, könnte Contentful für Produktcontent, Algolia für Suche, Stripe für Payments und Klaviyo für Retention Marketing nutzen. Jeder Anbieter wird unabhängig ausgewählt und vertraglich gebunden und kann ersetzt werden, ohne den Rest zu zerlegen. Der Händler gewinnt in jedem Funktionsbereich Geschwindigkeit, braucht dafür aber eine Integrationsschicht und jemanden, der das gesamte System versteht.

Die MACH Alliance, ein 2020 gegründetes Branchenkonsortium von Anbietern, die nach den Prinzipien Microservices, API-first, Cloud-native und Headless bauen, hat diese Architektur bei Enterprise-Käufern bekannt gemacht. Die MACH Alliance ist ein anbietergetriebenes Gremium, keine unabhängige Standardisierungsorganisation, ihre Publikationen sollten also in diesem kommerziellen Kontext gelesen werden.

Wann man sie einsetzt und wann nicht: die ehrlichen Tradeoffs

Composable Architektur passt tatsächlich gut zu Organisationen mit hoher Content-Velocity, komplexen Multi-Channel-Anforderungen oder der Engineering-Kapazität, Integration zu managen. Ein globales Medienunternehmen, das monatlich tausende Inhalte über Web, Mobile und Connected TV veröffentlicht, hat ein starkes Argument. Eine Luxusmarke, die dutzende marktspezifische Microsites in mehreren Sprachen betreut, hat ein starkes Argument.

Es gibt Situationen, in denen sie die falsche Wahl ist, und CMOs, die composable Stacks durchsetzen, ohne das zu berücksichtigen, schaffen tendenziell teure Probleme.

Wenn Ihr Marketing-Team klein ist und stark von den eingebauten Workflows eines Anbieters abhängt, ist es schmerzhaft, diese Workflows zu entfernen, ohne die operative Logik zu ersetzen. Die Salesforce- oder HubSpot-Oberfläche (HubSpot ist ein CRM- und Marketing-Plattform-Anbieter mit einem offensichtlichen kommerziellen Interesse daran, integrierte Suiten zu bewerben), die Ihr Team täglich nutzt, existiert, weil sie jemand gebaut hat. Ein composable Stack bringt diese Oberfläche nicht mit. Er bringt API-Endpunkte und die Erwartung mit, dass Sie die Workflows, die Ihr Team braucht, selbst bauen oder kaufen.

Integrationskomplexität ist real, nicht theoretisch. Jede neue Komponente in einem composable Stack ist ein potenzieller Fehlerpunkt, ein zu verwaltender Vertrag und ein Satz Zugangsdaten, den Ihr Security-Team regeln muss. Die Total Cost of Ownership besteht nicht nur aus Lizenzgebühren: Sie umfasst die Engineers oder Systemintegratoren (Firmen wie Valtech oder Dept werden dafür häufig beauftragt), die alles verdrahten und diese Verbindungen pflegen, während jeder Anbieter seine APIs aktualisiert.

Dazu kommt die Frage der Reife. Composable Architektur belohnt Organisationen, die ihre Daten bereits aufgeräumt, ihre Customer Journey klar definiert und eine Governance dafür etabliert haben, wie Technologieentscheidungen getroffen werden. Organisationen, die diese Arbeit nicht geleistet haben, bauen tendenziell composable Stacks, die genauso in Silos zerfallen wie der Monolith, den sie ersetzt haben, nur teurer im Unterhalt.

Der disziplinierteste Weg ist inkrementell: Identifizieren Sie die eine oder zwei Komponenten Ihres heutigen Stacks, wo die Einschränkungen Sie wirklich Geld kosten, ersetzen Sie diese durch Best-of-Breed-Alternativen und bauen Sie Integrationsfähigkeit auf, bevor Sie die gesamte Plattform zerlegen. Eine komplette Replatforming in einem einzigen Programm unterschätzt die operative Störung fast immer.

CMOs, die diese Architektur verstehen, müssen keine Engineers werden. Sie müssen aber unterscheiden können zwischen einem Anbieter, der composable als Konzept verkauft, und einem Anbieter, der erklärt, welche Integration, Wartung und Team-Fähigkeit das in Ihrer Organisation tatsächlich erfordert.

Mehr dazu

Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.

  1. 1MarTech-Stack-Architektur: Frameworks & MethodikMarTech & Data
  2. 2CMO-Playbook & fortgeschrittene Taktiken für die MarTech-Stack-ArchitekturMarTech & Data
  3. 3Praxisanwendung: einen MarTech-Stack aufbauen und betreiben, der tatsächlich Umsatz bringtMarTech & Data
  4. 4MarTech-Stack-Architektur: Grundlagen & KernkonzepteMarTech & Data
  5. 5CDP & first-party data: Grundlagen & KernkonzepteMarTech & Data

Artikel gelesen?

Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.