Analyse Shop-Management

Composable Commerce: Welche Architektur wirklich zu eurem Shop passt, und welche Anbieter liefern

Composable Commerce: Welche Architektur wirklich zu eurem Shop passt, und welche Anbieter liefern

80 Prozent schneller. So viel schneller sollten Unternehmen neue Features ausrollen, wenn sie auf composable Architekturen setzen, das prophezeite Gartner im Jahr 2020. Sechs Jahre später zeigt die Bilanz: Die Prognose stimmt für einige, und sie ist für viele andere zum teuren Irrtum geworden. Composable Commerce ist keine Technologie-Frage mehr, sondern eine Reifegrad-Frage. Wer sie falsch beantwortet, zahlt doppelt: für die Migration und für den Betrieb.

Dabei ist der Markt längst erwachsen geworden. commercetools, Spryker, Shopify, Shopware, alle sprechen inzwischen die Sprache von MACH (Microservices, API-first, Cloud-native, Headless), alle verkaufen Modularität. Der Unterschied liegt nicht mehr im Marketing, sondern in Details: Integrationskosten, Team-Anforderungen, Release-Geschwindigkeit. Genau dort entscheidet sich, ob ihr nach zwei Jahren ein zukunftsfähiges System habt oder einen verteilten Monolithen mit doppeltem Budget.

Was bedeutet Composable Commerce jenseits des Marketings?

Kurz gesagt: Ihr kauft keinen Shop mehr, sondern Bausteine. Suchmaschine von Algolia, CMS von Contentful, Checkout von commercetools, PIM von Akeneo, verbunden über APIs, betrieben in der Cloud, entkoppelt vom Frontend. Das klingt nach Freiheit. In der Praxis heißt es vor allem: Ihr werdet vom Kunden zum Integrator. Jede Schnittstelle, die ein Monolith intern regelt, wird bei euch zum eigenen Verantwortungsbereich, mit Monitoring, Versionierung und Fehlerkultur inklusive.

Das ist der Punkt, den die meisten Anbieter-Pitches aussparen. Der modulare Ansatz verschiebt Komplexität, er löst sie nicht auf. Sie wandert aus der Software in eure Organisation, in eure DevOps-Prozesse, in eure Vertragslandschaft mit fünf bis zwölf Dienstleistern. Wer dafür gewappnet ist, gewinnt Geschwindigkeit. Wer nicht, baut sich ein System, bei dem ein Checkout-Ausfall erst nach drei Telefonkonferenzen einem Verantwortlichen zugeordnet werden kann.

Kernsatz: Composable Commerce tauscht ein großes Problem gegen viele kleine. Ob das ein Gewinn ist, hängt davon ab, wie gut eure Organisation viele kleine Probleme managt.

Warum scheitern Composable-Projekte an der Organisation statt an der Technik?

Die ehrliche Antwort: weil die meisten E-Commerce-Teams für ein Produkt gebaut sind, nicht für eine Plattform. Ein Team, das einen Shopware- oder Adobe-Commerce-Shop betreut, braucht Entwickler, die ein System tief kennen. Ein Composable-Setup braucht Entwickler, die viele Systeme fließend verbinden, API-Design, Event-Streaming, Infrastructure as Code, Observability. Diese Profile sind teurer und auf dem DACH-Arbeitsmarkt deutlich knapper.

Vorwerk hat den Weg vorgemacht: Der Thermomix-Shop läuft auf commercetools, flankiert von einem eigenen Frontend und klar abgegrenzten Services. Funktioniert, weil Vorwerk die dafür nötige Engineering-Organisation aufgebaut hat. Das Gegenbeispiel erleben Agenturen regelmäßig: Mittelständler mit achtstelligen Umsätzen, die auf Druck der Tech-Abteilung composable gegangen sind und nach 18 Monaten feststellen, dass ein einfacher Kategorien-Relaunch drei Dienstleister und sechs Wochen braucht. Beim Monolithen war das ein Sprint.

Es gibt eine grobe Faustregel, die sich in Projekten bewährt hat: Unter einem Engineering-Team von fünf bis acht Vollzeit-Entwicklern, fest oder über einen sehr engen Partner, ist der volle Composable-Ansatz meist Selbstüberschätzung. Ab dieser Größe dreht sich das Verhältnis: Die Abhängigkeit vom Plattform-Roadmap-Tempo eines Monolithen kostet mehr, als die Integration der Bausteine.

Die Anbieterlandschaft: Wer liefert was?

