Composable Commerce: Definition und Unterschied zu Headless

Composable Commerce ist ein Architekturansatz für Onlineshops, bei dem du die Plattform aus einzelnen, spezialisierten Bausteinen zusammensetzt, statt alles aus einem System zu beziehen. Commerce Engine, Content-Management, Suche, Produktdaten und Checkout können von verschiedenen Anbietern stammen und tauschen ihre Daten über Schnittstellen (APIs) aus. Jeden Baustein kannst du weiterentwickeln oder ersetzen, ohne den ganzen Shop neu zu bauen.

„Composable“ heißt zusammensetzbar. Bekannt gemacht hat den Begriff das Analysehaus Gartner um das Jahr 2020. Gartner spricht von Packaged Business Capabilities, also abgepackten Geschäftsfähigkeiten: Bausteine, die eine fachlich klar umrissene Aufgabe vollständig übernehmen und über Schnittstellen angesprochen werden.

Ein Baustein übernimmt eine Geschäftsfähigkeit, keine Einzelfunktion

Ein Rabattcode-Feld ist kein Baustein. Promotion-Management dagegen schon: Es verwaltet Regeln, Zielgruppen, Laufzeiten und Freigaben, und ein Team oder ein Anbieter ist dafür verantwortlich. Dieselbe Logik gilt für Suche, Produktinformation, Content, Warenkorb, Preisfindung oder Kundenkonto. Prüfe bei jeder Grenze, ob jemand den Bereich fachlich versteht, ihn unabhängig weiterentwickeln und über eine stabile Schnittstelle anbieten kann. Ist das nicht der Fall, ist die Grenze falsch gezogen.

Composable beschreibt ein Bauprinzip

Viele Anbieter schreiben „composable“ auf ihre Plattform. Ob eine Architektur tatsächlich zusammensetzbar ist, zeigt sich an vier Eigenschaften: offene, dokumentierte Schnittstellen, vollständiger Zugriff auf die eigenen Daten, getrennte Updates der Bausteine und ein realistischer Weg, einen Baustein auszutauschen. Auch ein klassisches Shopsystem kann Teil einer composable Landschaft sein, wenn es eine klar definierte Rolle übernimmt, zum Beispiel als Commerce Engine hinter einem eigenen Frontend.

Umgekehrt ist eine Sammlung moderner Cloud-Dienste nicht automatisch composable. Wenn sich alle Dienste nur gemeinsam verändern lassen, hast du ein verteiltes System mit den Nachteilen eines Monolithen und zusätzlich den Netzwerkgrenzen dazwischen.

Ein Beispiel aus dem Alltag eines Shops

Ein Händler mit mehreren Marken verwaltet Produktdaten in einem PIM, Inhalte und Landingpages in einem Headless CMS, die Suche in einem spezialisierten Suchdienst und Warenkorb, Preise und Bestellungen in einer Commerce Engine. Ein eigenes Frontend holt sich die Daten aus allen vier Systemen und zeigt sie als eine Produktseite an. Will das Marketing später eine andere Suche testen, tauscht das Team nur diesen Baustein aus. Die übrigen drei bleiben unberührt.

Worum es eigentlich geht

Das Ziel von Composable Commerce ist Veränderbarkeit. Du sollst einen Teil deines Shops verbessern können, ohne den Rest anzufassen. Diese Freiheit hat einen Preis: Jemand muss die Bausteine auswählen, verbinden, überwachen und gemeinsam betreiben. Ob sich das für dich lohnt, klären die Abschnitte zu Vorteilen, Nachteilen und Eignung weiter unten.

Headless Commerce bedeutet, dass die sichtbare Oberfläche deines Shops, das Frontend oder „Head“, technisch vom Commerce-Backend getrennt ist. Das Backend verwaltet Produkte, Preise, Warenkorb und Bestellungen und stellt sie über APIs bereit. Das Frontend ist eine eigene Anwendung, die diese Daten abruft und darstellt. Die mitgelieferten Templates des Shopsystems werden dafür nicht mehr verwendet.

So funktioniert ein Headless-Shop

