MACH-Architektur in SAP Commerce Cloud: Was sie in der Praxis bedeutet

MACH steht für Microservices, API-first, Cloud-native und Headless. Auf einer Folie sind das vier Kästchen. In einem Projekt sind es Entscheidungen, und SAP Commerce Cloud geht mit jedem der vier Prinzipien anders um. Wer weiss, wo die Grenze verläuft, trifft Architekturentscheide nicht auf Basis von Anbieterfolien.

Kurz gesagt: Die Commerce Cloud ist ein Hybrid. Drei Prinzipien sind eingebaut, das vierte kommt über Erweiterungen.

Kurzfassung: SAP Commerce Cloud erfüllt API-first (OCC-REST-APIs), Cloud-native (eine Plattform, die SAP für Sie betreibt) und Headless (Composable Storefront oder ein eigenes Frontend). Das Backend ist eine einzige Java-Anwendung und damit nicht microservices-basiert; SAP empfiehlt, neue eigene Logik als Side-by-Side-Erweiterung auf SAP BTP zu bauen. Für die meisten B2B-Projekte reicht dieser Hybrid. Setzen Sie auf API-first und Headless, nehmen Sie Cloud-native als gegeben und ergänzen Sie Microservices nur dort, wo eine konkrete Anforderung sie verlangt.

Wofür steht MACH?

MACH umfasst vier Prinzipien, die von der MACH Alliance vorangetrieben werden:

• Microservices: Geschäftslogik, aufgeteilt in kleine, unabhängig deploybare Dienste
• API-first: jede Funktion zuerst über klar definierte APIs verfügbar, vor jeder Benutzeroberfläche
• Cloud-native: für den Cloud-Betrieb gebaut, mit automatischer Skalierung, Ausfallsicherheit und gemanagten Diensten
• Headless: Frontend vom Backend entkoppelt, Kommunikation nur über APIs

Das ist kein Alles-oder-nichts. Eine Plattform kann bei einigen Prinzipien stark und bei anderen schwächer sein. Welche Mischung Sie brauchen, zählt mehr als jedes Abzeichen auf einer Anbieter-Website. Die Geschäftsfrage, wann sich das Zusammensetzen spezialisierter Dienste überhaupt lohnt, beantwortet unser Leitfaden zu Composable Commerce im B2B.

M wie Microservices: ein Hybrid

Das Backend der Commerce Cloud ist eine einzige Java-Anwendung. Warenkorb, Checkout, Preisfindung, Suche und Auftragsverwaltung laufen im selben Prozess, und Sie deployen die Plattform als Einheit, nicht Modul für Modul.

Microservices gibt es rundherum:

• Side-by-Side-Erweiterungen auf SAP BTP. Der von SAP empfohlene Weg für neue eigene Logik: als eigenständigen Dienst auf SAP BTP bauen (Kyma-Runtime oder Cloud Foundry) und über APIs aufrufen, statt den Kern zu erweitern.
• Dienste von Drittanbietern. Zahlung, Steuern, Suche oder Personalisierung laufen als unabhängige Dienste, die die Commerce Cloud aufruft.

In der Praxis können Sie Commerce-Module nicht einzeln deployen, gewinnen aber Erweiterbarkeit über externe Dienste. Für die meisten B2B-Implementierungen genügt das, und der gemeinsame Kern hat einen Vorteil: Kontraktpreise, Promotionen und der Bestellablauf bleiben an einem Ort konsistent. Wo der Kern ein Projekt wirklich einschränkte, war die Antwort in unserer Arbeit jedes Mal dieselbe: genau diese Fähigkeit auf BTP neben der Commerce Cloud bauen.

A wie API-first: das stärkste Prinzip

Die OCC-REST-APIs (Omni Commerce Connect) stellen Produkte, Kategorien, Warenkörbe, Checkout, Bestellungen, Kunden, Suche und CMS-Inhalte bereit. Der Composable Storefront spricht ausschliesslich über sie mit der Commerce Cloud, der beste Beleg dafür, dass sie vollständig genug sind, um einen ganzen Shop zu betreiben. SAP dokumentiert die erweiterungsbasierte OCC-Architektur auf SAP Help.

Was die Schicht in Projekten brauchbar macht:

• breite Abdeckung der Commerce-Vorgänge, B2B inbegriffen
• erweiterbar: eigene Endpunkte kommen über eigene Extensions dazu
• OpenAPI-Spezifikationen und Authentifizierung mit OAuth 2.0
• jede Frontend-Technologie kann sie nutzen

Eine Einschränkung: Manche Administrations- und Konfigurationsaufgaben brauchen weiterhin das Backoffice. Die API-Oberfläche ist für Commerce gebaut, nicht für die vollständige Systemverwaltung.

C wie Cloud-native: von SAP betrieben

SAP Commerce Cloud läuft auf einer Infrastruktur, die SAP für Sie betreibt. Konkret heisst das:

• automatische Skalierung mit dem Traffic
• ein eingebautes CDN für statische Inhalte und Medien
• Deployments über das Cloud Portal, ohne direkten Serverzugriff
• getrennt bereitgestellte Umgebungen und unveränderliche Build-Artefakte
• Logs und Metriken im Portal
• Sicherheitspatches und kumulative Update-Releases von SAP

