Headless, Composable Commerce oder MACH mit Shopware 6

Headless, Composable Commerce, Best-of-Breed, MACH: Was ist was?

Um zu verdeutlichen, was die aktuellen Begriffe in der Diskussion über die Zukunft von Systemen und Architekturen im E-Commerce genau bedeuten, ist es hilfreich, zunächst noch einmal das ursprüngliche technische Konzept eines Onlineshops nachzuzeichnen. Denn vor dem Hintergrund der sogenannten monolithischen Architektur als „Urform“ von Onlineshops wird schnell deutlich, was an den hier diskutierten Ansätzen jeweils neu und anders ist.

Monolith

Der Begriff ‚Monolith‘, mit dem die bislang meistgenutzte Architektur von Shopsystemen bezeichnet wird, klingt etwas sperrig und ziemlich alt. Das passt gut, wenn von etwas die Rede ist, das als althergebracht und mittlerweile überholt dargestellt werden soll. (Inwieweit und inwiefern sich das überhaupt sagen lässt, sehen wir weiter unten noch.) Wörtlich bedeutet Monolith „einzelner Stein“ und bezeichnet etwas, das sich nicht in Komponenten oder Einzelteile zerlegen lässt. Bei einem Stein liegt das buchstäblich auf der Hand – und leuchtet unmittelbar ein. Bei einem „klassischen“ Onlineshop ist damit gemeint, dass Frontend und Backend zwar gewissermaßen unterschiedliche Seiten eines Shops darstellen, sich aber technisch nicht voneinander trennen lassen.

Auch wenn es möglich ist, unterschiedliche Themes zu installieren und beliebig anzupassen, um das Erscheinungsbild des Shops zu verändern, bleiben Frontend und Backend in der monolithischen Gesamtarchitektur des Shopsystems untrennbar miteinander verbunden. Es wäre in diesem Modell zum Beispiel nicht möglich, ein fertig konfiguriertes Frontend in ein anderes System „mitzunehmen“, um es mit einem anderen Backend im Hintergrund weiterzunutzen. Die einzige Möglichkeit wäre ein mühsamer Nachbau im Zielsystem. Die Weiterentwicklung von standardisierten Schnittstellen (APIs) und weiteren Webtechnologien macht es inzwischen aber möglich, Systeme ganz wesentlich modular aufzubauen und so ganz neue Möglichkeiten jenseits monolithischer Architekturen zu eröffnen.

Headless

Der Begriff ‚Headless‘ bezeichnet einen neuartigen Ansatz, der die Trennung von Backend und Frontend ermöglicht. Der Gedanke dahinter: Ein nach dem Headless-Ansatz konzipiertes System lässt sich als Unterbau (Backend) ohne Oberbau (Frontend) betreiben. Ein Backend ganz ohne Frontend wäre aus vertrieblicher Sicht natürlich sinnlos. Aber wichtig ist hier: ein Backend, das auch ohne „Head“ vollständig funktionsfähig ist, kann über Schnittstellen erst mit einem und später mit einem anderen Frontend betrieben werden – oder sogar mit mehreren völlig unterschiedlich aufgebauten Vertriebskanälen gleichzeitig. Im Backend werden alle Daten und Inhalte verwaltet sowie die für den Onlinehandel benötigten Funktionalitäten bereitgehalten. Für die Anzeige im Frontend können Inhalte und Funktionen dann über APIs abgerufen und eingehende Daten zurück übertragen werden.

Der in erster Linie an Schnittstellen orientierte API-first-Ansatz ermöglicht die unkomplizierte Systemintegration und eröffnet bislang unerreichbare Flexibilität in der Gestaltung und funktionalen Ausrüstung von Frontends bis hin zu Vertriebskanälen die ganz ohne grafische Benutzeroberfläche auskommen. Was zunächst seltsam klingen mag, ist letztlich eine direkte Reaktion auf mittlerweile nicht mehr ganz neue, aber immer noch relativ junge technische Herausforderungen. So sind Headless-Anwendungsfälle denkbar, an denen Geräte im Internet-of-Things (IoT) selbstständig Bestellungen im Shop auslösen können – und das natürlich ohne Kategorie- und Produktseiten, Warenkorb und Checkout mit Adresseingabe und so weiter, sondern im direkten Datenverkehr über Schnittstellen – headless.