Ruft jemand eine Produktseite auf, fragt das Frontend Produktdaten, Preise und Verfügbarkeit über die Schnittstelle des Backends ab und baut daraus die Seite. Legt die Person etwas in den Warenkorb, schickt das Frontend auch diese Aktion über die API an das Backend. Häufig sitzt dazwischen ein Backend-for-Frontend: eine schlanke Schicht, die Antworten mehrerer Systeme bündelt und für genau eine Oberfläche aufbereitet. Gebaut werden Headless-Frontends meist mit JavaScript-Frameworks wie Next.js. Shopify bietet mit Hydrogen ein eigenes Framework dafür an, das wir im Ratgeber zu Shopify Hydrogen und seinen Einsatzgrenzen einordnen.

Die Vorteile von Headless Commerce

• Freie Gestaltung: Das Frontend ist nicht an Theme-Strukturen gebunden. Du baust genau die Seiten und Abläufe, die dein Sortiment braucht.
• Mehrere Kanäle aus einem Backend: Website, App, Kundenportal oder ein Terminal im Laden greifen auf denselben Katalog und dieselben Bestellungen zu.
• Getrennte Releases: Das Frontend-Team ändert und testet Seiten, ohne das Backend anzufassen.
• Performance in eigener Hand: Rendering, Caching und Auslieferung legst du selbst fest, statt sie vom Shopsystem vorgegeben zu bekommen.

Was Headless Commerce dich kostet

Mit dem Frontend übernimmst du Verantwortung, die vorher das Shopsystem getragen hat: Hosting, Deployment, Caching, Barrierefreiheit, Tracking und Einwilligungen sowie eine Vorschau für Redakteure. Viele Apps und Plugins eines Shopsystems setzen auf die Standard-Templates auf und funktionieren headless gar nicht oder nur mit eigener Anpassung. Jede neue Funktion im Frontend ist Entwicklungsarbeit statt einer Theme-Einstellung. Auch das Marketing verliert den gewohnten Theme-Editor, solange kein Headless CMS diese Rolle übernimmt.

Was Headless-Commerce-Entwicklung praktisch umfasst

Ein Headless-Projekt besteht aus mehr als einem neuen Frontend. Dazu gehören ein Datenmodell für Inhalte, die Anbindung an die Storefront-API des Backends, eine Lösung für Suche und Filter, die Integration des Checkouts, Vorschau und Freigabe für Inhalte, Monitoring und SEO-Grundlagen wie serverseitiges Rendering, saubere URLs und strukturierte Daten. Wer nur das Frontend einplant, unterschätzt den laufenden Betrieb.

Rechne außerdem mit Aufwand für Inhalte, die heute im Theme stecken: Banner, Navigation, Landingpages und formatierte Produktbeschreibungen müssen in ein Content-Modell übertragen werden, bevor das neue Frontend sie anzeigen kann.

Suite, Headless und Composable sind keine konkurrierenden Produkte, sondern drei Stufen der Entkopplung. Die eigentliche Frage lautet, welche Teile deines Shops sich unabhängig voneinander verändern sollen: gar keine, nur die Oberfläche oder auch einzelne Fähigkeiten im Backend.

Die Suite: alles aus einem System

Eine Suite, oft auch Monolith genannt, liefert Frontend, Katalog, Warenkorb, Checkout, Content und Verwaltung aus einer Hand. Shopify mit einem Theme oder Shopware und WooCommerce in der Standardnutzung sind typische Beispiele. Die Teile sind aufeinander abgestimmt, Updates kommen gebündelt, und Erweiterungen laufen über Apps oder Plugins. Reicht eine Fähigkeit nicht aus, bist du auf das angewiesen, was die Plattform und ihr Ökosystem dafür anbieten.

Headless: eigene Oberfläche, gemeinsamer Kern

Bei Headless trennst du das Frontend ab, das Backend bleibt eine Suite. Willst du später die Suche oder die Preislogik wechseln, greifst du weiterhin tief in dieses zentrale Backend ein. Ein Headless-Shop ist deshalb nicht automatisch composable.

Composable: auch das Backend wird zerlegt

Composable wendet dieselbe Idee auf das Backend an. Die Suche kommt aus einem spezialisierten Dienst, Produktdaten aus einem PIM, Inhalte aus einem Headless CMS und Transaktionen aus einer Commerce Engine. Eine Integrationsschicht und das Frontend führen alles zusammen. Weil Composable eigene Frontends voraussetzt, ist jede composable Architektur in der Praxis auch headless. Umgekehrt gilt das nicht: Headless ist ein Teil von Composable, aber nicht dasselbe.

