Composable Commerce – modulare Shop-Architektur als lesbare Datenquelle

Composable Commerce: Wenn der Kunde nicht mehr klickt, sondern fragt

Jemand sucht 250-Gramm-Beutel für Röstkaffee, aromadicht, in kleiner Auflage. Vor drei Jahren hätte er drei Shops geöffnet und verglichen. Heute schildert er seine Lage einer KI und bekommt drei Namen genannt.

Ob dein Shop unter diesen drei Namen ist, entscheidet sich nicht mehr an deiner Startseite. Es entscheidet sich daran, ob deine Daten überhaupt lesbar sind.

Martin Kalinowski
2. Mai 2024
7 Min. Lesezeit
Aktualisiert: 22. August 2026

Über Composable Commerce ist in den letzten Jahren viel geschrieben worden, und fast alles davon aus derselben Richtung. Der Händler steht im Mittelpunkt, und das Versprechen lautet: Du kannst schneller umbauen. Tausch das Checkout-Modul, häng ein neues Zahlungsverfahren dran, ersetz das Content-System, ohne dass der Shop dabei stillsteht. Flexibilität, gemessen an der Geschwindigkeit deiner eigenen Änderungen.

Das Versprechen stimmt. Es ist nur nicht mehr die interessante Hälfte.

Denn während über Umbaugeschwindigkeit geredet wurde, hat sich verändert, wer überhaupt noch auf einen Shop schaut. Und diese Verschiebung stellt an eine modulare Architektur eine Frage, für die sie nie beworben wurde.

Was Composable Commerce lösen sollte

Der Ausgangspunkt war ein echtes Problem. Ein klassisches Shopsystem ist ein Block: Warenkorb, Katalog, Checkout, Inhalte, Suche — alles in einem Programm, alles voneinander abhängig. Wer das Zahlungsverfahren wechseln will, fasst ein System an, das gleichzeitig die Produktseiten ausliefert. Jede Änderung wird zum Eingriff am offenen Herzen.

Composable Commerce zerlegt diesen Block in austauschbare Bausteine, die über Schnittstellen miteinander sprechen. Die Grundlage dafür ist der Headless-Ansatz: Das Frontend — die Oberfläche, die Menschen sehen — wird vom Backend getrennt, also von den Daten und Abläufen dahinter. Verbunden sind beide über APIs.

Kurz erklärt

Headless und API

Headless heißt: Der Shop hat keinen fest angewachsenen Kopf. Die Oberfläche ist ein eigenes Programm, das sich die Daten holt, statt Teil des Systems zu sein, das sie verwaltet.

Eine API ist die Stelle, an der es sie sich holt — eine definierte Schnittstelle, über die Software Daten anfordert und zurückbekommt. Nicht als fertige Seite, sondern als Rohdaten: Artikelnummer, Preis, Bestand, Eigenschaften.

Der Unterschied klingt technisch und ist es auch. Er entscheidet aber darüber, ob außer einem Browser noch etwas anderes deinen Shop lesen kann.

Aus dieser Trennung ergaben sich die bekannten Vorteile. Module lassen sich einzeln austauschen. Man skaliert dort, wo Last entsteht, statt überall. Eine neue Verkaufsfläche — App, Marktplatz, Filialterminal — bekommt dieselben Daten, ohne dass sie doppelt gepflegt werden müssen.

Alles richtig. Alles vom Händler aus gedacht.

Die Prüfung kommt von der anderen Seite

Ein Shop war zwanzig Jahre lang ein Ort. Jemand kam an, sah sich um, verglich, legte in den Warenkorb. Alles, was ein Shopsystem tut, ist auf diesen Besuch hin gebaut: Navigation, Filter, Produktbilder, Bewertungen, Vertrauenssignale an der Kasse. Die Oberfläche ist das Produkt.

Genau dieser Besuch fällt zunehmend aus. Nicht, weil niemand mehr kauft, sondern weil der Vergleich woanders stattfindet. Wer seine Anforderung einer KI schildert, bekommt eine Empfehlung, keine Ergebnisliste. Er landet, wenn überhaupt, erst auf der Seite, wenn die Entscheidung im Wesentlichen gefallen ist.

Wo vorher jemand kam, um zu schauen, kommt jetzt jemand, um abzuholen — wenn er überhaupt kommt.

Damit verschiebt sich, woran ein Shop gemessen wird. Nicht mehr allein daran, wie gut er sich bedienen lässt, sondern daran, ob er als Quelle taugt. Ob das, was er über seine Produkte weiß, in einer Form vorliegt, die eine Maschine aufnehmen kann: vollständig, eindeutig, aktuell.

