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

Composable Commerce ist zu einem der meistdiskutierten Architekturkonzepte der Branche geworden. Das Versprechen ist überzeugend: Wählen Sie die besten Komponenten für jede Funktion aus, setzen Sie sie zu einem massgeschneiderten Stack zusammen und gewinnen Sie die Flexibilität, jedes Teil unabhängig weiterzuentwickeln.

Doch für B2B-Organisationen, die SAP Commerce Cloud evaluieren, lautet die Frage nicht, ob Composable theoretisch überlegen ist — sondern ob die damit verbundenen Abwägungen für Ihren spezifischen Kontext sinnvoll sind.

Was «Composable» im SAP-Kontext eigentlich bedeutet

In SAP Commerce Cloud bedeutet Composable Commerce typischerweise:

• Commerce Engine: SAP Commerce Cloud verwaltet Produktinhalte, Preisgestaltung, Auftragsmanagement und Lagerbestand
• Storefront: Ein entkoppeltes Frontend — Spartacus, eine massgeschneiderte React/Vue.js-App oder ein DXP wie Contentful oder Sitecore
• Experience Layer: Personalisierung, A/B-Testing und Content Management werden durch dedizierte Tools abgewickelt

Der entscheidende technische Enabler ist die OCC (Omnichannel Commerce) API-Schicht von SAP Commerce Cloud, die alle Commerce-Funktionalitäten als REST-APIs bereitstellt.

Wann Composable sinnvoll ist

Hohe Design- und UX-Ambitionen. Wenn Ihr Storefront ein echtes Markenerlebnis sein soll — und nicht nur ein funktionaler Katalog —, gibt Composable Ihren Design- und Frontend-Teams die Freiheit, genau das zu bauen, was benötigt wird, ohne gegen die Plattform ankämpfen zu müssen.

Mehrere Storefronts. Wenn Sie B2B- und B2C-Erlebnisse oder Storefronts für mehrere Marken oder Märkte betreiben, ermöglicht die Entkopplung des Frontends, dass jedes Erlebnis unabhängig von einer gemeinsamen Commerce-Basis weiterentwickelt werden kann.

Aggressiver Release-Rhythmus. Wenn das Unternehmen mehrmals pro Woche Frontend-Änderungen veröffentlichen muss, bedeutet die Trennung des Storefronts von der Commerce Engine, dass Backend- und Frontend-Releases unabhängig voneinander erfolgen können.

Wann Composable keinen Sinn ergibt

Kleine Teams ohne dedizierte Frontend-Kompetenz. Composable Commerce erfordert Frontend-Expertise. Wenn Ihr Team primär SAP/Backend-orientiert ist, werden Sie mehr Zeit mit der Verwaltung des Frontend-Stacks verbringen als mit der Entwicklung von Commerce-Funktionen.

Kurze Zeitrahmen. Eine Composable-Architektur braucht länger in der Umsetzung. Bei einem Projekt mit einer 6-Monats-Deadline ist ein auf Spartacus basierender Accelerator-Ansatz typischerweise schneller.

Einfache Katalog- und Bestellanforderungen. Wenn der Kernanwendungsfall ein funktionales B2B-Bestellportal mit Standardfunktionen ist — und kein herausragendes Markenerlebnis —, rechtfertigt die zusätzliche Flexibilität von Composable möglicherweise nicht die Komplexität.

Unsere Empfehlung

Für die meisten B2B SAP Commerce Cloud-Projekte, die wir sehen, funktioniert ein pragmatischer Mittelweg am besten:

• SAP Commerce Cloud als Commerce Engine einsetzen
• Spartacus als Frontend-Accelerator verwenden (nach Bedarf angepasst)
• Emarsys oder ein DXP für Personalisierung und Content Management hinzufügen
• Composable schrittweise übernehmen, wenn Team-Kompetenz und Geschäftskomplexität wachsen

Die «vollständig composable» Architektur ist für einige Organisationen tatsächlich die richtige Antwort — aber sie ist nicht die Standardlösung. Die richtige Architektur ist diejenige, die zu Ihrem Team, Ihrem Zeitplan und Ihrem Geschäftsmodell passt.

Erfahren Sie mehr darüber, wie Spadoom SAP Commerce Cloud umsetzt — von Composable-Storefront-Projekten über B2B-Szenarien bis zur Integrationsarchitektur — auf unserer SAP Commerce Cloud Lösungsseite.

Möchten Sie besprechen, welcher Ansatz für Ihre Organisation der richtige ist? Sprechen Sie mit unseren Commerce-Architekten.