Die Übergänge sind fließend

Kaum ein Shop ist vollständig das eine oder das andere. Ein Händler setzt ein Next.js-Frontend vor eine Commerce-Suite und ist damit headless. Ersetzt er später die mitgelieferte Suche durch einen Spezialdienst und bezieht Produktdaten aus einem PIM, wird er in zwei Fähigkeiten composable, während Warenkorb und Checkout im Kern bleiben.

Anbieter greifen genau diese Mischform auf. HCL Software nennt sein Angebot „Integrated Composable Commerce“ und meint damit einen integrierten Kern, der sich um modulare Bausteine ergänzen lässt. Shopify bietet großen Händlern unter dem Namen Commerce Components einzelne Teile wie Checkout und Warenkorb auch getrennt vom übrigen Shop an. Solche Begriffe beschreiben kein eigenes Architekturmodell, sondern einen Standort auf der Skala zwischen Suite und vollständig zerlegter Plattform.

Die bessere Frage an deinen Shop

Hilfreicher als „Sind wir composable?“ ist die Frage, an welcher Stelle eine Trennung einen konkreten Engpass in deinem Shop lösen würde. Wie du das systematisch herausfindest, zeigt der letzte Abschnitt dieses Ratgebers in fünf Schritten.

Wo von Composable Commerce die Rede ist, fällt fast immer das Kürzel MACH. Es steht für Microservices-based, API-first, Cloud-native SaaS und Headless. Geprägt hat es die MACH Alliance, ein herstellerneutraler Verband, der sich im Juni 2020 gegründet hat. Zu den Gründungsmitgliedern gehören unter anderem commercetools, Contentstack und Amplience. Die vier Begriffe beschreiben, welche Eigenschaften Software haben sollte, damit sie sich gut zusammensetzen und austauschen lässt.

Microservices-based: unabhängig betreibbare Teile

Die Software besteht aus Diensten, die sich getrennt aktualisieren und skalieren lassen. Für dich als Käufer ist nicht entscheidend, wie viele Microservices ein Anbieter intern betreibt, sondern ob sich die Fähigkeit, die du nutzt, unabhängig von anderen verändern lässt. Müssen mehrere Dienste immer gemeinsam veröffentlicht werden, sind sie praktisch eng gekoppelt.

API-first: Schnittstellen sind das Produkt

Funktionen werden von Anfang an über dokumentierte Schnittstellen angeboten, nicht nachträglich vor eine fertige Oberfläche gesetzt. Dazu gehören Versionierung, Authentifizierung, Limits, Webhooks oder Ereignisse und ein verlässlicher Umgang mit Änderungen, die bestehende Integrationen brechen würden.

Cloud-native SaaS: Der Anbieter betreibt die Plattform

Der Anbieter hostet die Software, spielt Updates ein und skaliert die Infrastruktur. Das nimmt dir den Serverbetrieb ab, schafft aber neue Abhängigkeiten: Verfügbarkeit, API-Limits, Datenstandorte und Vertragsbedingungen werden Teil deiner Architektur.

Headless: Oberfläche und Logik getrennt

Jeder Baustein liefert Daten und Funktionen, aber keine fest verdrahtete Oberfläche. Damit mehrere Kanäle trotzdem einheitlich wirken, brauchst du ein gemeinsames Designsystem und klare Regeln dafür, wo Geschäftslogik liegt. Bei mehreren Marken oder Ländern lohnt es sich, diese Regeln schon vor dem ersten Frontend schriftlich festzulegen.

MACH und Composable sind nicht dasselbe

Composable ist das Ziel: eine Plattform aus austauschbaren Fähigkeiten. MACH beschreibt Eigenschaften, die dieses Ziel erleichtern. Du kannst schrittweise composable werden, ohne dass jeder Baustein alle vier Prinzipien erfüllt. Eine selbst gehostete Open-Source-Commerce-Engine ist zum Beispiel kein SaaS, kann aber trotzdem sauber über APIs in eine composable Architektur passen.

Übersetze MACH deshalb in prüfbare Fragen an jeden Anbieter:

• Wie läuft eine Versionsänderung der API ab, und wie lange bleibt die alte Version erreichbar?
• Kannst du alle eigenen Daten vollständig und automatisiert exportieren?
• Gibt es Webhooks oder Ereignisse, wenn sich Daten ändern?
• Gibt es getrennte Umgebungen zum Testen, und wie funktioniert ein Rollback?

Die Antworten zeigen dir, ob sich ein Baustein im Alltag wirklich getrennt betreiben lässt oder ob jede Änderung ein gemeinsames Projekt mit dem Anbieter wird.

Eine Composable-Architektur setzt sich aus Bausteinen mit klaren Rollen zusammen. Welche du brauchst, ergibt sich aus deinen Prozessen, nicht aus einer Musterarchitektur. Die Übersicht zeigt die häufigsten Rollen mit bekannten Beispielen. Die Beispiele dienen der Orientierung und sind keine Empfehlung.

• Commerce Engine: Katalog, Warenkorb, Preise, Promotions und Bestellungen, etwa commercetools als SaaS oder Medusa als Open-Source-Engine.
• Frontend: die eigene Storefront, oft mit Next.js gebaut, bei Shopify auch mit Hydrogen.
• Headless CMS: Landingpages, Ratgeber und Markeninhalte, zum Beispiel mit Contentful, Storyblok oder Sanity.
• PIM: die führende Quelle für Produktdaten, Attribute und Übersetzungen.
• Suche: Relevanz, Filter und Merchandising, etwa mit Algolia.
• Zahlung: Payment-Anbieter, meist über die Commerce Engine angebunden.
• ERP und Warenwirtschaft: Bestand, Rechnungen und Versand.
• Integrationsschicht: verbindet die Bausteine über APIs und Ereignisse.

Medusa ist ein gutes Beispiel dafür, dass eine Commerce Engine nicht zwingend SaaS sein muss. Was die Engine kann und für welche Shops sie passt, steht im Ratgeber zu Medusa als Shop-Backend.

Datenhoheit zuerst festlegen

Bevor du Anbieter vergleichst, klärst du für jede Datenart, welches System sie führt. Produktdaten führt das PIM, Bestand das ERP, Preise die Commerce Engine und Inhalte das CMS. Alle anderen Systeme lesen nur oder reichern an. Wie ein PIM diese Rolle übernimmt, beschreibt der Ratgeber zum PIM-System. Wie Bestand und Bestellungen zwischen Shop und Warenwirtschaft fließen, erklären wir im Beitrag zur ERP-Schnittstelle für Shopify. Ohne klare Datenhoheit verwalten zwei Systeme denselben Wert, und niemand weiß, welcher stimmt.

Fähigkeiten an deinen schwierigsten Fällen prüfen

Eine Suche bewertest du an deinem Katalog: Größe, Sprachen, Fachbegriffe, Filterlogik und die Frage, wer die Ergebnisse steuern soll. Ein CMS bewertest du an deinem Content-Modell und an den Freigaben deines Marketings, eine Commerce Engine an deinen Preis- und Rabattregeln, an B2B-Konditionen oder Abonnements. Lass dir die zwei oder drei schwierigsten Fälle deines Geschäfts zeigen, nicht die Standarddemo.

Bewusst gekoppelte Bereiche einzeichnen

Nicht jede Fähigkeit braucht ein eigenes Produkt. Katalog, Warenkorb und Bestellung bleiben oft gemeinsam in der Commerce Engine, weil sie eng zusammenarbeiten und sich im gleichen Takt ändern. Markiere in deinem Zielbild neben den Trennkandidaten auch diese bewusst gekoppelten Bereiche. So löst nicht jede neue Anforderung reflexhaft einen weiteren Dienst aus.

Das Frontend bündelt, aber es rechnet nicht

Frontend und Backend-for-Frontend fügen Daten zu Seiten zusammen. Preisberechnung, Rabattregeln und Bestelllogik bleiben im zuständigen Baustein. Fängt das Frontend an, Preise selbst zu berechnen, entsteht ein neuer Monolith, diesmal verteilt über mehrere Systeme.

Die Vorteile von Composable Commerce entstehen aus der Entkopplung, die Nachteile ebenfalls. Jede Grenze zwischen zwei Bausteinen gibt dir Freiheit und kostet dich eine Schnittstelle, die gebaut, getestet und dauerhaft betrieben werden muss.

Die Vorteile

