Teams, die eine SAP-Commerce-Cloud-Storefront modernisieren, stehen vor einer klaren Weggabelung: auf der SAP Composable Storefront (früher Spartacus) bleiben, ein vollständig eigenes Frontend auf der OCC-API bauen, oder eine Frontend Management Platform (FMP) wie Laioutr darüberlegen. Dieser Artikel vergleicht alle drei Wege direkt, ohne die Nachteile zu beschönigen.

Der Ausgangspunkt: SAP Commerce Cloud ist bereits API-First

SAP Commerce Cloud, mit seiner Hybris-Herkunft, ist eine Java-basierte Enterprise-Commerce-Plattform. Seit dem Wechsel auf eine entkoppelte Architektur spricht die Storefront ausschließlich über die OCC-REST-API (Omni Commerce Connect) mit dem Backend: Produktsuche, Warenkorb, Checkout und Kundenkonto. Diese API ist technologie-agnostisch, die Frontend-Frage ist also wirklich offen. Das Backend bleibt unverändert. Die Entscheidung lautet, welcher Frontend-Layer die beste Investition ist.

Option 1: SAP Composable Storefront (Spartacus)

Die Composable Storefront ist SAPs eigene Angular-basierte, quelloffene Headless-Storefront. Sie liefert SSR für SEO, PWA-Fähigkeiten und CMS-gesteuerte Seitenkomposition mit.

Sie ist der natürliche Standard, wenn ein Angular-Team vorhanden ist. Der Haken: Jede Anpassung über die Defaults hinaus ist Angular-Entwicklung, und Upgrade-Tretmühle, Hosting, Performance-Budget und Barrierefreiheit liegen vollständig bei euch.

Option 2: Custom Build auf der OCC-API

Ein eigenes Frontend in React, Vue oder Next.js gibt maximale Kontrolle. Die OCC-API ist gut dokumentiert und framework-agnostisch, das ist also machbar.

Der Preis ist ein mehrmonatiger Build, ein dediziertes Frontend-Team und die dauerhafte Verantwortung für alles: Hosting, CI/CD, Dependency-Updates, Core Web Vitals und Barrierefreiheit. Sinnvoll nur, wenn Frontend-Engineering eine strategische Kernkompetenz ist.

Option 3: Laioutr FMP auf der OCC-API

Laioutr setzt sich als Frontend-Layer auf die vorhandene OCC-API. Das SAP-Backend bleibt unangetastet. Du bekommst einen visuellen Editor, mehr als 70 vorgefertigte Commerce-Komponenten, EU-Hosting und ein Lighthouse-100-Performance-Ziel.

Der Vorteil ist Planbarkeit und Geschwindigkeit: kein mehrmonatiges Greenfield, keine Framework-Wartung, und Marketing-Teams komponieren Landingpages und Kampagnen ohne Engineering-Tickets. WCAG 3.0 und BFSG gehören zum Plattform-Standard, nicht zu einem separaten Audit.

Direktvergleich

• Time-to-Launch: Composable Storefront = Monate Angular-Arbeit; Custom Build = mehrere Monate; Laioutr = Wochen
• TCO Jahr 1: Composable Storefront = engineering-lastig; Custom Build = hoch; Laioutr = planbare Subscription
• Wartung: Composable Storefront und Custom = euer Team; Laioutr = plattformseitig betrieben
• Barrierefreiheit: Composable Storefront und Custom = eure Verantwortung; Laioutr = WCAG 3.0 und BFSG im Standard
• Backend-Optionalität: Custom = an OCC gebunden; Laioutr = backend-agnostisch über SAP, commercetools, Shopify und mehr

Wann welche Option gewinnt

Composable Storefront oder ein Custom Build gewinnen, wenn ihr ein starkes Angular- oder JavaScript-Team habt und Pixel-Level-Kontrolle strategische Priorität ist. Laioutr gewinnt, wenn ihr Wochen bis zum Go-live wollt, Marketing-Autonomie braucht, eingebaute EU-Compliance schätzt und euch Backend-Optionen offenhalten möchtet.

Häufige Fragen

Ersetzt Laioutr die Composable Storefront?

Es ist ein alternativer Frontend-Layer auf derselben OCC-API. Ihr könnt die Composable Storefront behalten oder stattdessen Laioutr nutzen, für schnellere Time-to-Launch und No-Code-Seitenkomposition.

Ändert sich das SAP-Backend?

Nein. Laioutr konsumiert die OCC-REST-API. Katalog, Preisfindung, Promotions und Checkout-Logik bleiben in SAP Commerce Cloud.

Wie ist der Preis im Vergleich zum Eigenbau?

Der Total Cost of Ownership liegt typischerweise niedriger, weil Hosting, Komponenten und Editor enthalten sind und kein separates Frontend-Team nötig ist. Siehe Preise oder Strategiegespräch vereinbaren.