Composable Commerce: was es ist und wann es zum Mittelstand passt

Composable Commerce ist ein Ansatz, ein Onlinegeschäft aus separaten, austauschbaren Komponenten aufzubauen, die jeweils eine Geschäftsfunktion abdecken, etwa Produktkatalog, Preise, Warenkorb und Checkout, Suche, Content oder Auftragsverwaltung. Die Komponenten kommunizieren über APIs miteinander. Statt einer Plattform, die alles erledigt, wählst du für jede Aufgabe eine Komponente und kannst eine austauschen, ohne den Rest neu aufzubauen. Shopify beschreibt das als Auswahl und Integration von „best-in-breed technologies“, die über APIs verbunden sind (Shopify).

Laut Shopify hat das Analystenhaus Gartner den Begriff geprägt. Die Komponenten heißen Packaged Business Capabilities (PBCs), und die Architektur folgt meist den MACH-Prinzipien. Für die meisten Händler im Mittelstand lautet die praktische Antwort nicht „komplett composable werden“, sondern „den Stack dort modular machen, wo es wehtut“: eine Commerce-Plattform als Kern behalten und spezialisierte Komponenten nacheinander einbauen. In jeder Variante brauchen Produktdaten genau einen Eigentümer, und genau das ist die Aufgabe eines PIM.

Packaged Business Capabilities: eine Geschäftsaufgabe pro Komponente

Eine Packaged Business Capability ist laut Shopify eine Softwarekomponente, die „a particular business function“ abbildet, also eine bestimmte Geschäftsfunktion wie Checkout oder Suche. Commerce Layer beschreibt einen Composable-Stack als einen, der um PBCs herum gebaut ist, die „individually developed, deployed, and managed, connected through APIs“ sind, also einzeln entwickelt, bereitgestellt und verwaltet und über APIs verbunden (Commerce Layer).

In einem typischen Commerce-Stack sehen die PBCs und die Daten, die jede von ihnen verantwortet, so aus:

• Produktinformationen: Produkte, Attribute, Varianten, Übersetzungen, Bilder und Kategoriezuordnungen.
• Preise und Aktionen: Preislisten pro Markt oder Kundengruppe, Rabatte und Gutscheinregeln.
• Warenkorb und Checkout: Warenkörbe, Versandoptionen und die Steuerberechnung im Checkout.
• Zahlungen: Zahlungsmethoden, Autorisierungen und Erstattungen.
• Suche und Merchandising: der Suchindex, Synonyme, Ranking- und Boosting-Regeln.
• Content: Landingpages, Banner, Kaufberater und andere redaktionelle Seiten.
• Auftragsverwaltung: Bestellungen, Bestandszuteilung über Lager hinweg, Fulfillment und Retouren.
• Kundenkonten: Logins, Adressen, B2B-Firmenkonten und Treuepunktestände.

Eine PBC ist nicht dasselbe wie ein Microservice. Checkout ist eine PBC, weil es ein vollständiges Geschäftsergebnis liefert; die Adressvalidierung im Checkout ist ein Microservice. Eine PBC kann mehrere Microservices enthalten, und ein Anbieter kann mehrere PBCs verkaufen.

MACH, Buchstabe für Buchstabe

MACH ist das Label, das die meisten Composable-Anbieter für die technischen Prinzipien hinter ihren Produkten verwenden. Gefördert wurde es von der MACH Alliance, die im Juni 2020 von commercetools, Contentstack, EPAM Systems und Valtech gegründet wurde, und es steht für „Microservices based, API-first, Cloud-native SaaS and Headless“ (Gilbane).

• M für Microservices: Jede Funktion wird als Reihe kleiner Services gebaut, die jeweils in einem eigenen Prozess laufen und über schlanke APIs kommunizieren, so die Definition von Martin Fowler und James Lewis aus dem Jahr 2014 (Martin Fowler). In unserem Eintrag zur Microservices-Architektur liest du, wie das im Commerce gilt.
• A für API-first: Jede Funktion ist über eine dokumentierte API verfügbar, bevor darauf eine Benutzeroberfläche gebaut wird.
• C für Cloud-native SaaS: Der Anbieter hostet, skaliert und aktualisiert den Service; du nutzt ihn, statt ihn zu installieren.
• H für Headless: keine eingebaute Storefront; das Frontend ist eine separate Anwendung.

