Composable Commerce ist einer dieser Begriffe die in Konferenzen ständig fallen und danach wirkt es irgendwie klar. Bis man versucht es umzusetzen. Dann merkt man: Es ist komplex und teuer. Und ob es überhaupt Sinn macht, ist eine ganz andere Frage.
Wir setzen seit Jahren Composable-Architekturen um. Mit commercetools, Storyblok, Algolia, individuellen Frontends. Das macht Sinn in bestimmten Fällen. In 90% der Shops nicht.
Hier ist was du wirklich über Composable Commerce wissen musst. Und vor allem: wann es nicht die richtige Wahl ist.
Inhalt
- Was ist Composable Commerce wirklich?
- Was bedeutet MACH? Die vier Säulen
- Composable vs. Monolith vs. Headless: Die Unterschiede
- Ein typischer Composable-Stack
- Wann Composable Commerce Sinn macht
- Wann es zu viel ist
- Die TCO-Realität: Initial teurer, später günstiger
- Fazit: Für die meisten Shops falsche Wahl
Was ist Composable Commerce wirklich?
Composable Commerce bedeutet: Du setzt deine Architektur aus einzelnen Best-of-Breed-Tools zusammen. Nicht eine Plattform die alles macht. Sondern: Das beste E-Commerce-Backend, die beste Content-Plattform, die beste Such-Engine, dein eigenes Frontend.
Das Versprechen ist: Maximum Flexibilität. Jede Komponente kann unabhängig aktualisiert werden. Du bist nicht gefangen in den Update-Zyklen einer Monolith-Plattform. Und wenn eine Komponente nicht mehr passt, tauschst du sie aus. Die API bleibt die Schnittstelle.
Die Realität ist: Das funktioniert nur wenn die Integration wirklich reif ist. Und du musst die Architektur verstehen. Nicht implementieren, verstehen.
Was bedeutet MACH? Die vier Säulen
MACH ist ein Framework. Ein Akronym für vier Architektur-Prinzipien:
M wie Microservices: Nicht eine große Anwendung sondern viele kleine Services. Commerce, Search, Content, Assets, jeder als separater Service mit eigener Verantwortung.
A wie API-first: Alles läuft über APIs. Keine direkten Datenbankzugriffe. Der Service stellt sein Datenmodell über eine API bereit, der Consumer arbeitet damit. Das schafft Entkopplung.
C wie Cloud-native: Services laufen in der Cloud. Skalierbar, ausfallsicher, keine Kapazität die man selbst planen muss. Infrastructure as Code, Container, Kubernetes wenn nötig.
H wie Headless: Das Frontend ist komplett entkoppelt vom Backend. Das Backend liefert nur Daten. Dein Frontend kann eine Website sein, eine App, eine Desktop-Anwendung, morgen vielleicht etwas ganz anderes.
Wenn eine dieser vier Säulen fehlt, ist es nicht wirklich MACH. Es ist ein Hybrid. Was auch ok sein kann.
Composable vs. Monolith vs. Headless: Die Unterschiede
Diese drei Begriffe werden ständig verwechselt. Deshalb hier die klare Trennung:
Monolith (z.B. Shopware oder Shopify): Eine Plattform macht alles. Frontend, Backend, Produkte, CMS, Seiten, Search. Alles in einem System. Der Vorteil: Es gibt nicht viel zu integrieren. Das ist auch der Nachteil: Wenn du etwas anderes brauchst, baust du individuelle Erweiterungen auf der bestehenden Plattform.
Headless (z.B. Shopware Headless, Shopify Plus Hydrogen): Die Plattform liefert nur das Backend über APIs. Das Frontend ist separat. Content, Produkte, Preise kommen über APIs vom Backend. Dein Frontend nutzt diese APIs. Der Vorteil: Designfreiheit und ein entkoppelter Frontend-Zyklus. Das Backend kann aktualisieren ohne dein Frontend zu brechen. Der Nachteil: Du schreibst ein komplettes Frontend. Das ist Aufwand.
Composable Commerce: Mehrere spezialisierte Plattformen arbeiten zusammen. Das Commerce-Backend, das CMS, die Such-Engine, jeder macht das was er am besten kann. Über APIs. Der Vorteil: Du bekommst für jede Funktion das beste Werkzeug. Der Nachteil: Du musst alles integrieren und verstehen wie die Teile zusammenpassen.
Ein wichtiger Punkt: Composable ist nicht "ein fester Prozentsatz an Services". Das ist eine häufige Fehleinschätzung. Composable bedeutet: Du entscheidest pro Domain ob der Standard ausreichend ist oder ob du spezialisierte Tools brauchst. Das führt zu unterschiedlichen Kombinationen. Manche Shops brauchen Composable weil B2B-Komplexität spezialisierte Services erfordert. Andere D2C-Marken laufen mit Standard-Commerce + Headless-CMS und das ist schon "composable genug".
Ein Beispiel: Bei Shopware Headless nutzt du Shopware als Backend. Bei Composable Commerce vielleicht commercetools als Backend, Storyblok fürs CMS, Algolia für Search und Nuxt für das Frontend. Alles redet über APIs.
Wichtig: Headless ist oft ein Zwischenschritt. Manche Projekte fangen mit Headless an und ergänzen später spezialisierte Tools. Das ist ok. Besser als alles sofort zu entkoppeln. Die Entscheidung kommt dann pro Domain: "Reicht der Standard oder brauche ich spezialisiert?"
Ein typischer Composable-Stack
Wenn wir Composable-Projekte umsetzen, sieht das meist so aus:
Commerce Backend: commercetools. Open Source, API-first von Grund auf, keine Headless-Spielerei sondern pure API. Du schreibst gegen APIs, nicht gegen eine UI. Das ist anders als Shopware Headless, ist aber deutlich sauberer architektonisch.
Content Management: Storyblok. Headless CMS, gut integrierbar, Schema-basiert. Content-Teams bekommen eine UI, Entwickler bekommen strukturierte APIs.
Search: Algolia. Nicht als Rückfalloption für die Commerce-Plattform. Sondern als erste Wahl. Schneller, relevanter, mit Facetting, Typos, Synonymen von Haus aus.
Frontend: Nuxt oder Next.js. Eigene Komponenten, eigenes Design, eigener Deployment-Zyklus. Die Komponenten holen sich Daten von den APIs.
Das zusammen ist ein echter Composable-Stack. Nicht monolithisch. Nicht "wir haben ein individuelles Plugin extra". Sondern konzeptuell sauber.
Kosten für so einen Stack: 80.000+ EUR für die initiale Umsetzung. Plus Hosting (500+ EUR/Monat), Lizenzen (Storyblok, Algolia, commercetools zusammen 500+ EUR/Monat), Entwicklung für Integrations-Updates.
Das ist nicht günstig. Die Frage ist ob der Nutzen das rechtfertigt.
Wann Composable Commerce Sinn macht
Composable ist die Architektur für ein bestimmtes Segment. Nicht für viele. Die Entscheidung ist nicht "mehr oder weniger als X% individuell", sondern pro Domain: "Reicht der Standard oder brauche ich spezialisiert?"
Das sind die realen Fälle wo es Sinn macht:
B2B mit Komplexität: B2B braucht Composable früher als D2C weil mehr Systeme beteiligt sind. Kundengruppen-Preise, individuelle Kataloge, Freigabeprozesse, ERP-Integration. Das passt selten in einen Standard-Commerce-Stack. Hier macht Composable Sinn weil die Abhängigkeiten zwischen Systemen so groß sind dass spezialisierte Services besser sind.
Multi-Market-Operationen: Du verkaufst in 10+ Ländern. Jedes Land hat andere Anforderungen, andere Zahlungsarten, andere Steuern, andere Lieferanten. Mit einem Monolith wird das Konfigurationschaos. Mit Composable (etwa commercetools) passen die regionalen Anforderungen eleganter.
Multi-Marken-Setups: Du hast mehrere Marken mit unterschiedlichen Positionierungen aber gemeinsamen Lager- und Backend-Prozessen. Ein Backend, mehrere Frontends, jede Marke mit ihrem Design und ihrem CMS. Das ist ein echtes Composable-Szenario.
Content und Commerce stark vermischt und Freigabeprozesse notwendig: Du brauchst nicht nur viel Content (das könnte auch Headless lösen), sondern strukturierte redaktionelle Workflows. Wer genehmigt was, wer kann veröffentlichen. Hier macht eine CMS-Spezialisierung Sinn.
Enterprise mit vielen bestehenden Systemen: Du hast schon Salesforce, ERP, PIM, Warehouse Management im Einsatz. Mit Composable ist der Integrations-Layer klarer. Jeder Service hat eine API, Integrationen sind nicht in einer Codebase verteilt.
In diesen Fällen rechtfertigt Composable die höheren Kosten weil die Alternative (individueller Code auf einem Monolith) noch teurer oder fragiler wird.
Wann es zu viel ist
Und jetzt der wichtige Teil: In wie vielen Fällen ist Composable wirklich nötig?
Ehrliche Antwort: In 10% der Shops die danach fragen.
Das sind die Fälle wo Composable ein teurer Fehler ist:
Standard-Shop mit Standard-Anforderungen: Du verkaufst eine Produktkategorie, in einem oder zwei Märkten, keine B2B-Logik, Standard-Zahlungsarten. Ein Shopify oder Shopware Setup. Fertig. Composable multipliziert die Komplexität. Du bekommst nicht mehr Features, du bekommst mehr Dinge die brechen können.
Team hat keine Kapazität für Integrations-Management: Composable braucht jemanden der die Architektur versteht. Nicht nur technisch, sondern konzeptuell. Wenn das Team nicht da ist, wird Composable zum Chaos-Projekt. Alle Tools funktionieren einzeln, zusammen nicht.
Zeit-zu-Markt ist kritisch: Du brauchst einen Shop in 3 Monaten. Composable braucht 6 bis 12 Monate wenn du es richtig machst. Mit einem Monolith hast du nach 2 Monaten Umsatz.
Abhängigkeiten zwischen Systemen sind klein: Die meisten Anforderungen sind isoliert lösbar. Du brauchst nicht dass jedes System von jedem anderen weiß. Dann ist ein Monolith schneller.
Budget ist begrenzt: Composable kostet 80.000+ EUR am Anfang. Mit dem Budget bekommst du bei Shopware einen ausgefeilten individuellen Shop der die Geschäftsanforderungen erfüllt.
Wenn du mehr als zwei dieser Punkte abhaken kannst, ist Composable wahrscheinlich nicht die richtige Wahl.
Die TCO-Realität: Initial teurer, später günstiger
Das TCO-Argument ist wo Composable seine Kraft zeigt. Nur muss man den richtigen Zeithorizont nehmen.
Jahr 1 bis 3: Composable ist teurer. Initial höhere Entwicklungskosten, komplexere Architektur, du brauchst bessere Entwickler. Ein Monolith ist schneller und günstiger.
Jahr 3 bis 5: Hier dreht es sich. Mit Composable aktualisierst du commercetools, Storyblok, Algolia und dein Frontend unabhängig. Wenn commercetools ein Major-Update macht, betrifft das nur den API-Vertrag, nicht dein Frontend. Dein Frontend-Team arbeitet in ihrem Zyklus. Mit einem Monolith: Wenn Shopware 6.6 auf 7.0 geht, muss dein gesamter individueller Code überprüft werden. Dein Theme muss überprüft werden. Es kann Wochen dauern.
Bei Enterprise-Operationen: Der Vorteil wird noch größer. Du kannst einzelne Services austauschen. Algolia nicht mehr nötig weil deine Such-Engine jetzt 100.000 Produkte hat und Performance kein Thema mehr ist. Such-Engine raus, der Rest läuft. Bei Shopware musst du den ganzen Stack überdenken.
Die Rechnung: Wenn du alle 2 Jahre ein Major-Update auf deinem Monolith hast und das jeweils 3 Wochen kostet und 10.000 EUR kostet, über 5 Jahre sind das 50.000 EUR zusätzliche Update-Kosten. Plus die Ausfallrisiken und der Stress. Mit Composable sind diese Updates parallel.
Das ist aber nur relevant wenn du wirklich 5+ Jahre Perspektive hast. Wenn du dich in 2 Jahren verkauft hast, ist TCO egal.
Fazit: Für die meisten Shops falsche Wahl
Composable Commerce ist der richtige Ansatz wenn du Enterprise bist, Multi-Marken-Operationen hast, internationale Anforderungen und ein Team das diese Architektur verstehen und pflegen kann.
Für 90% der Shops ist eine bewährte Monolith-Plattform die bessere Wahl. Schneller zum Markt, günstiger, weniger Dinge die schieflaufen können.
Das zu sagen ist unbequem weil es gegen den Tech-Trend geht. Aber es ist ehrlich.
Wenn du vor der Entscheidung stehst: Definiere zuerst deine echten Anforderungen. Nicht die die du irgendwann haben willst. Die die du heute hast. Dann passt die Architektur. Der andere Weg ist teuer.
Wir bauen beides. Composable wenn es Sinn macht. Shopware und Shopify wenn es die bessere Wahl ist. Der Unterschied zwischen einer guten und einer schlechten Entscheidung ist meist die ehrliche Einschätzung am Anfang.