80 Prozent schneller bei der Umsetzung neuer Features, mit dieser Prognose hat Gartner 2020 den Begriff Composable Commerce salonfähig gemacht. Fünf Jahre später steht in den Bilanzen vieler Händler etwas Ernüchterndes: Projektbudgets, die sich verdoppelt haben, Entwicklerteams, die Microservices statt Kampagnen pflegen, und eine Schnittstellenlandschaft, die niemand im Haus mehr vollständig dokumentiert hat. Gleichzeitig wachsen commercetools, Spryker und SCAYLE zweistellig, und die MACH Alliance zählt inzwischen über hundert Mitgliedsunternehmen. Beides ist wahr. Und genau daran scheitern die meisten Architektur-Entscheidungen: Sie behandeln Composable Commerce als Technologiefrage, obwohl es eine Organisationsfrage ist.
Dieser Guide spart Ihnen die üblichen Definitionen. Stattdessen: die fünf Entscheidungen, bei denen Composable-Projekte in der Praxis kippen, inklusive der Anbieterlandschaft, die für den DACH-Markt tatsächlich relevant ist.
Wann lohnt sich Composable Commerce wirklich, und wann nicht?
Die ehrliche Antwort zuerst: Für die Mehrheit der deutschen Online-Händler lohnt sich eine vollständig modulare Architektur nicht. Wer unter 15 Millionen Euro Online-Umsatz macht, weniger als drei dedizierte Entwickler beschäftigt und ein Sortiment ohne exotische Pricing-Logik führt, fährt mit Shopify, Shopware oder einem gepflegten Monolithen schneller und billiger. Der modulare Ansatz kauft Flexibilität mit Komplexität, und Komplexität muss sich ein Unternehmen leisten können, jeden Tag, nicht nur am Go-live.
Interessant wird es ab einer bestimmten Schmerzgrenze. Typische Trigger, die wir in Gesprächen mit Händlern immer wieder hören: Multi-Brand-Setups mit drei oder mehr Shops auf einer Codebasis, B2B-Portale mit kundenindividuellen Preisen und Freigabe-Workflows, oder ein Marketing-Team, das für jedes neue Landingpage-Template einen Sprint beantragen muss. Sobald die Release-Geschwindigkeit des Gesamtsystems zum Umsatzrisiko wird, kippt die Rechnung.
Warum scheitern modulare Architekturen so oft im Betrieb?
Die Pressemitteilungen enden am Go-live. Die Probleme beginnen danach. Wer seine Commerce-Architektur aus zwölf spezialisierten Services zusammensetzt, Storefront, CMS, Search, Checkout, PIM, OMS, Personalisierung, betreibt danach zwölf Vendor-Beziehungen, zwölf Release-Zyklen und mindestens zwölf Stellen, an denen ein Update das Gesamtsystem brechen kann. In Projekten, die wir begleitet haben, lagen die laufenden Betriebskosten im ersten Jahr regelmäßig 20 bis 35 Prozent über der Planung. Nicht, weil die Software teurer war. Sondern weil niemand die Orchestrierung eingepreist hatte.
Ein zweiter, unterschätzter Kostenblock: Beobachtbarkeit. Im Monolithen zeigt ein Log, warum die Bestellung hängt. Im verteilten System brauchen Sie Tracing über fünf Services hinweg, um herauszufinden, ob der Fehler im Warenkorb-Service, in der Preis-Engine oder in der Middleware dazwischen liegt. Teams, die das unterschätzen, verbringen ihre Sprints mit Debugging statt mit Features, das exakte Gegenteil dessen, was Gartner versprochen hat.
„Der Monolith war nicht zu langsam. Unsere Entscheidungswege waren zu langsam, und die haben wir mit in die neue Architektur genommen.“ So fasste es der CTO eines deutschen Versandhändlers nach 18 Monaten Composable-Betrieb zusammen. Es ist die ehrlichste Projekt-Retrospektive, die wir kennen.
Die Konsequenz daraus ist unbequem: Wer replattformiert, ohne vorher Verantwortlichkeiten, Deployment-Prozesse und Datenhoheit zwischen Marketing, IT und Einkauf zu klären, baut sein altes Problem nur in kleineren Einheiten nach. Microservices lösen keine Abstimmungsprobleme. Sie machen sie teurer.
Welche Anbieter setzen im DACH-Markt die Maßstäbe?
Der deutsche Markt hat eine Besonderheit: Drei der weltweit relevantesten Composable-Anbieter kommen aus dem deutschsprachigen Raum. Das schafft kurze Wege, deutschsprachigen Support und Referenzen in ähnlichen Marktstrukturen, ein Vorteil, den viele Händler bei der Shortlist zu wenig gewichten.
- commercetools (München), der Enterprise-Maßstab für API-first-Commerce, Mitgründer der MACH Alliance, stark bei internationalen Konzernen und zuletzt deutlich in Richtung B2B und beschleunigter Implementierung mit Foundry unterwegs.
- Spryker (Berlin), erste Wahl bei komplexen Geschäftsmodellen: Marktplätze, B2B mit Freigabeprozessen, hybriden B2B2C-Setups. Referenzen wie ALDI Süd und Hornbach zeigen, wo die Stärke liegt.
- SCAYLE (Hamburg), aus About You hervorgegangen, Commerce-Engine mit Fashion-DNA. Wer schnelle Marktplatz-Anbindung und ein erprobtes Frontend-Ökosystem sucht, sollte SCAYLE auf die Shortlist setzen.
- Emporix (Zürich), kleiner, aber technisch konsequent composable, mit Fokus auf B2B-Automatisierung und Preislogik.
Daneben spielen zwei „Halb-Composable“-Optionen eine wachsende Rolle, die in Strategiepapieren oft unterschlagen werden. Shopware ist seit Version 6 API-first und lässt sich headless betreiben, ohne das Ökosystem zu verlassen, für den deutschen Mittelstand häufig der pragmatischste Zwischenschritt. Und Shopify drängt mit Hydrogen und Oxygen in Richtung modularer Frontends, bleibt aber im Core bewusst geschlossen. Wer Shopifys Betriebsmodell mag, aber mehr Freiheit im Frontend braucht, bekommt hier 80 Prozent des Composable-Nutzens bei 30 Prozent des Aufwands.
Best-of-Breed oder Suite-first: Wie trifft man die Architektur-Entscheidung?
Rein formell gibt es drei Wege: den Big Bang (alles neu, alles modular), den strangler-artigen schrittweisen Austausch und den Frontend-first-Ansatz. Der Big Bang hat in den letzten fünf Jahren die meisten Projektleiter gekostet, die er Projekte gerettet hat. Replatforming über alle Schichten gleichzeitig bedeutet sechs bis zwölf Monate ohne nennenswerte Feature-Auslieferung, Zeit, in der der Wettbewerb weiterläuft.
Der pragmatische Einstieg ist fast immer die Storefront. Ein headless Frontend auf dem bestehenden Shop-Core liefert sichtbare Ergebnisse, Ladezeit, Conversion im Checkout, Content-Geschwindigkeit, in einem Quartal statt in zwei Jahren. Erst danach wandern Search, CMS oder die Preislogik hinterher, Komponente für Komponente, jede mit eigenem Business Case. So bleibt das Projekt finanzierbar und das Team lernt den modularen Betrieb an einer überschaubaren Komponente, statt an zwölf gleichzeitig.
Bei der Anbieterauswahl selbst greifen Feature-Listen zu kurz. Drei Prüffragen trennen die Spreu vom Weizen: Wie sieht das Exit-Szenario aus, bekomme ich meine Daten vollständig und dokumentiert wieder heraus? Wie viele der Referenzkunden sind nach zwei Jahren noch auf der Plattform, und wie viele davon in meinem Geschäftsmodell? Und: Was kostet der Betrieb im dritten Jahr, nicht im ersten? Die Antwort auf die letzte Frage hat schon manche günstige Einstiegsofferte relativiert.
Zum Schluss eine These, die Ihnen kein Anbieter auf die Bühne tragen wird: Das Pendulum schwingt bereits zurück. Nach fünf Jahren maximaler Modularität bauen commercetools, Spryker und Shopify alle an vorkonfigurierten Bundles, Composable als Suite, quasi. Der Markt lernt gerade, dass die Frage nie „monolithisch oder modular“ war, sondern „wie viel Modularität verträgt meine Organisation“. Wer 2026 replattformiert, sollte nicht die Architektur kopieren, die Zalando oder Audi fahren. Er sollte die wählen, die sein Team an einem schlechten Dienstag im November noch beherrscht. Alles andere ist Architektur-Theater.