Der Preis ist Kontrolle. Sie können die Datenbank-Engine nicht wählen, die JVM nicht über das von SAP Erlaubte hinaus abstimmen und keine Regionen nutzen, die SAP nicht anbietet. Für die meisten Commerce-Lasten ist das unerheblich, für einige Sonderfälle nicht. Seit die Mainstream-Wartung für das On-Premise-Produkt am 31. Juli 2026 endete (SAP Help), führt der Weg für SAP Commerce in die Cloud; unser Beitrag dazu, was nach dem Ende des On-Premise-Supports zu tun ist, zeigt die Optionen.

H wie Headless: eingebaut

Der Composable Storefront (früher Spartacus) ist das Angular-basierte Headless-Frontend von SAP (SAP Help). Er spricht nur über OCC mit der Commerce Cloud, und Storefront und Backend werden unabhängig deployt: Sie liefern ein Angular-Update aus, ohne das Java-Backend anzufassen.

Was Headless ermöglicht:

• jedes Frontend-Framework (Angular, React, Vue, Next.js)
• dieselben APIs für Web, mobile Apps, Kioske und Partnerportale
• Storefront-Releases unabhängig von Backend-Releases
• serverseitiges Rendering für Tempo und Suchmaschinen

Oft übersehen: Auch im Headless-Betrieb verwaltet SmartEdit weiterhin den Seitenaufbau. Content-Verantwortliche legen Seiten, Slots und Komponenten in SmartEdit an, und der Composable Storefront stellt sie dar. Das Marketing ändert Layouts ohne Entwickler. Wer React oder Next.js vorzieht, findet die Abwägungen in unserem Vergleich Composable Storefront vs. React/Next.js. Distrelec ist eine Referenz für den Headless-Weg: Nachdem wir das Frontend entkoppelt hatten, sank die Time-to-Market für Frontend-Änderungen um 70 %.

Sollten Sie voll auf MACH setzen?

Nicht unbedingt. MACH ist ein Satz von Prinzipien, kein Glaubensbekenntnis. Die nützliche Frage lautet, welche Prinzipien Ihre konkreten Probleme lösen.

API-first und Headless lohnen sich fast immer. Sie geben Ihnen Freiheit im Frontend und eine saubere Integrationsstrategie, auch in Richtung ERP.

Cloud-native ist bei SAP Commerce heute gesetzt.

Microservices ist das Feld, auf dem Pragmatismus am meisten zählt. Das einheitliche Backend funktioniert für die meisten Implementierungen gut. Brauchen Sie für eine Fähigkeit unabhängiges Deployment oder eigene Datenspeicher, bauen Sie sie auf BTP neben der Commerce Cloud. Versuchen Sie nicht, die Plattform selbst zu zerlegen.

Wenn Sie das gegen andere Plattformen abwägen, betrachtet unser Vergleich von SAP, Salesforce und Adobe Commerce die Architekturen nebeneinander. Oder sprechen Sie mit unseren Commerce-Architekten über Ihr Setup.

Häufig gestellte Fragen

Ist SAP Commerce Cloud eine MACH-Plattform?

Zum Teil. Sie erfüllt drei der vier Prinzipien gut: API-first über die OCC-REST-APIs, Cloud-native als von SAP betriebene Plattform und Headless über den Composable Storefront oder ein eigenes Frontend. Das Backend ist eine einzige Java-Anwendung und erfüllt das Microservices-Prinzip daher nicht; die Antwort von SAP sind Side-by-Side-Erweiterungen auf SAP BTP.

Was ist der Unterschied zwischen MACH und Composable Commerce?

MACH beschreibt, wie die Technologie gebaut ist: Microservices, APIs zuerst, Cloud-nativer Betrieb, entkoppeltes Frontend. Composable Commerce ist die Strategie, spezialisierte Dienste zu einer Commerce-Plattform zusammenzusetzen. Für Composable brauchen Sie Bausteine nach MACH-Art, aber sie zu nutzen macht Sie noch nicht composable.

Kann ich auf SAP Commerce Cloud ein Frontend ohne Angular bauen?

Ja. Die OCC-APIs sind technologieneutrale REST-Endpunkte, React, Vue, Next.js oder Svelte funktionieren also ebenso wie der Angular-basierte Composable Storefront von SAP. Sie verzichten auf die vorgefertigten Storefront-Komponenten von SAP und gewinnen volle Kontrolle über das Frontend, samt dessen Pflege.

Verbessert eine MACH-Architektur die Performance?

Sie kann. Ein Headless-Frontend erlaubt serverseitiges Rendering und Edge-Caching, und eine gemanagte Cloud-Plattform skaliert mit dem Traffic. Das Risiko ist eine zu feine Zerlegung: Viele Dienste, die sich gegenseitig aufrufen, erzeugen Latenz, die eine gut abgestimmte Einzelplattform vermeidet. Messen Sie die wichtigen Kaufabläufe vor und nach einer Änderung.

Ändert MACH die Kosten von SAP Commerce Cloud?

Die Plattformlizenz hängt nicht von der gewählten Architektur ab. Implementierungs- und Betriebskosten schon: Eigene Dienste auf SAP BTP oder ein eigenes Frontend bringen Bau- und Pflegeaufwand. Für viele Projekte ist die Standardplattform mit dem Composable Storefront der wirtschaftlichere Start.