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

Composable Commerce wirkt auf dem Whiteboard überzeugend: für jede Aufgabe das beste Werkzeug, per API verbunden, austauschbar, sobald etwas Besseres kommt. Für ein B2B-Team auf SAP Commerce Cloud ist die nützliche Frage enger gefasst. Welche Teile Ihres Shops profitieren davon, eigenständig zu sein, und kann Ihr Team die zusätzlichen beweglichen Teile tragen?

Dieser Leitfaden beantwortet genau das. Er trennt Headless von Composable, zeigt, wie SAP Commerce Cloud beides unterstützt, und endet mit den Entscheidungsfragen, die wir in Architektur-Assessments verwenden. Die technischen Prinzipien hinter den Begriffen erklären wir im Beitrag zur MACH-Architektur in SAP Commerce Cloud.

Kurzfassung: Headless trennt den Storefront von der Commerce-Engine; Composable ersetzt zusätzlich einzelne Fähigkeiten wie Suche, CMS oder Zahlungen durch spezialisierte Dienste. Auf SAP Commerce Cloud läuft beides über die OCC-APIs. Composable lohnt sich bei hohem UX-Anspruch, mehreren Storefronts oder häufigen Frontend-Releases. Für kleine Teams, knappe Termine oder ein schlichtes Nachbestellportal ist es die falsche Wahl. Unser Standard: SAP Commerce Cloud als Kern, Composable Storefront oder ein eigenes Frontend, spezialisierte Dienste einzeln ergänzt.

Headless, Composable, MACH: drei verschiedene Dinge

Die Begriffe werden oft gleichgesetzt. Sie beantworten verschiedene Fragen.

Headless beantwortet: Wie spricht mein Storefront mit meiner Commerce-Engine? Ausschliesslich über APIs. Das Backend rendert keine Seiten, das Frontend greift nicht auf die Datenbank zu. So können Sie den Storefront in einem beliebigen Framework bauen, Frontend und Backend unabhängig releasen und Web, App und Kiosk aus demselben Backend bedienen. Es heisst aber auch: Sie brauchen Frontend-Entwickler, eine API-Schicht mit Authentifizierung und Versionierung sowie eigene Pipeline und eigenes Monitoring für das Frontend.

Composable beantwortet: Wie setze ich den ganzen Stack zusammen? Statt einer Suite, die alles macht, wählen Sie spezialisierte Dienste für Suche, Inhalte, Zahlungen oder Personalisierung und verbinden sie über APIs. Jeder lässt sich ersetzen, ohne den Rest neu zu bauen.

MACH (Microservices, API-first, Cloud-native, Headless) beschreibt die technischen Prinzipien, die Composable möglich machen. Sie brauchen Bausteine nach MACH-Art, um modular aufzubauen, aber allein darauf zu laufen, macht Sie noch nicht composable.

Man kann also headless sein, ohne composable zu sein (ein React-Storefront auf einer integrierten Commerce-Engine), und composable, ohne headless zu sein (ein serverseitig gerenderter Shop, der einen externen Suchdienst aufruft). Die meisten SAP-Commerce-Cloud-Projekte landen heute dazwischen: entkoppelter Storefront, integrierter Commerce-Kern und zwei, drei spezialisierte Dienste.

Wie SAP Commerce Cloud beides unterstützt

SAP Commerce Cloud ist headless von Grund auf und composable an den Rändern.

OCC-REST-APIs. Produkte, Kategorien, Warenkörbe, Checkout, Bestellungen und Kunden stehen als REST-Endpunkte bereit. Jedes Frontend und jedes externe System kann sie aufrufen, und über eigene Extensions lassen sich zusätzliche Endpunkte ergänzen. Ohne diese Schicht bliebe Composable eine Folie.

Composable Storefront. Der Angular-basierte Storefront von SAP (früher Spartacus) spricht nur über OCC mit der Commerce Cloud. Sie können ihn erweitern oder durch React oder Next.js ersetzen, ohne die Commerce-Engine anzufassen. SAP dokumentiert ihn im Composable-Storefront-Leitfaden auf SAP Help. Im September 2026 hat SAP zudem eine Partnerschaft mit Vercel für Next.js-Storefronts auf der Commerce Cloud angekündigt; die Frontend-Optionen vergleichen wir in Composable Storefront vs. React/Next.js.

