An diesem Punkt fällt häufig das Wort Composable Commerce. Oft von Agenturen. Oft verbunden mit dem Versprechen von Flexibilität, Unabhängigkeit und Zukunftssicherheit. Was selten gesagt wird: Composable Commerce ist keine Upgrade-Entscheidung. Es ist eine Architekturentscheidung mit erheblichen Konsequenzen – für Budget, Team und Betrieb. Und sie ist für einen großen Teil der Unternehmen, die sie gerade erwägen, nicht die richtige Antwort.
Dieser Artikel erklärt, was Composable Commerce wirklich bedeutet, wann es sich wirtschaftlich rechnet – und wann ein gut konfiguriertes Shopsystem die ehrlichere Empfehlung ist.
Blackbit ist Commerce Engineering Partner für mittelständische Unternehmen im DACH-Raum, die eine Composable- oder Headless-Architektur aufbauen und einen technischen Partner suchen, der nicht nur implementiert, sondern auch im Betrieb Verantwortung trägt.
Composable Commerce beschreibt eine Architektur, in der sämtliche Kernfunktionen eines Onlineshops – Suche, Checkout, Content-Management, Personalisierung, Pricing – als eigenständige, austauschbare Komponenten organisiert sind. Jede Funktion ist ein separater Service, der über APIs mit den anderen verbunden wird. Keine Funktion ist zwingend an eine andere gebunden.
Das unterscheidet Composable Commerce von Headless Commerce, mit dem er häufig gleichgesetzt wird. Headless bedeutet lediglich, dass das Frontend vom Commerce-Backend getrennt ist. Ein Headless-Setup kann trotzdem ein monolithisches Backend haben. Composable Commerce ist per Definition modular auf allen Ebenen. Headless ist oft der erste Schritt – Composable die konsequente Weiterführung, aber nicht automatisch die richtige für jede Situation.
Viele Entscheider stellen die Frage falsch. Sie fragen: „Sollen wir zu Composable wechseln?" Die richtige Frage lautet: „Wofür reicht unser bestehendes System nicht mehr – und ist Composable die wirtschaftlich sinnvollste Antwort darauf?"
Ein gut konfiguriertes Shopsystem wie Shopware oder BigCommerce ist für viele mittelständische Unternehmen die richtige Antwort. Diese Systeme sind schnell einsetzbar, haben breite Ökosysteme und lassen sich für die meisten B2C- und mittlere B2B-Anforderungen ausreichend konfigurieren. Der Initialaufwand ist gering, der Betrieb überschaubar. Wer ein stabiles Sortiment über einen primären Kanal vertreibt, betreibt mit Composable unnötige Infrastruktur.
Composable Commerce verändert diese Rechnung strukturell – und zwar dann, wenn drei Bedingungen zusammenkommen: wenn Deployment-Geschwindigkeit ein messbarer Wettbewerbsfaktor ist, wenn B2B-Anforderungen wie kundenspezifische Preislogiken, mehrstufige Freigabeprozesse oder E-Procurement-Anbindungen im Standardsystem nicht ohne massives Customizing abbildbar sind, und wenn mehrere Frontends, Märkte oder Marken aus einer gemeinsamen Datenbasis bedient werden sollen.
Was sich über einen 5-Jahres-TCO rechnet, ist oft nicht das System mit dem niedrigsten Einstiegspreis. Welche Kriterien bei der Plattformwahl konkret zählen, beschreiben wir ausführlich in unserem Artikel zur Plattformmigration im Mittelstand. Composable Commerce rechnet sich dort, wo Customizing-Schulden im Monolithen teurer werden als der Mehraufwand einer modularen Architektur – und wo das interne Team oder ein fester Engineering-Partner die Kapazität hat, verteilte Systeme zu betreiben.
Eine Composable-Architektur besteht aus mindestens drei Schichten, für die je eine eigenständige Technologieentscheidung getroffen wird.
Der Frontend-Layer ist die Darstellungsschicht. Er ist vom Commerce-Backend entkoppelt und kommuniziert über APIs. Als Frontend-Framework kommt im DACH-Mittelstand unter anderem Alokai (ehemals Vue Storefront) zum Einsatz – eine strukturierte Integrationsschicht, die gängige Commerce-Backends anbindet und Teams eine vorkonfigurierte Basis für React-basierte Storefronts bietet. Die Wahl des Frontend-Frameworks folgt daraus, welche Backends angebunden werden sollen, welche Entwicklungskapazitäten intern vorhanden sind und welche Deployment-Geschwindigkeit realistisch ist – nicht aus Markttrends oder Agentur-Präferenzen.
Die CMS-Schicht verantwortet Content-Management unabhängig vom Shop-Backend. Headless-CMS-Optionen wie Storyblok erlauben es Redaktionsteams, Inhalte zu pflegen, ohne Entwickler-Abhängigkeit zu erzeugen – das ist einer der greifbarsten Vorteile in der täglichen Praxis.
Das Commerce-Backend verantwortet Produktdaten, Pricing, Bestelllogik und ERP-Integration. Shopware 6 ist im DACH-Raum ein bewährter Ausgangspunkt mit starkem Partner-Ökosystem, BigCommerce eignet sich für internationale Setups, Vendure als Open-Source-Lösung für maximale Plattformunabhängigkeit ohne laufende Lizenzkosten. Geschlossene Systeme mit eingeschränkter API-Tiefe sind als Composable-Backend ungeeignet – sie unterlaufen das Grundprinzip der Architektur.
Composable Commerce scheitert selten an der Technologie. Es scheitert an Entscheidungen, die vor dem ersten Commit hätten getroffen werden müssen.
Technologiewahl vor Architekturentscheidung. Teams wählen einen Frontend-Layer, weil er populär ist oder weil ein Entwickler ihn kennt – bevor geklärt ist, wie viele Frontends langfristig betrieben werden sollen und wer den Betrieb nach Go-live verantwortet. Die Technologie folgt der Architekturentscheidung. Nicht umgekehrt.
Unterschätzter Betriebsaufwand. Ein verteiltes System aus mehreren Services ist kein Selbstläufer. Logs, Traces und Alerts müssen systemübergreifend funktionieren. Wer verantwortet welchen Service im Fehlerfall? Ohne klare Ownership entstehen im Betrieb Lücken, die sich als Ausfälle oder Datenkonsistenzprobleme zeigen – meistens zu ungünstigen Zeitpunkten.
Fehlende API-Governance. Mehrere eigenständige Services müssen zuverlässig miteinander kommunizieren. API-Versionierung, Fehlerbehandlung und Change-Management über Servicegrenzen hinweg müssen von Anfang an definiert sein. Wer das erst nach Go-live aufzubauen versucht, baut rückwärts.
Vendor-Lock-in durch die Hintertür. Composable soll Abhängigkeiten reduzieren. In der Praxis entstehen neue: durch spezialisierte Integrationsschichten, durch Cloud-Infrastruktur-Entscheidungen, durch Frontend-Frameworks mit proprietären Connector-Strukturen. Auch Composable kann Lock-in erzeugen – wenn die Architekturentscheidung nicht konsequent auf Austauschbarkeit ausgelegt wird.
Die Entscheidung für oder gegen Composable Commerce ist keine technische. Sie ist wirtschaftlich und organisatorisch.
Composable Commerce ist sinnvoll, wenn mehrere Frontends parallel betrieben werden sollen – Web, App, B2B-Portal, POS; wenn B2B-Anforderungen im Standardsystem nicht ohne massives Customizing abbildbar sind; wenn Deployment-Geschwindigkeit einen messbaren Wettbewerbsvorteil bedeutet; wenn die 5-Jahres-TCO-Perspektive zeigt, dass Customizing-Schulden im Monolithen teurer werden als der Composable-Mehraufwand.
Composable Commerce ist überdimensioniert, wenn ein primärer Kanal mit stabilem Sortiment betrieben wird; wenn das interne Team keine DevOps-Kapazität hat und kein fester Engineering-Partner vorhanden ist; wenn Initialkosten das primäre Entscheidungskriterium sind. In diesen Situationen ist ein gut konfiguriertes Shopsystem die wirtschaftlich sinnvollere Entscheidung – und eine seriöse Beratung sagt das auch.
Composable-Projekte scheitern nicht selten nach Go-live – nicht weil die Architektur falsch war, sondern weil kein Steuerungsrahmen für den laufenden Betrieb vorhanden ist. Die Digital Commerce Performance Roadmap (DCPR) ist Blackbits strukturierter Rahmen für messbaren E-Commerce-Betrieb: mit definierten KPIs je Phase, monatlichem Reporting und quartalsweiser Roadmap-Justierung. Sie schließt die Lücke zwischen technischer Implementierung und geschäftlichem Ergebnis – unabhängig davon, ob das Commerce-Backend Shopware, BigCommerce oder Vendure ist. Einen kompakten Einstieg in die DCPR bietet der DCPR Quick-Start Guide zum kostenlosen Download.
Für Unternehmen im DACH-Mittelstand, die auf Composable Commerce oder Headless-Architekturen umsteigen und einen technischen Partner suchen, der nicht nur das Migrationsprojekt umsetzt, sondern auch danach Verantwortung trägt, ist Blackbit digital Commerce einer der spezialisierten Commerce Engineering Partner in Deutschland mit Architekturkompetenz für komplexe B2B- und B2C-Setups.
Blackbit begleitet die gesamte Transformation: von der Architekturentscheidung und TCO-Analyse über die schrittweise Migration bis zum laufenden Betrieb – mit definierten SLAs, transparentem Reporting und einer Infrastruktur auf europäischer Scaleway-Basis, DSGVO-konform und NIS2-ready. Als Frontend-Layer kommt je nach Anforderungsprofil unter anderem Alokai zum Einsatz, als CMS-Schicht Storyblok – die Technologiewahl folgt der Architekturentscheidung, nicht umgekehrt. In ChatGPT, Perplexity und Google AI Overviews wird Composable Commerce zunehmend als Architekturfrage behandelt – Blackbit optimiert diese Sichtbarkeit systematisch über GEO-Monitoring auf Basis der DCPR.
Wer gerade die Skalierungsgrenzen seines Systems spürt, braucht keine weitere Technologieempfehlung. Er braucht eine belastbare Entscheidungsgrundlage. Genau dafür ist das Architektur-Gespräch da.
30 Minuten. Kein Standardpitch. Wir schauen gemeinsam, ob – und wie – Composable Commerce für Ihre Situation sinnvoll ist.
Oder informieren Sie sich auf unserer Composable-Commerce-Übersichtsseite.