Und das ist der Punkt, an dem eine modulare Architektur plötzlich etwas beweist, wofür sie nicht gebaut wurde.

Wer antwortet, wenn niemand mehr blättert

Ein monolithischer Shop kennt seine Daten sehr gut — aber er gibt sie nur in einer Form heraus: als fertig gebaute Seite für einen Menschen. Preis, Bestand und Eigenschaften stecken in einem Layout, umgeben von Navigation, Bannern und Zustimmungsdialogen. Wer sie herausholen will, muss sie aus dem Text klauben.

Ein Headless-Aufbau hat diese Trennung bereits vollzogen. Die Schnittstelle, die das eigene Frontend beliefert, kann im Prinzip jeden beliefern — eine App, einen Marktplatz, ein Vergleichsportal, und eben auch ein System, das im Auftrag eines Kunden recherchiert. Die Daten liegen ohnehin schon getrennt von ihrer Darstellung vor.

Das ist keine neue Funktion. Es ist derselbe Aufbau, betrachtet aus einer Richtung, aus der ihn bisher kaum jemand betrachtet hat. Composable Commerce wurde als Antwort auf die Frage verkauft, wie schnell du umbauen kannst. Die Frage, die jetzt zählt, lautet, wie gut du ausgelesen werden kannst.

Wer diese zweite Frage einmal ernst nimmt, sieht seinen Shop anders. Ein Produktdatensatz ist dann keine Zulieferung für eine hübsche Seite mehr, sondern das eigentliche Erzeugnis.

Lösung

E-Commerce Agentur Freiburg

Der Shop endet nicht am Bildschirm.

Onlineshops samt der Schnittstelle zum ERP, an der die meisten Projekte scheitern. Bestände, Preise und Aufträge stimmen in allen Systemen.

Shop und System verbinden

Der unbequeme Teil: die meisten brauchen kein Composable

Hier muss ich gegen meine eigene Argumentation arbeiten, sonst wird sie unehrlich.

Aus allem oben folgt nicht, dass ein mittelständischer Händler jetzt seinen Shop zerlegen sollte. Eine modulare Architektur ist teuer. Sie braucht Menschen, die sie betreiben — nicht einmalig zum Aufbau, sondern dauerhaft. Sie verlagert Komplexität aus dem Shopsystem in den Raum zwischen den Bausteinen, und dieser Raum gehört niemandem, solange man ihn nicht jemandem zuweist. Wenn drei Module sich über einen Lagerbestand uneinig sind, meldet das kein System. Das merkt der Kunde.

Für die allermeisten Betriebe, mit denen wir arbeiten, lautet die ehrliche Antwort deshalb: Du brauchst kein Composable Commerce. Du brauchst deine Produktdaten in Ordnung.

Das ist der unglamouröse Teil derselben Sache. Ob ein Preis in der Warenwirtschaft und im Shop übereinstimmt. Ob ein Bestand stimmt oder eine halbe Stunde alt ist. Ob eine Artikeleigenschaft überall gleich heißt oder in drei Systemen drei Namen trägt. Ob ein Artikel, den es nicht mehr gibt, wirklich verschwindet oder nur unsichtbar wird.

Diese Fragen entscheiden darüber, ob eine Maschine deine Daten brauchen kann — und sie entscheiden es vorher und gründlicher als jede Architekturwahl. Ein sauber gepflegter Standard-Shop mit einer funktionierenden Verbindung zur Warenwirtschaft ist als Quelle wertvoller als ein modulares System, in dem drei Bausteine unterschiedliche Wahrheiten erzählen.

Was zuerst dran ist

Die Stelle, an der es in der Praxis reißt, ist fast immer dieselbe: die Verbindung zwischen Shop und Warenwirtschaft. Dort treffen zwei Systeme aufeinander, die von verschiedenen Leuten zu verschiedenen Zeiten für verschiedene Zwecke eingerichtet wurden, und dazwischen liegt in erstaunlich vielen Betrieben eine Tabelle, die jemand von Hand pflegt.

Solange das so ist, ist jede Architekturdebatte verfrüht. Nicht, weil sie falsch wäre, sondern weil sie ein Problem löst, das noch gar nicht dran ist.

Die brauchbare Reihenfolge ist unspektakulär. Erst dafür sorgen, dass die Daten an einer Stelle entstehen und überall dieselben sind. Dann prüfen, ob sie außerhalb des eigenen Frontends überhaupt abrufbar sind. Und erst dann, wenn beides steht und tatsächlich an Grenzen stößt, über Module reden.