Side-by-Side-Erweiterungen auf SAP BTP. Eigene Logik wie eine spezielle Preisregel oder ein Empfehlungsdienst kann auf SAP BTP laufen und von der Commerce Cloud aufgerufen werden, statt in den Kern eingebaut zu werden.

Spezialisierte Dienste an den Rändern. Suche (das eingebaute Solr oder ein externer Dienst), Content-Management (SmartEdit oder ein Headless-CMS), Zahlungen über Gateway-Integrationen, SAP Engagement Cloud (ehemals SAP Emarsys) für Marketing-Automatisierung und SAP Customer Data Cloud für Identität und Einwilligungen.

Was die Commerce Cloud nicht ist: eine Sammlung unabhängig deploybarer Microservices. Warenkorb, Preisfindung, Promotionen und Bestellungen laufen als eine Plattform. Im B2B ist das meist ein Vorteil, denn genau dort liegen Kontraktpreise, Kundenhierarchien und die Anbindung ans ERP.

Wann lohnt sich Composable im B2B?

Composable zahlt sich in drei Situationen aus. Trifft keine davon auf Sie zu, lohnt sich die zusätzliche Komplexität kaum.

Der Storefront ist Teil Ihrer Marke, nicht bloss ein Katalog. Sollen Einkäufer einen Produktkonfigurator, reichhaltige Inhalte oder eine geführte Auswahl erleben statt einer Liste mit Bestellknopf, gibt ein entkoppeltes Frontend Ihren Designern und Entwicklern Spielraum, den Vorlagen nicht bieten.

Sie betreiben mehrere Storefronts. B2B und B2C, mehrere Marken oder Länder auf einem Commerce-Kern: Durch die Entkopplung entwickelt sich jedes Erlebnis eigenständig weiter, während Preise, Bestände und Bestellungen an einem Ort bleiben.

Sie releasen Frontend-Änderungen laufend. Braucht das Geschäft mehrmals pro Woche Änderungen, entfällt mit getrennten Releasezyklen das Warten auf Backend-Deployments. Distrelec ist unsere Referenz dafür: Nachdem wir das Frontend von SAP Commerce Cloud entkoppelt hatten, sank die Time-to-Market für Frontend-Änderungen um 70 %.

Wann ist Composable die falsche Wahl?

Keine dedizierten Frontend-Leute. Ein eigenes Frontend ist eine JavaScript-Anwendung, die jemand bauen und pflegen muss. Besteht Ihr Team vor allem aus SAP- und Backend-Entwicklern, verbringen Sie mehr Zeit mit dem Frontend-Stack als mit Commerce-Funktionen.

Ein knapper Termin. Komponenten auswählen, verbinden und Pipelines aufbauen kostet Zeit, bevor die erste Bestellung durchläuft. In unseren Assessments sind das mehrere Wochen mehr als bei einem integrierten Start. Bei einem festen Go-live-Datum starten Sie mit dem Composable Storefront.

Ein einfacher Anwendungsfall. Ein Nachbestellportal mit Standard-B2B-Funktionen braucht kein eigenes Frontend. Der Composable Storefront deckt es ab, und das Budget ist in sauberen Preisen und einer funktionierenden ERP-Integration besser angelegt.

Wo Sie mit Composable anfangen

Bauen Sie nicht alles auf einmal um. Beginnen Sie dort, wo der Unterschied für Einkäufer am grössten und das Risiko für den Bestellablauf am kleinsten ist.

Reihenfolge	Komponenten	Warum hier
Hier starten	Suche, Zahlungen, Commerce-Analytics	Sichtbarer Nutzen, klare Schnittstellen, leicht rückgängig zu machen
Danach	Headless-CMS neben SmartEdit, Personalisierung, Marketing-Automatisierung (z. B. SAP Engagement Cloud)	Setzt saubere Daten und Content-Abläufe voraus
Später prüfen	Vollständig eigener Storefront, eigenes PIM statt des eingebauten Produkt-Contents, Funktionen als BTP-Dienste	Höchster Aufwand, berührt den Bestellablauf

Halten Sie dabei den Commerce-Kern stabil: Warenkorb, Checkout, Preisfindung, Bestellungen und Produktverwaltung bleiben in der Commerce Cloud. Validieren Sie jede neue Integration, bevor Sie die nächste anschliessen.

