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

Composable Commerce. Eines der meistdiskutierten Architekturkonzepte der Branche. Das Versprechen klingt überzeugend: die besten Komponenten für jede Funktion auswählen, zu einem massgeschneiderten Stack zusammensetzen, jedes Teil unabhängig weiterentwickeln.

Aber für B2B-Organisationen, die SAP Commerce Cloud evaluieren, lautet die relevante Frage nicht, ob Composable theoretisch überlegen ist. Sondern ob die damit verbundenen Abwägungen für Ihren spezifischen Kontext Sinn ergeben. Und da wird es konkret.

Was «Composable» im SAP-Kontext eigentlich bedeutet

In SAP Commerce Cloud bedeutet Composable Commerce typischerweise:

• Commerce Engine: SAP Commerce Cloud verwaltet Produktinhalte, Preisgestaltung, Auftragsmanagement, 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 durch dedizierte Tools

Der technische Enabler ist die OCC (Omnichannel Commerce) API-Schicht von SAP Commerce Cloud, die alle Commerce-Funktionalitäten als REST-APIs bereitstellt. Prima vista einfach. In der Praxis: Es kommt drauf an.

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 anzukämpfen.

Mehrere Storefronts. Wenn Sie B2B- und B2C-Erlebnisse oder Storefronts für mehrere Marken 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. Das ist kein Luxus, das ist eine Notwendigkeit für schnell drehende Märkte.

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. Also ehrlich: Das ist der häufigste Fehler, den wir sehen.

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. Und schneller heisst hier: adäquat schnell, nicht gehetzt.

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 die Komplexität de facto nicht.

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. Nicht die, die auf der letzten Konferenz am lautesten beklatscht wurde.

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.

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