• Gezielter Austausch: Du ersetzt eine schwache Fähigkeit wie die Suche, ohne den ganzen Shop neu aufzubauen.
• Spezialisierte Lösungen: Wo du dich vom Wettbewerb abhebst, setzt du einen Baustein ein, der genau diese Aufgabe sehr gut löst.
• Unabhängige Teams: Wer für Content, Suche oder Checkout zuständig ist, veröffentlicht im eigenen Takt.
• Mehrere Marken und Kanäle: Ein gemeinsamer Kern versorgt verschiedene Frontends, Länder oder Portale.
• Schrittweise Modernisierung: Du löst ein Altsystem Fähigkeit für Fähigkeit ab statt in einem einzigen Großprojekt.
• Gezielte Skalierung: Stark belastete Bausteine wie Suche oder Checkout lassen sich getrennt skalieren.

Die Nachteile

• Integrationsaufwand: Was eine Suite mitliefert, verbindest du selbst. Die Integrationsschicht wird ein eigenes Produkt.
• Mehr Verträge und Anbieter: Jeder Baustein bringt eigene Limits, Roadmaps, Preislogik und Supportwege mit.
• Fehlersuche über Grenzen: Ein Fehler kann in jedem Baustein oder in jeder Schnittstelle dazwischen entstehen, und oft müssen mehrere Anbieter gemeinsam suchen.
• Höhere Anforderungen ans Team: Du brauchst Architekturverantwortung, Entwicklung und Betrieb, nicht nur Shop-Pflege.
• Weniger Fertiges: App-Marktplätze und Plugins einer Suite fallen weg oder müssen angepasst werden.
• Längere Einführung: Bis der erste Kaufweg über alle Bausteine stabil läuft, braucht es Auswahl, Integration und Tests, die eine Suite schon mitbringt.

Warum die Abhängigkeit von Anbietern nicht verschwindet

Composable wird oft als Ausweg aus dem Vendor-Lock-in beschrieben. Tatsächlich verschiebt sich die Abhängigkeit nur. Dein Frontend, deine Datenflüsse und deine Prozesse passen sich an die Besonderheiten jedes Bausteins an, und ein Wechsel bleibt ein Projekt. Was Composable dir gibt, ist die Möglichkeit, einen Teil zu wechseln, ohne alle anderen mitzunehmen. Das ist wertvoll, erspart dir aber nicht die sorgfältige Auswahl jedes Bausteins.

Was das für Kosten und Team bedeutet

Lizenzen pro Baustein sind nur ein Teil der Rechnung. Hinzu kommen Integration, Migration, Tests, Monitoring, die Steuerung mehrerer Anbieter und die laufende Pflege der Schnittstellen. Eine Suite kann in der Summe deutlich weniger Aufwand verursachen, obwohl ihre Lizenz auf den ersten Blick teurer wirkt. Rechne deshalb pro Fähigkeit: Welchen Geschäftsvorteil bringt die Trennung, und welcher Aufwand entsteht dafür dauerhaft? Erst wenn du beide Seiten für die Kandidaten aus deiner Fähigkeitenkarte beschrieben hast, lohnt sich ein Gespräch über konkrete Anbieter.

Was sich im Arbeitsalltag der Fachteams ändert

Composable verändert nicht nur die Technik, sondern auch die tägliche Arbeit. Redaktion und Marketing pflegen Inhalte im CMS, Produktdaten im PIM und Aktionen in der Commerce Engine, also in mehreren Oberflächen statt in einer Verwaltung. Damit das nicht zur Suche nach dem richtigen System wird, braucht jedes Team eine klare Zuordnung: welche Aufgabe in welchem Werkzeug erledigt wird, wie eine Vorschau vor der Veröffentlichung funktioniert und wer bei Fragen hilft. Plane diese Einarbeitung von Anfang an mit ein.

Composable Commerce ist keine Reifestufe, die jeder Shop erreichen muss. Der Ansatz lohnt sich, wenn konkrete Anforderungen mit einer Suite dauerhaft schwer lösbar sind und du die zusätzliche Verantwortung tragen kannst. Beide Bedingungen müssen erfüllt sein.

Signale für Composable