Composable Commerce

Ohne den Headless-Ansatz ist Composable Commerce nicht denkbar. Die in der Entkopplung von Frontend und Backend neu gewonnene Flexibilität wird hier allerdings noch einmal auf eine neue Ebene gehoben. Denn mit den richtigen Schnittstellen lässt sich auch ein Full-Stack-Backend aus streng modular ausgelegten, untereinander verbundenen Komponenten aufbauen. Der Composable-Ansatz wiederholt im Unterbau die Entkopplung von früher untrennbar miteinander verbundenen Teilen eines Ganzen noch einmal – und zwar prinzipiell beliebig oft. Eine wichtige Voraussetzung, damit das auch funktioniert, ist: Wenn eine Teilkomponente des Systems herausgenommen und durch eine andere Anwendung oder einen externen Dienst ersetzt wird, muss das Ganze als integriertes Gesamtsystem weiterhin vollständig funktionsfähig bleiben.

Sinnvoll wird der Composable-Ansatz im E-Commerce, wenn bestimmte Funktionen, die das verwendete Shopsystem bereithält, von anderen Systemen oder Diensten besser bereitgestellt werden können. Das können zum Beispiel PIM-Systeme für das Produktinformationsmanagement, Content-Management-Systeme (CMS) oder Tools für Rezensionen und Bewertungen sein. Ein Onlinehändler kann die Verwaltung von Produktdaten dann also vollständig im PIM erledigen, Inhalte für Content-Marketing auf redaktionell gepflegten Seiten und in Blog-Beiträgen in einem voll ausgestatteten CMS ansiedeln und Rezensionen in einen direkt angebundenen externen Dienst auslagern. Diese Form des Rosinenpickens beim Bau der eigenen Systemlandschaft wird auch immer wieder als „Best of Breed“ bezeichnet.

MACH

Hinter der im Zusammenhang mit den Ansätzen Headless und Composable immer wieder auftauchenden Abkürzung ‚MACH‘ verbirgt sich ein übergreifendes Konzept. Der Lösungsansatz MACH bildet einen Rahmen aus aktuellen technologischen Entwicklungen in unterschiedlichen Bereichen, die in der Kombination derzeit das größtmögliche Maß an Flexibilität ermöglichen: Microservices, API-first, Cloud-Hosting und Headless.

Microservices sind Dienste, die bestimmte Aufgaben innerhalb eines Systems erfüllen können und sich bei Bedarf in eine bestehende Systemlandschaft integrieren lassen. Ein KI-getriebener Microservice für Produktempfehlungen kann beispielsweise in einem nach dem Prinzip API-first entwickelten System integriert werden und dort die out of the box für diese Aufgabe bereitgestellte, weniger leistungsfähige Funktionalität ersetzen. Cloud-Hosting ist wegen der hervorragenden Skalierbarkeit die ideale Grundlage für ein modular aufgebautes System, in dem sich das Backend nach dem Ansatz Headless (siehe oben) problemlos mit wechselnden oder mehreren Frontends parallel betreiben lässt.

Für wen sind solche Konzepte geeignet?

Die drei hier vorgestellten Ansätze für Systemarchitekturen im E-Commerce jenseits monolithischer Onlineshops versprechen – in unterschiedlichen Graden – sehr viel Flexibilität. Das heißt insbesondere, dass die Wartung und Weiterentwicklung oder das Austauschen von einzelnen Komponenten oder Diensten unkomplizierter wird, weil nicht immer gleich ein Gesamtsystem, in dem alles untrennbar miteinander verbunden ist, ein Upgrade braucht oder durch eine andere Komplettlösung ersetzt werden muss. Aber initial ist die Entwicklung eines Onlineshops nach dem Headless-Ansatz aufwendiger als ein monolithischer Shop. Und noch schwerer zu stemmen wird das Ganze, wenn eine komplexe Composable-Commerce-Lösung oder gar eine E-Commerce-Plattform nach dem MACH-Prinzip geplant ist.