Was die Anbieter sagen — und was nicht

Der Markt für modulare Commerce-Bausteine ist gut besetzt. commercetools gilt als einer der Pioniere des API-First-Ansatzes, BigCommerce und Shopify Plus bieten headless-fähige Schnittstellen zu etablierten Systemen, Shopware bedient den Mittelstand.

Was diese Anbieter erklären, ist durchweg richtig und meist gut erklärt. Was sie nicht erklären, liegt in der Natur der Sache: Keiner von ihnen hat ein Interesse daran, dir zu sagen, dass dein eigentliches Problem in der Datenpflege liegt und mit einem Plattformwechsel nicht verschwindet. Das ist kein Vorwurf. Es ist der Grund, warum die Entscheidung nicht anhand von Herstellermaterial fallen sollte.

Wenn der Kunde nicht mehr selbst klickt

Eine Entwicklung steht noch aus, und ich beschreibe sie mit Absicht vorsichtig, weil belastbare Zahlen dazu fehlen: Systeme, die nicht nur recherchieren, sondern auch bestellen. Für diesen Fall wird die Oberfläche eines Shops endgültig zur Nebensache, und alles hängt daran, ob Verfügbarkeit, Preis, Versandbedingungen und Rückgabe maschinell abrufbar sind.

Ob und wie schnell das kommt, weiß heute niemand seriös. Bemerkenswert ist etwas anderes: Die Vorbereitung darauf ist dieselbe Arbeit, die sich auch ohne diese Entwicklung lohnt. Saubere Daten, eine funktionierende Schnittstelle zur Warenwirtschaft, eindeutige Eigenschaften. Wer das tut, verbessert seinen Shop heute und ist für einen Fall gerüstet, der vielleicht kommt.

Das ist selten. Die meisten Wetten auf eine technische Zukunft kosten etwas, wenn die Zukunft ausbleibt. Diese hier nicht.

Der Shop als Quelle

Composable Commerce ist keine Antwort auf die Frage, ob man modern ist. Es ist eine Bauform, die für bestimmte Größen und bestimmte Probleme richtig ist und für andere ein teurer Umweg.

Was sich verändert hat, ist nicht die Bauform. Es ist der Betrachter. Zwanzig Jahre lang war die einzige Frage, wie ein Mensch mit deinem Shop zurechtkommt. Jetzt kommt eine zweite dazu, und sie interessiert sich nicht für Gestaltung: Was weiß dieses System über seine Produkte, und gibt es das heraus?

Die zweite Frage lässt sich beantworten, ohne einen einzigen Baustein auszutauschen. Man muss sie nur stellen.

Häufig gestellte Fragen

Was ist Composable Commerce in einem Satz?

Ein Shopsystem, das nicht als ein Block läuft, sondern aus austauschbaren Bausteinen besteht, die über Schnittstellen miteinander sprechen — Katalog, Warenkorb, Checkout und Inhalte lassen sich einzeln ersetzen, ohne dass der Rest stillsteht.

Was ist der Unterschied zwischen Composable und Headless?

Headless beschreibt nur die Trennung von Oberfläche und Backend. Composable geht weiter: Auch das Backend selbst besteht aus einzeln austauschbaren Diensten. Headless ist die Voraussetzung, Composable die Konsequenz daraus.

Lohnt sich Composable Commerce für einen mittelständischen Händler?

Meistens nicht, und das ist die ehrliche Antwort. Der Aufbau ist teuer und braucht dauerhaft Menschen, die ihn betreiben. Vorher lohnt sich fast immer etwas anderes: dafür zu sorgen, dass Preise, Bestände und Artikeleigenschaften zwischen Shop und Warenwirtschaft zuverlässig übereinstimmen.

Was hat Composable Commerce mit KI-Suche zu tun?

Wenn Kaufentscheidungen in einer KI-Antwort vorbereitet werden, wird ein Shop weniger als Oberfläche und mehr als Datenquelle gelesen. Ein System, das seine Daten ohnehin getrennt von der Darstellung bereitstellt, ist dafür besser aufgestellt als eines, in dem alles im Seitenlayout steckt.

Womit fängt man an, wenn der Shop maschinenlesbar werden soll?

Mit der Verbindung zwischen Shop und Warenwirtschaft. Solange Bestände oder Preise über eine von Hand gepflegte Tabelle laufen, hilft keine Architektur — dann sind die Daten uneinheitlich, und uneinheitliche Daten verwendet kein System zuverlässig.