Composable Commerce im B2B: Wann es sinnvoll ist — und wann nicht

Composable Commerce sieht auf dem Whiteboard brillant aus. Für jede Aufgabe das beste Tool wählen. Alles zusammenstecken. Teile austauschen, sobald etwas Besseres auftaucht. Verstehe ich. Elegantes Konzept.

Aber wenn Sie ein B2B-Team sind, das SAP Commerce Cloud betreibt, bezahlt das Whiteboard keine Rechnungen. Die eigentliche Frage ist, ob die Abwägungen für Ihre Situation tatsächlich funktionieren. Der globale B2B-E-Commerce-Markt liegt bei 32.1 Billionen US-Dollar und wächst mit 14.5 % CAGR (Statista, 2025). Ihre Architekturwahl ist also relevant. Aber «Composable für alle» ist die falsche Antwort.

TL;DR: 76 % der Organisationen planen, innert zwei Jahren Composable Commerce einzuführen (MACH Alliance, 2024). Aber Composable ist nicht der Standard für jedes B2B-Szenario. Es funktioniert bei hohen UX-Ambitionen, mehreren Storefronts oder ständigen Frontend-Änderungen. Es ist falsch für kleine Teams, knappe Zeitpläne oder einfache Bestellportale. Unsere Empfehlung: mit SAP Commerce Cloud + Composable Storefront starten, dann schrittweise composable werden.

Was bedeutet «Composable» im SAP-Kontext eigentlich?

SAP ist seit 11 Jahren in Folge Leader im Gartner Magic Quadrant für Digital Commerce (SAP News Center, 2025). In SAP Commerce Cloud heruntergebrochen bedeutet Composable drei entkoppelte Schichten:

Die Commerce Engine (SAP Commerce Cloud) verwaltet Produktinhalte, Preisgestaltung, Auftragsmanagement und Lagerbestand. Davor sitzt ein entkoppelter Storefront: der Composable Storefront (früher Spartacus), eine eigene React/Vue.js-App oder ein DXP wie Contentful. Eine Experience-Schicht übernimmt Personalisierung, A/B-Testing und Content Management über dedizierte Tools.

Möglich macht das alles die OCC (Omnichannel Commerce) API-Schicht von SAP Commerce Cloud. Jede Commerce-Funktion als REST-API verfügbar. Ohne diese Schicht bleiben Sie an SAPs Frontend-Stack gebunden, und Composable bleibt eine hübsche Idee auf einer Folie.

Wann ist Composable im B2B sinnvoll?

Wir haben inzwischen eine ganze Reihe von Architektur-Assessments für B2B-Commerce-Projekte durchgeführt. Composable funktioniert in drei Situationen. Wenn keine davon auf Sie zutrifft, lohnt sich die zusätzliche Komplexität vermutlich nicht.

Sie wollen ein echtes Markenerlebnis, keinen Katalog. Wenn Ihr Storefront wie ein echter Marken-Touchpoint wirken soll, gibt Composable Ihren Design- und Frontend-Teams die Freiheit, genau das zu bauen, was sie wollen. Kein Kampf gegen die Plattform. 80 % der B2B-Umsätze werden bis Ende 2025 digital generiert (Shopify, 2025). Die Erwartungen von B2B-Käufern nähern sich schnell dem B2C-Niveau an. Ihr Storefront darf nicht mehr wie eine Tabelle aussehen.

Sie betreiben mehrere Storefronts. B2B und B2C? Mehrere Marken oder Märkte? Die Entkopplung des Frontends lässt jedes Erlebnis unabhängig von einem gemeinsamen Commerce-Kern weiterentwickeln. Eine Commerce-Cloud-Instanz, komplett unterschiedliche Frontends. Genau da verdient Composable sein Geld.

Sie liefern ständig Frontend-Änderungen aus. Wenn das Unternehmen mehrmals pro Woche Updates braucht, entkoppelt die Trennung von Storefront und Commerce Engine die Release-Zyklen. Backend-Updates nach eigenem Zeitplan. Frontend-Deployments, wann immer Sie wollen. Niemand wartet auf niemanden.

Wann ist Composable die falsche Wahl?

Ihr Team hat keine dedizierten Frontend-Leute. Composable braucht React-, Angular- oder Vue-Entwickler, die eine richtige JavaScript-Applikation bauen und pflegen können. Wenn Ihr Team primär aus SAP- und Backend-Leuten besteht, verbringen Sie mehr Zeit mit der Verwaltung des Frontend-Stacks als mit dem Bau von Commerce-Funktionen.

Sie haben es eilig. Composable braucht anfangs länger bis zur Auslieferung. 6-Monats-Deadline? Ein Accelerator-basierter Ansatz auf dem Composable Storefront bringt Sie schneller ans Ziel. Der Composable-Setup-Overhead (Komponenten auswählen, verdrahten, Deployment-Pipelines bauen) kostet 4 bis 8 Wochen mehr als ein integrierter Start. Das ist echte Zeit.

Ihr Use Case ist simpel. Wenn Sie ein funktionales B2B-Bestellportal mit Standardfunktionen bauen und kein Flaggschiff-Markenerlebnis, rechtfertigt die Flexibilität von Composable die Komplexität nicht. Wozu ein eigenes React-Frontend für ein Nachbestellportal? Das deckt der Composable Storefront out of the box ab.

Was ist der pragmatische Mittelweg?