• Mehrere Marken, Länder oder Kanäle teilen sich Katalog und Bestellungen, brauchen aber eigene Frontends und Inhalte.
• Dein Kaufprozess ist besonders: Produktkonfiguration, B2B-Konditionen, Abonnements oder eine enge Verzahnung von Laden und Onlineshop.
• Einzelne Fähigkeiten ändern sich deutlich schneller als der Rest, etwa Content und Suche gegenüber Checkout und Auftragslogik.
• Deine heutige Plattform stößt an einer klar benennbaren Stelle an Grenzen, während der Rest gut funktioniert.

Wann Headless reicht

Passt dein Backend fachlich und braucht vor allem die Oberfläche mehr Freiheit, ist Headless der kleinere Schritt. Typisch ist ein Shop, der ein besonderes Markenerlebnis, eine App oder sehr schnelle Seiten will, dessen Katalog, Preise und Bestellungen im Standard aber gut aufgehoben sind. Du übernimmst dann die Verantwortung für ein Frontend, nicht für ein ganzes Netz aus Bausteinen.

Wann eine Suite die bessere Architektur ist

Ein Shop mit Standardkatalog, einem Markt und üblichen Zahlungs- und Versandprozessen fährt meist besser mit einer gut eingerichteten Suite. Erweiterungen werden dort konfiguriert statt entwickelt, Updates kommen abgestimmt, und ein kleines Team kann den Betrieb tragen. Das ist oft die stärkere Entscheidung. Steht ohnehin ein Plattformwechsel an, hilft dir der Ratgeber zum Relaunch eines Onlineshops, Anlass und Umfang sauber zu klären.

Team und Skills: Was du für Composable brauchst

Composable braucht kein großes Team, aber klare Verantwortung. Diese Rollen müssen besetzt sein, intern oder bei einem Partner:

• Architektur: jemand, der das Gesamtbild und die Grenzen zwischen den Bausteinen verantwortet.
• Entwicklung: Erfahrung mit APIs, Frontend-Frameworks und Datenflüssen zwischen Systemen.
• Betrieb: Monitoring, Deployment und Störungsbehandlung über Anbietergrenzen hinweg.
• Produktverantwortung: jemand, der fachliche Prioritäten setzt und entscheidet, was als Nächstes getrennt wird.

Landen all diese Aufgaben bei einer einzigen Person, wächst das Risiko mit jedem weiteren Baustein. Auch die Organisation muss mitziehen: Braucht jede Änderung an der Suche Freigaben aus mehreren Abteilungen, bringt technische Modularität keine Geschwindigkeit. Teamgrenzen sollten den Fähigkeiten folgen, die du trennst.

Für den Weg von einer Suite zu Composable gibt es zwei Grundmuster. Beim Big Bang ersetzt du das alte System an einem Stichtag vollständig. Beim Strangler-Fig-Muster, das der Softwarearchitekt Martin Fowler nach der Würgefeige benannt hat, wächst die neue Architektur schrittweise um das Altsystem herum, bis es keine Aufgaben mehr hat und abgeschaltet wird.

Warum der Big Bang selten die richtige Wahl ist

Ein Komplettwechsel bündelt alle Risiken auf einen Termin: Datenmigration, neue Prozesse, neue Integrationen und neues Frontend gehen gleichzeitig live. Läuft etwas schief, betrifft es den gesamten Verkauf. Außerdem lieferst du lange keinen Nutzen, weil erst am Ende alles zusammen fertig ist. Sinnvoll ist ein Big Bang vor allem, wenn das Altsystem kaum Schnittstellen bietet, nicht mehr gewartet wird oder der Funktionsumfang klein ist.

So läuft eine Strangler-Fig-Migration ab

Du beginnst mit einem klar abgegrenzten Bereich, der einen echten Engpass löst, zum Beispiel Content, Suche oder Produktdaten. Eine Fassade oder API-Schicht vor dem Frontend entscheidet, welche Anfragen schon an den neuen Baustein gehen und welche noch an das Altsystem. Ist der neue Baustein stabil und vollständig übernommen, schaltest du die alte Funktion ab. Dann folgt die nächste Fähigkeit.

Die Reihenfolge folgt den Abhängigkeiten. Ein neues Frontend vor ungeklärten Produkt- und Preisquellen erzeugt viel Übergangslogik. Oft ist es klüger, zuerst die Datenhoheit für Produkte zu klären und danach die Oberfläche zu tauschen.