Für sehr kleine Onlineshops sind die hier dargestellten Konzepte für E-Commerce jenseits monolithischer Architekturen finanziell und technisch nicht zu realisieren. Betreiber mittelgroßer Onlineshops dagegen können auf der Grundlage eines geeigneten Shopsystems durchaus Headless- oder sogar Composable-Aspekte in ihre Strategie integrieren. Und im Enterprise-Bereich gibt es – je nach Branche – sehr interessante Möglichkeiten für komplexe Composable-Commerce- und MACH-Szenarien.

Wer braucht so etwas?

Möglich ist vieles. Aber für wen sind die Ansätze Headless, Composable Commerce und MACH sinnvoll? Wer braucht so etwas wirklich? Immerhin lässt sich das Frontend eines Shops ja auch mithilfe von Themes und individuellen Anpassungen nach Belieben umbauen und im Backend lassen sich durch die Installation von Extensions, Plugins oder Apps andere Systeme und externe Dienste ja auch sehr gut integrieren – und zwar mit durchaus überschaubarem Aufwand. Wozu sollten Shopbetreiber also gleich grundsätzlich werden und die gesamte Architektur des Systems verändern?

Richtig ist, dass der Headless-Ansatz nicht nötig ist, um die Gestaltung der Storefront umzubauen. Aber die Entkopplung von Backend und Frontend eröffnet viel umfassendere Möglichkeiten als das Wechseln und Anpassen von Themes. Wenn die Funktionalitäten des Shops vollständig unabhängig von dem oder den eingesetzten Frontends bereitstehen, lassen sich mehrere Frontends und auch schnittstellenbasierte Vertriebskanäle ohne visuelle Benutzeroberfläche nebeneinander betreiben – aber nicht nur das. Updates für Frontend und Backend lassen sich im Headless-Betrieb unabhängig voneinander durchführen und es ist auch jederzeit möglich, eine der beiden Komponenten durch eine Alternative zu ersetzen, ohne dass es sich auf die jeweils andere Komponente auswirkt. Vorausgesetzt sind natürlich immer die nötigen Schnittstellen. Händler, die sich durch eine starre Verbindung von Frontend und Backend in ihrem Handlungsspielraum eingeschränkt fühlen, finden im Headless-Ansatz die Freiheit, die sie zur Entfaltung ihrer Potenziale brauchen. Damit lassen sich nicht zuletzt im B2B-Bereich ganz neue Vertriebskonzepte realisieren.

Und wenn es im Composable-Commerce daran geht, Teile eines modular aufgebauten Backends „abzuklemmen“, um ihre Aufgaben durch andere, spezialisierte Systeme und Dienste übernehmen zu lassen, ist auch das noch einmal etwas anderes, als sie über Erweiterungen in das Backend zu integrieren. Jedes zusätzlich installierte Modul macht die Wartung eines Shopsystems komplexer und fügt ihm potenzielle Quellen von Konflikten und Fehlern hinzu. Updates, Upgrades und individuelle Anpassungen am System werden damit immer aufwendiger und komplizierter, da innerhalb des Shop-Backends immer mehr zusammenpassen und aufeinander abgestimmt werden muss, damit das Ganze weiterhin funktioniert.