Bei den meisten B2B SAP Commerce Cloud-Projekten, die wir sehen, gewinnt der Mittelweg. 90 % der Unternehmen, die ihre E-Commerce-Plattform migriert haben, meldeten Umsatzverbesserungen (commercetools, 2024). Aber die Architekturwahl ist weniger entscheidend als saubere Grundlagen.

Das empfehlen wir in den meisten Fällen konkret: SAP Commerce Cloud als Commerce Engine. Composable Storefront als Frontend-Accelerator, angepasst nach Bedarf. Emarsys oder ein DXP für Personalisierung und Content Management. Dann schrittweise composable werden, wenn Teamkompetenz und Geschäftskomplexität wachsen.

Integriert starten. Zu Composable weiterentwickeln. Das ist kein Kompromiss. Es ist der Ansatz, der am schnellsten Wert liefert und gleichzeitig die Option offenhält, später zu dekomponieren. Dank der OCC-API-Schicht können Sie das Frontend jederzeit austauschen, ohne die Commerce Engine anzufassen. Das klingt nach Aufschieben, ist es aber nicht. Es ist pragmatisch.

Details dazu, wie wir SAP Commerce Cloud implementieren, inklusive Composable-Storefront-Projekten, B2B-Szenarien und Integrationsarchitektur, finden Sie auf unserer SAP Commerce Cloud Lösungsseite.

Wie sollten Sie entscheiden?

Fünf Fragen. Seien Sie ehrlich mit sich selbst.

1. Hat Ihr Team 2+ dedizierte Frontend-Entwickler? Falls nein: integriert starten.
2. Brauchen Sie mehrere unterschiedliche Storefronts? Falls ja, hat Composable gute Argumente.
3. Liegt Ihre Go-live-Deadline unter 6 Monaten? Falls ja: integriert starten.
4. Ist der Storefront ein Markendifferenzierer oder ein funktionales Werkzeug? Markendifferenzierer: composable. Funktionales Werkzeug: integriert.
5. Können Sie in die langfristige Wartung eines eigenen Frontends investieren? Composable ist kein einmaliger Bau. Es ist eine dauerhafte Verpflichtung.

Ganz ehrlich: Für manche Unternehmen ist vollständig composable tatsächlich die richtige Antwort. Aber es ist nicht der Standard. Die richtige Architektur ist die, die zu Ihrem Team, Ihrem Zeitplan und Ihrem Geschäftsmodell passt.

Möchten Sie herausfinden, welcher Ansatz zu Ihrer Situation passt? Wir führen Architektur-Assessments durch, die Ihr Team, Ihren Zeitplan und Ihre Anforderungen bewerten und dann den Ansatz empfehlen, der am schnellsten Wert liefert. Sprechen Sie mit unseren Commerce-Architekten.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Composable und Headless Commerce?

Headless bedeutet, das Frontend über APIs vom Backend zu trennen. Das ist eine Architekturentscheidung. Composable geht weiter: Sie wählen Best-of-Breed-Komponenten für jede Commerce-Funktion (Suche, PIM, OMS, Payments) und verbinden sie. Jede Composable-Architektur ist headless, aber nicht jede Headless-Implementierung ist composable. SAP Commerce Cloud unterstützt beides über die OCC-API-Schicht.

Können wir mit dem Composable Storefront starten und später vollständig composable werden?

Ja. Und genau das empfehlen wir für die meisten B2B-Projekte. Der Composable Storefront basiert auf Angular und konsumiert die OCC-APIs von Commerce Cloud. Weil alles über APIs läuft, können Sie später ein eigenes React- oder Next.js-Frontend einsetzen, ohne die Commerce Engine anzufassen. Ihre Investition in Commerce-Cloud-Konfiguration, Datenmodelle und Integrationen bleibt vollständig erhalten. Das ist der ganze Punkt.

Wie viele Entwickler braucht eine Composable-Architektur?

Ein Composable-Stack braucht typischerweise 2 bis 3 dedizierte Frontend-Entwickler plus 1 bis 2 Commerce-Cloud-Backend-Entwickler für die laufende Wartung. Zum Vergleich: Ein integrierter Composable-Storefront-Ansatz läuft mit 1 bis 2 Full-Stack-Entwicklern. Dazu brauchen Sie DevOps-Kompetenz für mehrere Deployment-Pipelines, CI/CD-Konfigurationen und Service-Abhängigkeiten. Das summiert sich schnell.

Ist Composable Commerce teurer als integriert?

Anfangs ja. Der Setup-Overhead kostet 4 bis 8 Wochen und typischerweise 20 bis 30 % mehr Initialbudget. Über einen Horizont von 3 bis 5 Jahren kann Composable jedoch günstiger sein, wenn Sie die Flexibilität tatsächlich brauchen. Einzelne Komponenten auszutauschen kostet weniger als ein komplettes Replatforming eines integrierten Stacks. Der Break-even hängt davon ab, wie oft Sie Ihr Frontend weiterentwickeln und wie viele Storefronts Sie betreiben.

Unterstützt SAP Composable-Architekturen auf Commerce Cloud?

SAP unterstützt Composable-Ansätze aktiv über die OCC-API-Schicht von Commerce Cloud und das Composable-Storefront-Framework. SAPs eigene Architektur-Guidance positioniert Commerce Cloud als «Composable Commerce Engine», die mehrere Frontend-Erlebnisse bedienen kann. Die API-Abdeckung der Plattform ist für die meisten B2B-Szenarien solide, auch wenn einzelne Randfälle eigene API-Erweiterungen über SAP BTP brauchen können.