Die Risiken, die auf keiner Folie stehen

Integrationsaufwand. Jede Komponente ist eine Schnittstelle, ein Vertrag und ein Upgradezyklus mehr. Fünf Dienste heissen fünf Anbieter und fünf mögliche Fehlerquellen. Der Klebstoff dazwischen kann mehr kosten als jede einzelne Komponente.

Betrieb. Eine Plattform zu überwachen ist Routine. Zehn Dienste zu überwachen verlangt verteiltes Tracing, Alarmierung über Anbietergrenzen hinweg und ein Team, das den Fehler findet, wenn eine Bestellung zwischen zwei Systemen hängen bleibt. Das ist ein anderes Können als klassische Commerce-Entwicklung.

Die Abhängigkeit verschiebt sich, sie verschwindet nicht. Sie hängen nicht mehr an einem Anbieter, dafür an Ihrer Integrationsschicht. Ist der Integrationscode komplex, ist der Austausch einer Komponente schwieriger, als die Broschüre verspricht.

Die besten Einzelteile ergeben nicht automatisch das beste Ganze. Die beste Suche, das beste CMS und der beste Zahlungsanbieter ergeben zusammen nicht von selbst das beste Einkaufserlebnis. Entscheidend ist, wie gut sie bei einer echten Bestellung zusammenspielen.

Nach dem On-Premise-Ende: drei Wege

Die Mainstream-Wartung für SAP Commerce On-Premise (letztes Release 2205) endete am 31. Juli 2026; seither gibt es nur noch kundenspezifische Wartung (SAP Help). Für viele Teams ist das der Moment, die Composable-Frage zu stellen. Es gibt drei realistische Wege:

Weg	Was er bedeutet	Unsere Planungsgrösse	Passt, wenn
SAP Commerce Cloud	Bestehende Logik auf die von SAP betriebene Plattform bringen	Etwa 3 bis 6 Monate	Anpassungen hängen an SAP-Datenmodellen, das Team kennt SAP Commerce
Hybrid	Commerce Cloud als Kern, entkoppeltes eigenes Frontend, spezialisierte Dienste nach und nach	Etwa 4 bis 8 Monate	Sie wollen Freiheit im Frontend, ohne Commerce-Logik neu zu bauen
Voll Composable	Plattform durch eigene Dienste für Commerce, Inhalte, Suche und Bestellungen ersetzen	Oft 9 bis 15 Monate	Starkes internes Team, API-first-Landschaft, ungewöhnliche Anforderungen

Diese Spannen stammen aus unseren eigenen Assessments und hängen vom Umfang ab; sie sind kein Angebot. Die Franke-Plattform zeigt, was ein fokussierter Umfang erreicht: Spadoom hat die SAP-Commerce-Cloud-Plattform in 90 Tagen live gebracht, eine Zahl, die sich auf diesen Commerce-Launch bezieht. Wenn Sie noch On-Premise sind, finden Sie die nächsten Schritte in unserem Beitrag dazu, was nach dem Ende des On-Premise-Supports zu tun ist.

Ein vollständiger Composable-Neubau bedeutet, jahrelang gewachsene Promotionsregeln, Preisberechnung und B2B-Logik neu zu implementieren, die die Commerce Cloud behält. Das allein ist oft ein grösseres Projekt als der ganze Wechsel in die Cloud.

Wie entscheiden Sie?

Sechs Fragen. Beantworten Sie sie für Ihr heutiges Team, nicht für das erhoffte.

1. Haben Sie mindestens zwei dedizierte Frontend-Entwickler? Wenn nein: integriert starten.
2. Brauchen Sie mehrere unterschiedliche Storefronts? Wenn ja: Composable hat gute Argumente.
3. Liegt Ihr Go-live weniger als sechs Monate entfernt? Wenn ja: integriert starten.
4. Ist der Storefront ein Differenzierungsmerkmal Ihrer Marke oder ein Werkzeug? Differenzierung: entkoppeln. Werkzeug: integriert bleiben.
5. Bieten Ihre ERP-, PIM- und Logistiksysteme bereits saubere APIs? Wandern Daten noch als Batch-Dateien und Tabellen, bringt Composable Komplexität ohne seinen Hauptnutzen.
6. Können Sie über Jahre mehrere Anbieterbeziehungen und ein eigenes Frontend tragen? Composable ist kein einmaliges Bauprojekt.