MACH beschreibt Komponenten, Composable beschreibt, wie du sie zusammensetzt. Ein Stack kann composable sein, ohne dass jeder Teil MACH ist. Viele Composable-Setups behalten ein On-Premise-ERP oder ein älteres Lagersystem und kapseln es mit einer API. Unser Eintrag zur MACH-Architektur behandelt die Zertifizierungsseite.

Was es dir bringt, Komponenten einzeln auszutauschen

Das Argument für Composable Commerce beruht auf einigen konkreten Vorteilen. Sie sind real, aber jeder hängt von der weiter unten beschriebenen Integrationsarbeit ab.

• Eine schwache Funktion ersetzen, ohne Replatforming. Wenn die Onsite-Suche an technischen Teilenummern scheitert, wechselst du die Suchkomponente und lässt Checkout, Bestellungen und Storefront in Ruhe.
• Ein Spezialist pro Aufgabe. Ein B2B-Händler kann eine Pricing-Engine ergänzen, die Preislisten pro Händler abbildet, was viele All-in-one-Plattformen nur über Apps abdecken.
• Getrennte Release-Zyklen. Das Frontend-Team kann eine neue Produktseite ausliefern, ohne auf ein Backend-Release zu warten, und umgekehrt.
• Skalieren, wo die Last entsteht. Mit Cloud-native-SaaS-Komponenten skaliert der Anbieter Suche oder Storefront für eine Verkaufsspitze, ohne dass du Server für den ganzen Stack dimensionieren musst.

Headless oder Composable Commerce und die hybride Mitte

Die Trennung des Frontends haben wir in Was ist Headless Commerce behandelt. Der kurze Unterschied: Headless verschiebt eine Grenze, zwischen Storefront und Backend. Composable verschiebt viele, innerhalb des Backends. In der Praxis landen Händler in einem von vier Setups:

• All-in-one-Plattform: Ein Anbieter betreibt Storefront, Katalog, Checkout und Bestellungen; zusätzliche Funktionen kommen aus dem App Store der Plattform.
• Headless auf einer Plattform: ein eigenes Frontend auf einem einzigen Commerce-Backend.
• Hybrid oder modular: Eine Commerce-Plattform bleibt der Kern, und ein oder zwei Funktionen, oft Suche, Content oder Produktinformationen, kommen von spezialisierten Tools.
• Komplett composable: Das Backend selbst besteht aus PBCs verschiedener Anbieter, mit einem Headless-Frontend und einer Integrationsschicht dazwischen.

Die hybride Mitte ist selbst bei großen Unternehmen verbreitet. In einer Umfrage, die Shopify mit IDC unter über 1.000 Großunternehmen durchführte, hatten 45 % „a composable front end with a full-stack back end“, also ein Composable-Frontend mit einem Full-Stack-Backend (Shopify). Die Umfrage betrifft Großunternehmen, nicht Händler im Mittelstand, die meist weniger Entwickler haben, um ein komplett composables Backend zu betreiben.

Wem welche Daten in einem Composable-Stack gehören

Die wichtigste Designentscheidung ist nicht, welche Anbieter du wählst, sondern welches System für jede Datenart die maßgebliche Quelle ist. Nimm eine Outdoor-Marke aus dem Mittelstand mit 4.000 SKUs, Webshops in drei Ländern, einem B2B-Portal für Händler und zwei Marketplaces:

Die Regel hinter der Tabelle: Jedes Feld wird an einer Stelle geschrieben und überall sonst gelesen. Wenn PIM und Commerce-Plattform beide Produkttitel bearbeiten können oder das CMS eine eigene Kopie einer Produktbeschreibung hält, laufen die Versionen auseinander und niemand weiß, welche stimmt. SKU und GTIN werden zu den Verknüpfungsschlüsseln zwischen den Systemen, also müssen sie eindeutig und stabil sein.