Die Auswahl ist 2026 überschaubarer, als der Markt suggeriert. Vier Positionen sind relevant:

  • commercetools bleibt der Referenz-Purist. München, gegründet 2013, konsequent API-first, kein eigenes Frontend. Lidl zählt ebenso zu den Kunden wie internationale Enterprise-Namen. Wer maximale Freiheit will und die Integrationskraft mitbringt, landet hier. Die Einstiegshürden sind real: Ohne erfahrene Systemintegratoren geht wenig.
  • Spryker besetzt die Lücke zwischen B2B-Komplexität und Modularität. Das Berliner Unternehmen hat bei Händlern wie Aldi Süd und Hilti gezeigt, dass sich Marktplatz-Modelle, Ersatzteil-Logik und B2B-Preisstrukturen sauber komponieren lassen. Für B2B-Händler mit erklärungsbedürftigen Sortimenten oft die pragmatischste Wahl.
  • Shopify mit Hydrogen und Oxygen treibt den Headless-Ansatz von unten in den Markt. Der Vorteil: Der Commerce-Kern bleibt betreut, nur das Frontend wird entkoppelt. Für D2C-Marken bis in den mittleren achtstelligen Bereich ist das der risikoärmste Einstieg in die composable Welt, mit dem Preis, dass ihr im Shopify-Ökosystem bleibt.
  • Shopware verfolgt mit der API-first-Architektur von Shopware 6 einen Mittelweg, der im DACH-Mittelstand stark ist: modular genug für echte Entkopplung, integriert genug für kleinere Teams. Wer deutschsprachigen Support, eine dichte Agenturlandschaft und planbare Kosten will, findet hier oft das beste Verhältnis aus Ambition und Alltagstauglichkeit.

Am Rand stehen Elastic Path und BigCommerce, international relevant, im DACH-Raum aber mit dünnerer Partnerlandschaft. Wer hier einsteigt, sollte prüfen, wer das System in drei Jahren noch betreuen kann, nicht nur wer es heute implementiert.

Was kostet der Umstieg wirklich, und wann rechnet er sich?

500.000 Euro und mehr müssen Enterprise-Relaunches auf composable Basis aktuell kalkulieren, Migration, Integration, Frontend-Neuaufbau, plus ein laufender Betrieb, der typischerweise 20 bis 40 Prozent über dem eines vergleichbaren Monolithen liegt. Das ist kein Argument dagegen. Es ist ein Argument für sauberes Rechnen.

Rentabel wird die Rechnung, wenn euer Geschäft von Geschwindigkeit lebt: wöchentliche statt quartalsweiser Releases, mehrere Touchpoints (Web, App, Marktplatz, B2B-Portal) auf einem Commerce-Kern, internationale Rollouts mit lokalen Besonderheiten. Wer dagegen einen Shop mit stabilen Abläufen und zwei Redesigns im Jahrzehnt betreibt, bezahlt für Flexibilität, die er nie abruft.

Die richtige Frage lautet nicht „Monolith oder Composable?“, sondern: „An welcher Stelle unserer Architektur bremst uns Abhängigkeit heute konkret aus?“

Genau deshalb setzt sich in der Praxis ein dritter Weg durch: schrittweise Komposition. Zuerst wird das Frontend entkoppelt, weil dort die Conversion-Hebel liegen. Dann vielleicht die Suche, weil sie Umsatz direkt beeinflusst. Der Commerce-Kern bleibt, bis er zum tatsächlichen Engpass wird. Dieser pragmatische Pfad fehlt in den meisten Anbieter-Broschüren, er ist aber der, den die meisten erfolgreichen Projekte der vergangenen Jahre gegangen sind.

Wie trefft ihr die Anbieterentscheidung, die ihr nicht bereut?

Drei Prüffragen trennen Bauchgefühl von belastbarer Entscheidung. Erstens: Welche Referenzen kann der Anbieter in eurer Branche und Größenklasse nennen, und dürft ihr mit denen sprechen, ohne dass der Vertrieb danebensitzt? Zweitens: Wie sieht der Exit aus? Fragt konkret, wie ihr Daten, Subscriptions und Kundenhistorie herausbekommt, wenn der Vertrag endet. Wer hier ausweicht, plant mit eurer Abhängigkeit. Drittens: Passt das Skill-Profil eures Teams zum Betriebsmodell? Ein Proof of Concept mit eurem realen Sortiment, nicht mit Demo-Daten, beantwortet das in vier Wochen ehrlicher als jede Beraterstudie.

Meine Einschätzung nach Dutzenden Gesprächen mit Betreibern: Die nächsten zwei Jahre gehören nicht dem vollständig composierten Stack, sondern dem diszipliniert komponierten. Die Gewinner werden Unternehmen sein, die genau die zwei, drei Engpässe modularisieren, an denen Flexibilität Umsatz bringt, und den Rest bewusst langweilig lassen. Wer heute einen Relaunch plant, sollte weniger über die perfekte Zielarchitektur nachdenken und mehr über die erste Komponente, die sich in zwölf Monaten bezahlt gemacht hat. Von dort aus lässt sich bauen. Vom Whiteboard aus nicht.