Für die meisten B2B-Projekte auf SAP Commerce Cloud lautet unsere Empfehlung gleich: integriert starten, das Frontend entkoppeln, wo es hilft, und weiter modularisieren, wenn Team und Anforderungen wachsen. Die OCC-APIs halten diese Option offen, ohne die Commerce-Engine anzufassen. Welchen Weg Sie auch wählen, die Bestellung muss korrekt im ERP ankommen. Deshalb planen wir Storefront und ERP-Integration mit einem Team, wie im Beitrag zum B2B-Webshop auf SAP Commerce Cloud mit S/4HANA Public Cloud beschrieben. Wer Plattformen über SAP hinaus vergleicht, liest unseren Vergleich von SAP, Salesforce und Adobe Commerce.

---

Sie möchten wissen, welcher Ansatz zu Ihrer Situation passt? Unsere Architektur-Assessments betrachten Team, Zeitplan, ERP-Landschaft und Anforderungen. Sprechen Sie mit unseren Commerce-Architekten oder lesen Sie mehr über unsere Leistungen für SAP Commerce Cloud.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Headless und Composable Commerce?

Headless trennt den Storefront vom Commerce-Backend, beide sprechen nur über APIs miteinander. Composable geht weiter: Suche, Inhalte, Zahlungen oder Personalisierung sind eigene, austauschbare Dienste. Jedes Composable-Setup ist headless, aber ein Headless-Storefront auf einer integrierten Commerce-Engine ist noch nicht composable. SAP Commerce Cloud unterstützt beides über die OCC-REST-APIs.

Ist SAP Commerce Cloud headless oder composable?

Headless von Grund auf und composable an den Rändern. Die OCC-APIs stellen Produkte, Warenkörbe, Checkout, Bestellungen und Kunden jedem Frontend zur Verfügung, und Suche, CMS, Zahlungen oder Marketing können externe Dienste sein. Der Commerce-Kern (Warenkorb, Preise, Promotionen, Bestellungen) bleibt eine integrierte Plattform, keine Sammlung unabhängig deployter Microservices.

Können wir mit dem Composable Storefront starten und später voll auf Composable gehen?

Ja, und für die meisten B2B-Projekte empfehlen wir genau das. Der Composable Storefront nutzt dieselben OCC-APIs wie jedes eigene Frontend. Ein späterer Wechsel zu React oder Next.js lässt Commerce-Konfiguration, Datenmodell und ERP-Integration unberührt. Ersetzen Sie eine Komponente nach der anderen, beginnend mit der, die am meisten Ärger macht.

Wie viele Entwickler braucht eine Composable-Architektur?

Rechnen Sie mit zwei bis drei dedizierten Frontend-Entwicklern, ein bis zwei Commerce- oder Integrationsentwicklern und jemandem, der DevOps und Monitoring über mehrere Deployment-Pipelines verantwortet. Ein integriertes Setup mit dem Composable Storefront kommt oft mit einem kleineren Team aus SAP-Commerce-Entwicklern aus. Zudem muss jemand die Gesamtarchitektur verantworten.

Ist Composable Commerce teurer als ein integriertes Setup?

Zu Beginn ja: Auswahl der Komponenten, Integrationsarbeit und zusätzliche Pipelines kosten Wochen und Budget, bevor die erste Bestellung läuft. Über drei bis fünf Jahre kann es sich rechnen, wenn Sie tatsächlich Komponenten wechseln oder mehrere Storefronts betreiben. Der grösste Kostentreiber sind nicht Lizenzen, sondern Integration und Betrieb: Jeder zusätzliche Dienst bringt eigenen Vertrag, eigenen Releasezyklus und eigene Fehlerquellen.

Was hat sich für On-Premise-Kunden nach dem 31. Juli 2026 geändert?

Die Mainstream-Wartung für SAP Commerce On-Premise (letztes Release 2205) endete am 31. Juli 2026; seither gibt es nur noch kundenspezifische Wartung. Ein Wechsel in die SAP Commerce Cloud erhält bestehende Geschäftslogik und Datenmodelle, ein vollständiger Composable-Neubau bedeutet, sie neu zu implementieren. Ein häufiger Mittelweg ist Commerce Cloud als Kern mit entkoppeltem Frontend.