Der Composable-Ansatz geht gewissermaßen genau den umgekehrten Weg: Wenn hier externe Systeme und Microservices integriert werden, muss dem Backend des Shops nichts hinzugefügt werden, sondern es kann ein Teil davon deaktiviert werden. Das Backend des Onlineshops wird also immer schlanker, je mehr Aufgaben nach dem Prinzip „Best of Breed“ in über Schnittstellen angebundene Systeme und Dienste ausgelagert werden. Wartung und Weiterentwicklung des Shopsystems gestalten sich damit einfacher und weniger aufwendig und zugleich ist es einfacher, die Komponente für eine bestimmte Aufgabe durch eine andere zu ersetzen. In diesem Modell kommen zwar möglicherweise weitere Systeme hinzu, die zusätzlich gewartet werden müssen oder Dienste, die zusätzliche laufende Kosten verursachen. Aber in großen, finanziell und personell breit aufgestellten Unternehmen kann das der weitaus bessere Weg sein als das Festhalten am monolithischen Ansatz: Wer über die nötigen Ressourcen verfügt, hat lieber mehr Tiere im Zoo, um die sich gekümmert werden muss, als ein im Lauf der Zeit immer unberechenbarer werdendes Monstrum zu bändigen. Und das ist ganz besonders interessant für Hersteller, die in den Online-Direktvertrieb einsteigen wollen. Große Unternehmen verfügen meist bereits über eine komplexe Software-Systemlandschaft. Um hier neue digitale Vertriebskanäle für den direkten Handel mit Privat- und Geschäftskunden zu integrieren und im D2C- und D2B-Commerce durchzustarten, ist der Composable-Ansatz daher goldrichtig.

Shopware 6: Onlineshops jenseits monolithischer Architektur

Bekanntlich ist Shopware 6 nicht einfach eine Weiterentwicklung von Shopware 5. Betreiber von Shopware 5 Onlineshops können aus diesem Grund nicht einfach per Upgrade auf das neue System umsteigen, sondern müssen einen steileren Pfad wählen: die Migration von Shopware 5 zu Shopware 6. Das ist zwar aufwendiger als ein Upgrade, aber dafür gibt es einen guten Grund: Shopware 6 wurde seinerzeit vollständig neu entwickelt: Sowohl die Code-Basis als auch das Datenbank-Modell wurden von Grund auf neu entworfen – und zwar nach dem API-first-Ansatz. Damit ist Shopware 6 hervorragend für den Headless-Einsatz und als zentrale Komponente in Composable-Commerce-Szenarien geeignet. Wer sich für Shopware 6 entscheidet, hat tatsächlich alle Möglichkeiten: Das System lässt sich dank integrierter Template-Engine, modularer Architektur und moderner Schnittstellen wahlweise monolithisch, headless oder composable betreiben.

Headless-Ansatz mit Shopware 6

Wer einen klassischen Onlineshop mit einem Backend und einem damit verbundenen Frontend betreiben möchte, kann das dank der integrierten Template-Engine mit Shopware 6 tun – und zwar auf technisch sehr hohem Niveau. Und wer sich nicht nur unter der Haube vom monolithischen Ansatz lösen, sondern neue Vertriebskanäle nach dem Headless-Ansatz entwickeln möchte, findet dafür in Shopware 6 alles, was es dafür braucht: Alle Bereiche des Systems können über REST-Schnittstellen (Sync, Admin und Store) angesprochen werden. Über die Sync API ist es möglich, große Produkt- und Datenmengen in angebundene Systeme (etwa ein CRM, PIM oder ERP) zu übertragen. Die Store API ist die Schnittstelle zu den unterschiedlichen Vertriebskanälen, für die sich die User Experience jeweils unabhängig entwickeln lässt. Auf der anderen Seite eröffnet die Admin API weitreichende Möglichkeiten, um die Administrationsoberfläche weitreichend an die Bedürfnisse des Unternehmens anzupassen und zu personalisieren.

Composable-Commerce mit Shopware 6

Und eben weil sich in Shopware 6 alle Teilbereiche des Systems über Schnittstellen ansprechen lassen, ist es auch hervorragend für den Einsatz im Composable-Commerce geeignet. Wer vor dem Einstieg in den E-Commerce bereits mit einer gut austarierten Systemlandschaft arbeitet, kann Shopware 6 über Schnittstellen mit genau denjenigen Teilen des Systems integrieren, die für ein funktionierendes Ganzes noch fehlen. Und wer sein Geschäftsmodell von Anfang auf der Grundlage des Best-of-Breed-Ansatzes entwickelt, kann Shopware 6 gewissermaßen als E-Commerce-Modul zwischen PIM, CRM, CMS, Frontend, Suchmaschine, Payment, Bewertungsportal und weiteren Komponenten und Diensten passgenau einfügen und die daraus benötigten Funktionalitäten über Schnittstellen mit den anderen Systemen verbinden, um aus allen Komponenten das jeweilige Maximum herauszuholen.

