Wir prüfen, welcher Ansatz zu uns passt.
Monolith, Headless oder Composable: Die Entscheidung hängt an Ihrem Vorhaben, nicht an der Technologie.
Composable Commerce – Architektur, die Ihren Prozessen folgt
Wir bauen modulare Commerce-Plattformen auf commercetools – verankert in Ihren Geschäftsprozessen, vernetzt mit Daten und KI, vorausgedacht für Ihr Wachstum. B2C, B2B und D2C für Retail und Industrie im DACH-Raum. Vom Zielbild bis zum laufenden Betrieb.
Wo stehen Sie gerade?
Wir planen den Aufbau.
Sie wollen wissen, wie ein solches Projekt geschnitten wird und wann was fertig ist.
Wir haben eine Plattform, die nicht trägt.
Der Stack ist modular, aber Releases dauern, Integrationen sind brüchig, Kosten laufen weg.
Was Composable Commerce bedeutet
Composable Commerce ist ein Architekturansatz, bei dem Commerce-Engine, Content-Management, Suche, Zahlungsabwicklung und weitere Funktionen als eigenständige, über APIs verbundene Dienste betrieben werden. Jeder Baustein wird einzeln ausgewählt, einzeln deployt und einzeln ersetzt. Das Gegenmodell ist der Monolith, bei dem jede Änderung ein Deployment des Gesamtsystems auslöst.
Der Wert liegt nicht in der Modularität. Er liegt darin, dass Änderungen an einer Stelle nicht das Ganze berühren: Releases werden kleiner und häufiger, der zweite Markt kostet weniger als der erste, ein neuer Kanal kommt ohne Systemumbau dazu.
Die MACH Alliance beschreibt den Ansatz inzwischen nicht mehr über die vier Buchstaben, sondern über drei Eigenschaften: Open. Composable. Connected. Weg von der Technologie-Checkliste, hin zur Frage, ob eine Architektur anschlussfähig bleibt.
Diese Frage ist gerade bei KI entscheidend. Im Enterprise Technology Report 2026 der MACH Alliance, einer Befragung von 600 Technologie-Entscheidern in sieben Märkten, berichten 78 Prozent der Unternehmen mit vollständig ausgerollter Composable-Architektur von messbarem ROI ihrer KI-Investitionen – gegenüber 13 Prozent derjenigen, die noch planen. KI-Vorhaben scheitern selten am Modell. Sie scheitern daran, dass die Daten nicht erreichbar sind.
- Bausteine einzeln austauschbarCommerce-Engine, CMS, Suche und Payment laufen als eigenständige Dienste, verbunden über APIs
- Releases ohne SystemumbauÄnderungen an einer Stelle berühren nicht das Ganze – kleinere Releases, häufiger ausgeliefert
- Der zweite Markt kostet wenigerLänder, Marken und Mandanten werden konfiguriert, nicht kopiert
- Anschlussfähig für neue KanäleNeue Touchpoints und KI-Agenten binden an bestehende APIs an, ohne die Plattform umzubauen
Was Composable möglich macht
Die drei Ansätze unterscheiden sich nicht in ihrer technischen Eleganz, sondern darin, was sie Ihnen im Alltag erlauben.
| Was Sie vorhaben | Monolith | Headless | Composable auf commercetools |
|---|---|---|---|
| Einen neuen Markt oder eine neue Marke ausrollen | Neues Projekt | Neues Frontend, Backend-Grenzen bleiben | Konfiguration statt Kopie |
| Kampagnen und Inhalte ändern | Zum Release-Termin | Zum Release-Termin | Jederzeit, ohne Deployment |
| Suche, Loyalty oder Payment frei wählen | Was mitgeliefert wird | Was mitgeliefert wird | Freie Wahl je Baustein |
| Preise und Konditionen aus dem ERP nutzen | Nachbauen und synchron halten | Nachbauen und synchron halten | Anbinden, ERP bleibt führend |
| Ein zweites Frontend ergänzen, etwa ein Partnerportal | Eigene Anwendung daneben | Eigene Anwendung daneben | Zusätzliche Storefront auf gleichem Backend |
| KI-Anwendungsfälle produktiv bringen | Datenwege fehlen | Teilweise offen | Daten über APIs verfügbar |
| In fünf Jahren einen Baustein ersetzen | Neues Projekt | Backend-Projekt | Baustein tauschen |
Der Unterschied zeigt sich selten am Tag des Launches. Er zeigt sich beim zweiten Markt, beim dritten Kanal und bei der ersten Anforderung, die beim Bau der Plattform noch niemand kannte.
Wofür Composable die richtige Antwort ist
Composable spielt seine Stärken dort aus, wo Komplexität real ist und sich nicht wegvereinfachen lässt. Treffen drei oder mehr der folgenden Punkte zu, rechnet sich der Ansatz.
- Mehrere Märkte, Marken oder MandantenHeute oder auf der Roadmap
- Preislogik im ERPPreise und Konditionen leben im ERP und sollen dort bleiben
- Mehr als ein FrontendShop, Partnerportal, App, Marktplatz-Anbindung
- Fachbereiche ohne Release-BindungInhalte und Kampagnen sollen unabhängig von Deployment-Terminen laufen
- Spezialisierte AnforderungenFür Suche, Loyalty oder Konfiguration gibt es bessere Systeme als das Plattform-Modul
- KI-Vorhaben mit ProduktionszielAnwendungsfälle sollen in Produktion gehen und nicht im Pilot bleiben
Und wo ein anderer Weg schneller trägt
| Ihre Situation | Der schnellere Weg |
|---|---|
| Ein Markt, ein Sortiment, stabile Anforderungen | Ein integriertes System – dauerhaft wirtschaftlicher |
| Ein konkretes Symptom, etwa eine schwache Suche | Eine gezielte Einzelmaßnahme im Bestand |
| Altsystem läuft aus der Wartung, die Architektur trägt aber noch | Replatforming ohne Architekturwechsel |
| Produktdaten noch nicht belastbar | Datenfundament zuerst, Plattform danach |
In welche Zeile Ihr Vorhaben fällt, klärt ein Gespräch. Dafür braucht es kein Angebot.
Wie foobar Agency Composable Commerce baut
Wir bauen Composable Commerce auf commercetools. Partner seit 2019 – und alle Composable-Commerce-Projekte, die wir in den vergangenen Jahren gestartet haben, laufen auf dieser Plattform.
Ergänzt wird aus einem festen Repertoire: Hygraph, Storyblok oder Contentful für Content, Algolia oder FactFinder für Suche, Next.js für die Storefront, Vercel und Fastly für Delivery. Betrieben wird auf der Cloud, die Sie mitbringen – AWS, Google Cloud oder Azure. Wir passen uns Ihrer Cloud-Strategie an, nicht umgekehrt.
Capability Mapping vor der Systemauswahl
Bevor über Systeme entschieden wird, ordnen wir jede Anforderung der Ebene zu, auf der sie gelöst wird. Vier Kategorien:
| Zuordnung | Bedeutung |
|---|---|
| Standard | Von der Plattform abgedeckt |
| Konfiguration | Mit Plattformmitteln abbildbar |
| Erweiterung | Eigenentwicklung, Aufwand geschätzt |
| Andere Ebene | Gelöst in ERP, PIM oder Fachsystem – keine Lücke in der Gesamtlösung |
Das Ergebnis ist eine Matrix über alle Anforderungen. Sie zeigt, wo Aufwand entsteht und wo nicht, und welche Anforderungen die Systemauswahl tatsächlich treiben. Scope, Schätzung und Architekturentscheidungen bauen darauf auf – nachvollziehbar, Zeile für Zeile.
Unser Ansatz
Fünf Prinzipien in der Umsetzung
Right-Sizing
Der Zuschnitt folgt der Anforderung, nicht dem Katalog. Ein Enterprise-OMS für überschaubares Fulfillment kostet ebenso Geld wie eine fehlende Suche bei sechsstelligem Katalog.
Re-use first
Wir bauen nicht auf der grünen Wiese. Bestehende Systeme, Services und Muster in Ihrer Landschaft werden wiederverwendet, ergänzt wird gezielt.
Integrationen zuerst
ERP-Integrationen entscheiden über den Zeitplan. Sie stehen bei uns am Anfang der Umsetzung, validiert durch einen Integrations-Spike, der Schnittstellen, Datenqualität und Aktualisierungsfrequenzen prüft, bevor der Plan darauf aufbaut.
Konfigurieren statt duplizieren
Länder-, Marken- und Mandantenunterschiede laufen über Feature Flags und zentrale Einstellungen, nicht über kopierte Codebasen.
Nichts wegwerfen
Datenmodelle und Schnittstellen werden so geschnitten, dass spätere Erweiterungen ohne Umbau möglich sind. In der Konzeption kostet das Stunden, im Betrieb spart es Wochen.
Vier Phasen bis zur laufenden Plattform
Klar abgegrenzte Phasen mit definierten Ergebnissen. Die frühen Phasen bieten wir zum Festpreis an.
Phase 1 · Architektur-Review
Für Unternehmen, die bereits eine Composable- oder Headless-Plattform betreiben. Acht Prüfbereiche: Systemlandschaft und Datenflüsse, Code- und Implementierungsqualität, Frontend- und Integrationsebene, Backend- und Servicelandschaft, Content-Architektur mit Rollen- und Rechtemodell, Infrastruktur und Operations, Security und Datenschutz, Entwicklungsprozesse.
Wir prüfen nicht nur Dokumentation und Architectural Decision Records, sondern die tatsächlich implementierte Architektur: Codebasis, Konfigurationen, Pipelines, Monitoring. Wo Diagramme fehlen oder veraltet sind, erstellen wir eigene.
Phase 2 · Discovery
Zehn moderierte Workshops mit festen Ergebnissen: Zielbild und Projektauftrag, Stakeholder und Personas, Geschäftsprozesse und Use Cases, funktionale Anforderungen, Systemlandschaft und Integrationslandkarte, nichtfunktionale Anforderungen inklusive Performance, Security und SLAs, UX-Exploration, Priorisierung nach Business Value und Komplexität mit MVP-Definition, Backlog für die ersten zwei Sprints, Sign-off.
Die Discovery endet mit einer Go/No-Go-Entscheidung und einem Backlog, aus dem am nächsten Tag entwickelt werden kann. Wir kalkulieren von realistischen Szenarien aus, nicht von Best Cases, und legen Annahmen und Abgrenzungen offen.
Phase 3 · MVP bis Release Candidate
Zweiwöchige Sprints mit cross-funktionalen Teams aus Entwicklung, QA, UX und Product Ownership. Design-Sprints laufen den Entwicklungssprints voraus. Ab zwei parallelen Streams koordiniert ein Projekt-Leadership-Board übergreifende Risiken und Abhängigkeiten.
Getestet wird früh statt am Ende: testbare Akzeptanzkriterien, automatisierte Tests bei jedem Commit und in jeder Pipeline, Regressionstests bei jedem Release.
Entwickelt wird KI-gestützt. Repetitive Implementierungsarbeit automatisieren wir – mit definierten Quality Gates und ohne dass Ihre Daten die Projektumgebung verlassen. Das verkürzt Implementierungszeiten erheblich und verschiebt Kapazität dorthin, wo Ihr Geschäft sich unterscheidet.
Phase 4 · Rollout und Betrieb
Erst ein Pilotmarkt, dann Rollout je Land oder Mandant. Vor jedem Go-live: integrierter Systemtest mit allen beteiligten Drittsystemen, Last- und Penetrationstest durch unabhängige Dritte, User-Acceptance-Test, Datenmigration mit Mapping und Validierung. Danach Hypercare und laufender Betrieb.
Erfahrungswert: Ein Composable-Neuaufbau von der Anforderungsaufnahme über Design und Architektur bis zur ERP- und PIM-Integration ist in sechs bis neun Monaten produktiv realisierbar – am unteren Ende bei eng geschnittenem Scope und belastbaren Schnittstellen. Bei mehreren Märkten und Mandanten ist der Pilotmarkt der aussagekräftigere Meilenstein als der Gesamt-Go-live.
- Phase 1 · 2 bis 4 WochenArchitektur-Review: Gesamtbewertung, priorisierte Handlungsempfehlungen mit Aufwand und Risiko, vorläufige Roadmap
- Phase 2 · 3 bis 5 WochenDiscovery: Festpreisangebot für den MVP-Scope, Kostenindikation mit Bandbreite für die Ausbaustufen, Backlog für zwei Sprints
- Phase 3 · 3 bis 4 MonateBelastbarer Release Candidate, auf dem weitergebaut wird – kein Prototyp
- Phase 4 · Rollout und BetriebPilotmarkt, dann Rollout je Land oder Mandant, danach Hypercare und laufender Betrieb
Drei Wege, den ersten Release zu schneiden
Der häufigste Fehler in Composable-Projekten ist ein MVP, der keiner ist. Es gibt drei bewährte Schnitte – welcher passt, entscheidet die Discovery.
Sortimentsschnitt
Start mit einem Teil des Sortiments. Komplexe Produkte, Variantenlogiken und Konfiguratoren bleiben zunächst außen vor. Passt, wenn sich ein tragfähiger Sortimentsteil sauber isolieren lässt.
Funktionaler Schnitt
Der Happy Path wird umgesetzt, Randfälle bewusst ausgeklammert und dokumentiert. Passt, wenn Prozesse breit, aber flach sind.
Organisatorischer Schnitt
Go-live für ausgewählte Kundengruppen, Standorte oder Vertriebspartner. Passt im B2B, wenn Rechte- und Konditionsstrukturen komplex sind und eine Teilmenge als Referenz dient.
Bausteine und Integrationsmuster
commercetools als Commerce-Engine, Headless CMS mit Hygraph, Storyblok oder Contentful, Suche und Recommendations über Algolia oder FactFinder, Storefront mit Next.js in Microfrontends geschnitten, Backend-for-Frontend zwischen Storefront und Diensten, Delivery über Vercel und Fastly, Cloud-Infrastruktur auf AWS, Google Cloud oder Azure, Identity-Management als eigenes führendes System, Integrations-Layer zu ERP und PIM sowie eine Daten- und Analytics-Ebene neben Commerce und Content.
Für den wiederkehrenden Teil setzen wir einen eigenen Accelerator ein: performantes Frontend, fertiger Backend-for-Frontend-Layer und Integrationen in Commerce-Engine, Suche und CMS – inklusive der Integrationen zwischen diesen Systemen. Das spart Commodity-Aufwand und verschiebt Budget dorthin, wo Ihr Geschäft sich unterscheidet.
Das ERP bleibt führend
Wir binden es über eine bewusst dünn gehaltene Middleware-Schicht an, nicht Punkt-zu-Punkt. Artikelstammdaten, Preise, Bestände und Kundendaten bleiben im ERP; die Middleware transformiert und routet Änderungen und gibt Bestellungen und Statusänderungen zurück. Damit muss das ERP nichts über Storefront-Belange wissen, beide Systeme bleiben unabhängig ersetzbar, und es gibt genau eine Stelle für Monitoring, Fehlerbehandlung und Wiederholungen.
Preise und Verfügbarkeiten sind zwei Aufgaben, nicht eine
Auf Listenseiten und in der Suche liefert ein dedizierter Preis-Cache-Service, asynchron nachgeladen und per Event oder Batch aktualisiert. Im Warenkorb und Checkout wird live gegen das ERP simuliert, über externe Preise und Steuern in der Commerce-Engine. Dazu gehört die Festlegung, was bei kurzzeitiger Nichtverfügbarkeit des ERP geschieht.
Daten von Anfang an
Bestell-, Kunden- und Interaktionsdaten laufen in eine zentrale Datenplattform – in der Regel Snowflake mit dbt-Modellierung –, aus der Reporting, Vorhersagen und KI-Anwendungsfälle bedient werden. Wer die Datenwege erst nach dem Launch definiert, baut sie zweimal.
- Synchrone API-AufrufeWo eine unmittelbare Antwort nötig ist: Warenkorb-Operationen, Bonitätsprüfung im Checkout, Verfügbarkeitsprüfung auf Klick
- Asynchrone EventsWo nachgelagerte Systeme reagieren: Eine Bestellung löst Fulfillment, ERP-Buchung, Loyalty-Gutschrift und Versandkommunikation aus
- Bulk-ImporteFür große Datenmengen mit festem Rhythmus: nächtliche Artikel- und Preisaktualisierungen
Betrieb
Was nach dem Launch trägt
Automatisierter Weg auf Produktion
Deployments vollautomatisiert, die Freigabe für die Produktion ein bewusster Klick, Rollback ebenfalls automatisiert. Manueller Betrieb ist teuer, nicht modularer Betrieb.
Observability
Uptime-Monitoring, Error-Tracking, Logs, Alerts. Dazu Betriebs-KPIs, die gemessen werden: Verfügbarkeit, mittlere Wiederherstellungszeit, Service-Level-Einhaltung, Zykluszeit.
Eine steuernde Stelle
In einem Best-of-Breed-Stack braucht es eine definierte Verantwortung über Systemgrenzen hinweg: Wer erkennt einen Vorfall, wer klassifiziert ihn, wer koordiniert die Anbieter, wer kommuniziert an das Geschäft. Wir übernehmen diese Rolle in der Regel mit – zusammen mit Architektur, Umsetzung, Projektleitung, Testing und Betrieb.
Dokumentierte Entscheidungen
Wir arbeiten in Ihren Systemen. Architectural Decision Records halten fest, warum etwas so gebaut wurde. Damit bleibt das Wissen bei Ihnen, auch für die Person, die in zwei Jahren die nächste Entscheidung trifft.
Composable-Architekturen in Retail und Industrie
Häufig gestellte Fragen
Composable Commerce ist ein Architekturansatz, bei dem Commerce-Engine, Content-Management, Suche, Zahlungsabwicklung und weitere Funktionen als eigenständige, über APIs verbundene Dienste betrieben werden. Jeder Baustein wird einzeln ausgewählt, deployt und ersetzt. Das Gegenmodell ist der Monolith, bei dem jede Änderung ein Deployment des Gesamtsystems auslöst.
Headless trennt das Frontend vom Backend – das Backend bleibt monolithisch. Composable zerlegt auch das Backend in austauschbare Dienste. Headless ist eine Frontend-Entscheidung, Composable eine Architekturentscheidung. Ein Headless-Setup auf einem Monolithen bringt ein modernes Frontend, aber keine Ablösbarkeit einzelner Funktionen.
Nein, die beiden Begriffe beschreiben unterschiedliche Dinge. Unified Commerce ist ein Ziel: ein konsistentes Erlebnis über alle Kanäle, mit einer gemeinsamen Sicht auf Kunde, Bestand und Bestellung. Composable ist die Architektur, mit der sich dieses Ziel erreichen lässt – und mit der es auch dann noch trägt, wenn Kanäle, Märkte oder Anforderungen sich verschieben.
Für Unternehmen mit mehreren Märkten, Marken oder Mandanten, mit Preis- und Konditionslogik im ERP, mit mehr als einem Frontend oder mit KI-Vorhaben, die produktiv gehen sollen. Bei einem Markt, einem Sortiment und stabilen Anforderungen ist ein integriertes System dauerhaft wirtschaftlicher.
commercetools. Wir sind seit 2019 Partner, und alle Composable-Commerce-Projekte, die wir in den vergangenen Jahren gestartet haben, laufen auf dieser Plattform. Für Vorhaben mit klar umrissenem Scope und kurzer Time-to-Market implementieren wir auch Shopify Plus – das ist dann allerdings kein Composable-Setup, sondern eine bewusst andere Entscheidung.
Auf der, die Sie mitbringen. Wir arbeiten auf AWS, Google Cloud und Azure und richten uns nach Ihrer Cloud-Strategie, Ihren bestehenden Verträgen und Ihren Compliance-Vorgaben. Für Storefront-Delivery und Edge-Caching setzen wir Vercel und Fastly ein.
Ein erster belastbarer Release Candidate ist in drei bis vier Monaten realistisch. Ein vollständiger Aufbau inklusive Anforderungsaufnahme, Design, Architektur sowie ERP- und PIM-Integration liegt bei sechs bis neun Monaten. Bei mehreren Märkten, Währungen und Mandanten entsprechend länger. Unser KI-gestützter Entwicklungsprozess verkürzt diese Zeiten erheblich: Repetitive Implementierungsarbeit wird automatisiert, mit definierten Quality Gates und ohne dass Kundendaten die Projektumgebung verlassen.
Die Gesamtkosten setzen sich aus Lizenzen für Commerce-Engine und Peripherie, Integrationsaufwand, Frontend-Entwicklung, Datenmigration und Betrieb zusammen. Die größten Treiber sind der Zustand der Quellsysteme und die Datenqualität – deshalb entstehen belastbare Zahlen erst nach der Discovery, und die bieten wir zum Festpreis an.
Über eine bewusst dünn gehaltene Middleware-Schicht, nicht Punkt-zu-Punkt. Das ERP bleibt führendes System für Artikelstammdaten, Preise, Bestände und Kundendaten. Die Middleware transformiert und routet Änderungen und gibt Bestellungen und Statusänderungen zurück. So bleiben beide Systeme unabhängig ersetzbar, und Monitoring und Fehlerbehandlung liegen an einer Stelle.
Getrennt nach Anwendungsfall. Auf Listenseiten und in der Suche über einen dedizierten Preis-Cache-Service, per Event oder Batch aktualisiert. Im Warenkorb und Checkout über eine Live-Simulation gegen das ERP mit externen Preisen und Steuern. Dazu gehört die Festlegung, was bei kurzzeitiger Nichtverfügbarkeit des ERP geschieht.
Nächster Schritt
Composable Commerce auf commercetools.
Ob Neuaufbau, Replatforming oder ein Review Ihrer bestehenden Plattform: Wir beginnen mit einer Bestandsaufnahme.
Kontakt aufnehmen
Wir freuen uns auf Ihre Anfrage.
Bitte akzeptieren Sie Marketing-Cookies, um das Kontaktformular zu laden.