Daten migrieren, ohne zwei Wahrheiten zu erzeugen

Vor jedem Schritt legst du fest, welches System künftig welche Daten führt. Übergangsweise Synchronisation läuft in genau eine Richtung. Schreiben zwei Systeme ohne Konfliktregeln gleichzeitig in dieselben Daten, entstehen Abweichungen, die sich kaum zurückverfolgen lassen. Bestände, Kundenkonten und offene Bestellungen gleichst du vor und nach jedem Schritt ab.

Was vor jedem Schritt getestet wird

Funktionsgleichheit allein reicht nicht. Teste zusätzlich Performance, Fehlerverhalten, Monitoring und Sicherheit. Vertragstests sichern die Schnittstellen ab, End-to-End-Tests die wichtigsten Kaufwege von der Suche bis zur Bestellbestätigung. Für jeden Schritt planst du einen Rückweg und einen Datenabgleich ein.

Übergangslösungen bekommen ein Ablaufdatum

Adapter und doppelte Synchronisation sind während der Migration normal. Für jedes Provisorium dokumentierst du, wem es gehört, wofür es da ist und wann es entfernt wird. Sonst wird die Übergangsschicht zur dauerhaften Plattform, und jeder weitere Schritt wird aufwendiger. Fortschritt misst du daran, wie viel das Altsystem nicht mehr tun muss, nicht daran, wie viele neue Dienste daneben laufen.

Ändern sich bei der Migration URLs, Templates oder die Seitenstruktur, sind auch deine Rankings betroffen. Wie du sie absicherst, beschreibt der Ratgeber zum Relaunch ohne Rankingverlust.

Eine Produktseite in einer Composable-Architektur kombiniert Produktdaten aus dem PIM, Preise aus der Commerce Engine, Inhalte aus dem CMS und Ergebnisse aus der Suche. Deine Kundschaft erwartet trotzdem eine schnelle, stimmige Seite. Die Integrationsschicht ist deshalb der Teil, der aus einzelnen Bausteinen einen Kaufprozess macht.

Synchrone Aufrufe und Ereignisse richtig einsetzen

Eine synchrone API-Anfrage liefert sofort eine Antwort, etwa den aktuellen Preis im Checkout. Sie macht deine Seite von Antwortzeit und Verfügbarkeit des Bausteins abhängig. Ereignisse verteilen Änderungen zeitversetzt, zum Beispiel wenn ein Produkt freigegeben oder eine Bestellung angelegt wurde. Sie entkoppeln Systeme, brauchen aber Regeln für Reihenfolge, Wiederholung und Fehler. Wie du solche Verbindungen sauber planen und bauen lässt, beschreibt der Ratgeber zum Programmieren von Schnittstellen.

Aktualität pro Information festlegen

Ein Produkttext darf einige Minuten verzögert erscheinen, ein bestätigter Preis im Checkout nicht. Lege für jeden Datenfluss fest, wie aktuell er sein muss. Daraus ergibt sich, ob ein Cache genügt, ein Ereignis reicht oder ein Live-Aufruf nötig ist. Ohne diese Vorgabe baust du entweder unnötige Echtzeitkomplexität oder zeigst an kritischen Stellen veraltete Werte an.

Ausfälle von Anfang an einplanen

Fällt der Empfehlungsdienst aus, funktioniert die Produktseite ohne Empfehlungen weiter. Fallen Preis oder Checkout aus, braucht es eine andere Reaktion. Lege für jeden Baustein fest, ob er kritisch ist, was bei einem Ausfall angezeigt wird und wer reagiert. Die Serviceziele richten sich nach der Wirkung auf den Kauf: Checkout und Bestellannahme brauchen eine andere Absicherung als redaktionelle Vorschauen.

Betrieb über Anbietergrenzen hinweg

Mit mehreren SaaS-Diensten kommen mehrere Roadmaps, Wartungsfenster, Limits und Vertragsänderungen. Ein Verzeichnis der Bausteine hält fest, wem jeder gehört, welche Daten er führt, welche Schnittstellen er anbietet und wie der Eskalationsweg aussieht. Gemeinsames Tracing verfolgt eine Anfrage über alle Bausteine hinweg. So erkennst du, ob eine langsame Seite am Frontend, an der Suche oder an einem Drittanbieter liegt.

Identität, Einwilligung und Sicherheit zentral regeln