Steht der Untergang der monolithischen Architektur im E-Commerce bevor?

Wer für das eigene Geschäftsmodell keinen Bedarf sieht, den eigenen Shop in Richtung Headless- oder Composable-Ansatz zu entwickeln, oder schlicht nicht über die Ressourcen dafür verfügt, mag sich nun fragen: Kann ich in Zukunft auch mit einem klassischen Onlineshop – dem sogenannten Monolithen – weiterhin erfolgreich sein? Oder haben herkömmliche Shops bald ausgedient, während Branchenriese Amazon und große E-Commerce-Plattformen, die auf komplexen Headless- und Composable-Architekturen beruhen, das Marktgeschehen zunehmend beherrschen? Ist der Monolith tatsächlich so althergebracht, wie die Bezeichnung klingt – und technisch inzwischen schlichtweg überholt? Einige Beiträge zu den Themen Headless- und Composable-Commerce lesen sich so.

Technisch mag die monolithische Architektur durchaus ihre Grenzen haben – überholt ist sie deswegen aber längst nicht. Ein Blick auf die jüngeren Entwicklungen in der Magento Community zeigt, dass es im E-Commerce-Ökosystem eine sehr breite und stabile Basis gibt, die in der Entkopplung von immer mehr Teilen und Komponenten und den Einsatz von Microservices, Schnittstellen und Cloud-Hosting keineswegs den einzigen Weg in eine erfolgreiche Zukunft im E-Commerce sieht. Nachdem Adobe begonnen hatte, die Enterprise-Variante von Magento unter dem Namen Commerce Cloud in sein modularisiertes Produktportfolio zu integrieren (wir berichteten) und damit in Richtung MACH-Ansatz weiterzuentwickeln, begehrte die Community laut auf.

In der Sorge, Adobe arbeite daran, die monolithische Architektur als Möglichkeit von auf Magento basierenden Onlineshops vollständig hinter sich zu lassen, entstand eine Initiative, die zahlreiche Unterstützer fand und schließlich das vollständig von der Community getragene Projekt Mage-OS, das Magento 2 als solide Grundlage für voll ausgestattete und performante Onlineshops – nicht zuletzt in monolithischer Architektur – dauerhaft erhalten soll und damit inzwischen Marktreife erreicht hat. Und auch Shopware 6 wird weiterhin und sicherlich noch auf lange Sicht von vielen Händlern weder nach dem Composable- noch nach dem Headless-Ansatz eingesetzt, sondern ganz klassisch mit einem Backend und einem damit verbundenen Frontend. Dass die beiden unter der Haube per API verbunden sind, ist in diesen Anwendungsfällen letztlich nicht weiter wichtig. Die wichtigsten Erfolgskriterien sind und bleiben Performance, SEO, Usability, UX und die richtige Strategie  – und nicht etwa modulare Architekturen. Gleichwohl bleibt die Wahl des Shopsystems eine sehr wichtige Entscheidung, bei der es noch auf eine Reihe weiterer Faktoren und Aspekte ankommt, wie wir in unserem Beitrag mit zehn Punkten zum Shopsystem-Wechsel herausgearbeitet haben. Und eine moderne, modular aufgebaute Codebasis und intelligente Schnittstellen haben noch keinem Onlineshop geschadet – auch im monolithischen Betrieb.

Können wir Sie unterstützen?

Wenn Sie unsicher sind, welches Shopsystem und welche Architektur für Ihr E-Commerce-Vorhaben oder Ihren Shop-Relaunch geeignet ist, sprechen Sie uns gern direkt an. Gemeinsam finden wir die für Ihr Projekt passende Lösung.

Jetzt beraten lassen!