Wann Composable Commerce zu einem Händler im Mittelstand passt

Shopify selbst rät, Composable sei „probably not right for you“, also wahrscheinlich nichts für dich, es sei denn, du bist digital reif, hast ein erfahrenes Entwicklungsteam und komplexe Anforderungen an die Auslieferung. Für einen Händler im Mittelstand helfen diese Signale bei der Entscheidung.

Signale, die für Composable-Komponenten sprechen

• Eine Funktion deiner aktuellen Plattform blockiert Umsatz, und keine App löst das, zum Beispiel B2B-Preislisten pro Händler oder Suche über 40.000 technische SKUs.
• Du verkaufst über mehrere Frontends (Webshops pro Land, ein B2B-Portal, Kiosks), die Produkte, Preise und Bestand teilen müssen.
• Du hast Entwickler im Haus oder eine Agentur mit langfristigem Vertrag und jemanden, der die Integrationsschicht verantwortet.
• Dein Produktdatenmodell ist bereits sauber: typisierte Attribute, echte Varianten, eine SKU pro verkaufbarem Artikel.

Signale, die für eine Plattform mit wenigen spezialisierten Tools sprechen

• Dein Team ändert den Shop vor allem über Admin-Oberflächen und Apps, ohne Entwickler in Bereitschaft.
• Deine Wachstumsprobleme sind Traffic, Sortiment oder Produktinhalte, nicht Grenzen der Plattform.
• Du betreibst ein oder zwei Shops in wenigen Sprachen, und die Plattform deckt Checkout, Zahlungen und Bestellungen gut ab.
• Dein Katalog hat noch Lücken wie fehlende Attribute, Lieferantentexte und uneinheitliche Einheiten. Systeme aufzuteilen, würde diese Lücken auf mehr Stellen verteilen.

Viele Händler in der zweiten Gruppe profitieren trotzdem von einem Composable-Schritt: Produktinformationen aus dem Shop-Admin in ein PIM zu holen, das jeden Kanal speist. Das bringt den Großteil der Datenvorteile, ohne den Checkout neu zu bauen.

Die laufenden Kosten, die ein Composable-Business-Case gern weglässt

Lizenzgebühren pro Komponente lassen sich leicht auflisten. Diese Kosten nicht, und sie fallen an, solange der Stack existiert:

• Aufbau und Pflege der Integrationen: Jede Verbindung zwischen Komponenten ist Code, den jemand schreiben, testen und anpassen muss, wenn eine Seite ihre API ändert.
• Monitoring über Anbieter hinweg: Wenn eine Bestellung fehlschlägt, musst du sie durch Storefront, Checkout, Zahlungen und Auftragsverwaltung verfolgen, jeweils mit eigenen Logs.
• Änderungen an API-Versionen: Anbieter kündigen API-Versionen nach ihrem Zeitplan ab, nicht nach deinem.
• Daten-Mapping: Jede Komponente hat ihr eigenes Modell für Produkte, Preise und Kunden, und jemand pflegt das Mapping dazwischen.
• Anbietermanagement: mehr Verträge, mehr Verlängerungen, mehr Sicherheitsprüfungen.
• Kompetenzen: Composable braucht Leute, die das ganze System verstehen, nicht nur ein Tool. Shopify weist darauf hin, dass sich bei mehreren Anbietern Wartungs- und Updatekosten schnell summieren können.

Das PIM als Produktfunktion, die jede andere Komponente liest

In einem Composable-Stack ist Produktinformation eine eigene Funktion. Storefront, Suche, Marketplaces, Feeds, B2B-Portal und CMS lesen alle daraus. Das erhöht die Anforderungen an das PIM:

• Ein klares Datenmodell: Produktfamilien, typisierte Attribute mit Einheiten, Varianten und Beziehungen, damit jeder Abnehmer dieselbe Struktur liest.
• Validierung vor der Veröffentlichung: Vollständigkeits- und Formatregeln pro Kanal, damit Suche und Feeds keine halbfertigen Produkte indexieren.
• APIs und Events: eine API zum Lesen und Schreiben sowie Change-Events oder Webhooks, damit Suchindizes und Storefront-Caches aktualisiert werden, wenn sich ein Produkt ändert. Unser Eintrag zur ereignisgesteuerten Architektur erklärt das Muster.
• Kanalspezifische Ausgaben: dasselbe Produkt mit kurzem Titel für einen Marketplace, langer Beschreibung für den Webshop und anderem Attributnamen für einen Feed.
• Lokalisierung: übersetzte Texte und lokalisierte Attributwerte für jeden Markt.
• Stabile Identifikatoren: SKU und GTIN bleiben eindeutig, weil jedes andere System darüber verknüpft.

Ein PIM für diese Rolle wird oft Headless PIM genannt: Es hat eine Bearbeitungsoberfläche für das Content-Team, aber seine Ausgabe wird per API abgerufen, statt in einem eigenen Storefront angezeigt zu werden.

Diese Funktion aufzubauen, ist meist der erste Schritt einer Composable-Roadmap, nicht der letzte, weil jede spätere Komponente davon abhängt. Unser PIM-Implementierungsplan behandelt dieses Projekt Schritt für Schritt.

Schritt für Schritt zu Composable, eine Funktion nach der anderen

Ein Big-Bang-Replatforming auf einen komplett composablen Stack ist der riskanteste Weg. Für Teams im Mittelstand funktioniert ein schrittweiser Weg besser:

Fünf Wege, wie Composable-Projekte zum verteilten Monolithen werden

1. Komponenten, die sich eine Datenbank teilen. Wenn Suche und Checkout dieselben Tabellen lesen, kannst du eine nicht ändern oder ersetzen, ohne die andere kaputtzumachen.
2. Lange Ketten synchroner Aufrufe. Wenn die Produktseite auf die Suche wartet, die auf die Preise wartet, die auf den Bestand wartet, legt ein langsamer Service die ganze Seite lahm.
3. Zwei Systeme bearbeiten dasselbe Feld. Produkttitel, die sowohl im PIM als auch im Commerce-Admin bearbeitet werden, laufen innerhalb von Wochen auseinander.
4. Glue Code, für den niemand zuständig ist. Integrationen, die für den Launch geschrieben und nie einem Team zugeordnet wurden, brechen bei der ersten API-Änderung.
5. Komponenten kaufen, bevor die Datenverantwortung geklärt ist. Ohne maßgebliche Quelle pro Feld fügt jedes neue Tool eine weitere Kopie des Katalogs hinzu.

WISEPIM in einen hybriden Commerce-Stack einbinden

WISEPIM deckt die Funktion Produktinformationen ab. Es importiert deinen Katalog, füllt fehlende Beschreibungen, Attribute, Übersetzungen und Kategorien per AI, prüft die Vollständigkeit mit Quality Guard und überträgt das Ergebnis per Plattform-Sync an Shopify, WooCommerce, Magento 2, Lightspeed eCom, CCV Shop, Kaufland, Google Merchant Center und andere verbundene Kanäle. Mit optionalem Auto-Sync erreicht ein gespeichertes Produkt diese Kanäle etwa 30 Sekunden später; geplante Importe und Exporte laufen über Automatisierungen mit stündlichem, täglichem, wöchentlichem oder monatlichem Trigger. Teams, die bereits Akeneo nutzen, können es als Quelle anbinden.

Wenn du einen modularen Stack in Betracht ziehst, fang mit der Produktfunktion an: Importiere deinen Katalog im kostenlosen Plan (bis zu 100 Produkte) und sieh dir an, welche Felder jede andere Komponente brauchen würde, bevor du dich für einen einzigen Anbieter entscheidest.