Kundenkonto, Login, Einwilligungen und Zugriffsrechte betreffen jeden Baustein. Regelt das jedes System für sich, entstehen unterschiedliche Sicherheitsniveaus und widersprüchliche Einwilligungsstände. Lege deshalb einen führenden Dienst für Identität fest, verwalte Zugangsdaten zu den Bausteinen an einer Stelle und gib jedem System nur die Rechte, die es für seine Aufgabe braucht. Auch Tracking und Einwilligungen gehören in eine gemeinsame Lösung, damit jede Oberfläche dieselben Regeln anwendet.

Regelmäßig prüfen, ob die Trennung noch trägt

Miss, ob die Modularität wirklich hilft: wie oft Teams unabhängig veröffentlichen, wie lange eine Änderung bis zum Livegang braucht und wie schnell sich der Shop von Fehlern erholt. Ein Baustein, der kaum Vorteil bringt, aber viel Integrationsaufwand verursacht, darf auch wieder in den Kern zurückwandern. Zur Wahlfreiheit von Composable gehört auch, eine Trennung wieder zurückzunehmen.

Die Entscheidung zwischen Suite, Headless und Composable beginnt nicht mit einem Anbietervergleich. Sie beginnt mit der Frage, welche Teile deines Geschäfts sich unabhängig verändern müssen und welche Verantwortung du dauerhaft tragen kannst. Die folgenden fünf Schritte führen von dort zu einem belastbaren Zielbild.

1. Fähigkeiten kartieren

Liste die wichtigsten Commerce-Fähigkeiten auf: Katalog, Produktdaten, Content, Suche, Preise und Promotions, Warenkorb und Checkout, Bestellungen und Kundenkonto. Bewerte jede nach strategischer Bedeutung, heutiger Qualität und erwartetem Veränderungsbedarf. Differenzierende Bereiche mit hohem Veränderungsdruck sind Trennkandidaten, stabile Standardfunktionen bleiben im Kern.

2. Den Engpass benennen

Formuliere, woran die heutige Plattform konkret scheitert. „Unsere Suche findet bei Fachbegriffen keine passenden Produkte“ ist ein Engpass, „Wir wollen moderner werden“ ist keiner. Lässt sich kein Engpass im Backend benennen, spricht das für Headless oder eine gut eingerichtete Suite.

3. Datenhoheit und Schnittstellen festlegen

Für jede Datenart bestimmst du das führende System und die Richtung der Datenflüsse. Für die Trennkandidaten beschreibst du, welche Schnittstellen sie anbieten müssen und welche Aktualität und Verfügbarkeit dein Kaufprozess von ihnen verlangt.

4. Einen vertikalen Schnitt testen

Ein Prototyp sollte nicht nur eine API aufrufen, sondern einen kleinen, vollständigen Kundenablauf liefern: Datenquelle, Oberfläche, Fehlerfall, Deployment und Monitoring. So siehst du früh, wie viel Plattformarbeit tatsächlich entsteht. Im besten Fall ist der Prototyp schon der erste nutzbare Baustein.

5. Roadmap und Grenzen schriftlich festhalten

Halte fest, welche Fähigkeiten in welcher Reihenfolge folgen, welche bewusst im Kern bleiben und welche Alternativen du mit welcher Begründung verworfen hast. Ändern sich später die Anforderungen, prüft das Team genau diese Annahmen neu, statt die ganze Architektur infrage zu stellen. Die Unterlagen aus den fünf Schritten sind zugleich die Grundlage für ein Briefing. Worauf es dabei ankommt, zeigt der Ratgeber zum Briefing für eine Onlineshop-Agentur.

Wie die Architekturfrage ins Projekt kommt

In einem Shop-Projekt gehört die Wahl zwischen Suite, Headless und Composable an den Anfang, vor die Auswahl von Anbietern und vor das Design. So gehen wir auch vor, wenn wir deinen Shop neu aufbauen: Zuerst stehen Fähigkeiten, Engpässe und Betriebsfähigkeit fest, dann die Bausteine.

Das Ergebnis ist eine Architektur, die zu deinem Geschäft und deinem Team passt. Suite, Headless-Frontend und spezialisierte Bausteine können darin nebeneinander bestehen, solange ihre Rollen und Schnittstellen eindeutig sind.