Der Vorteil besteht darin, dass die Backend-Applikation in verschiedenen Anwendungsf\u00e4llen zum Einsatz kommen kann und die entwickelte Logik somit wiederverwendbar wird. Wie die Anwendungsf\u00e4lle konkret aussehen, spielt dabei keine Rolle und kann g\u00e4nzlich unterschiedlich ausfallen, deshalb h\u00f6rt man in dem Kontext auch \u00f6fter den Begriff \u201cmulti experience\u201d.<\/p>\n\n\n\n
Microservices<\/h3>\n\n\n\n
Eine Microservice-Architektur ist eine Softwarearchitektur, die auf dem Konzept von einzelnen, unabh\u00e4ngigen Diensten (sogenannte „Microservices“) basiert, die jeweils eine spezifische Funktion erf\u00fcllen. Jeder Microservice wird als eigenst\u00e4ndige Anwendung entwickelt und kommuniziert mit anderen Microservices \u00fcber eine API (Schnittstelle).<\/p>\n\n\n\n
Die Idee hinter einer Microservice-Architektur ist es, die Komplexit\u00e4t einer grossen Anwendung zu reduzieren, indem sie in kleinere, spezialisierte Dienste aufgeteilt wird. Jeder Microservice ist eigenst\u00e4ndig und kann in einer beliebigen Programmiersprache oder Technologie entwickelt werden. Wichtig ist, dass er mittels Schnittstelle kommunizieren kann. Teams k\u00f6nnen dadurch unabh\u00e4ngig voneinander arbeiten, was die Geschwindigkeit der Entwicklung und die Qualit\u00e4t der Anwendung erh\u00f6hen kann.<\/p>\n\n\n\n
Die Microservice-Architektur ist flexibler und skalierbarer als monolithische Anwendungen. Wenn eine Anwendung w\u00e4chst, k\u00f6nnen neue Microservices hinzugef\u00fcgt werden, um zus\u00e4tzliche Funktionalit\u00e4ten bereitzustellen. Jeder Microservice kann unabh\u00e4ngig vom n\u00e4chsten skaliert werden, um mit der jeweiligen Last umzugehen, die er verarbeitet.<\/p>\n\n\n\n
Composable Commerce – Shop nach dem Baukastenprinzip<\/h3>\n\n\n\n
Vor dem Hintergrund dieser Entwicklungen ist es nur konsequent, dass sich auch im eCommerce etwas tut. Gerade Shopsysteme m\u00fcssen verschiedene Business-Logiken abbilden. Sie b\u00fcndeln komplexe Informationen und interagieren in der Regel mit weiteren Umsystemen. Kein Wunder, halten \u201cHeadless & Co.“ auch in dieser Welt Einzug. Im eCommerce etabliert sich mittlerweile der Begriff \u201cComposable Commerce\u201d.<\/p>\n\n\n\n
Composable Commerce beschreibt eine modulare, auf (Micro)Services basierende Architektur, die Unternehmen die M\u00f6glichkeit gibt, verschiedene Funktionen miteinander zu kombinieren, um eine massgeschneiderte eCommerce-L\u00f6sung zu erstellen. Die Services werden anhand ihrer Gesch\u00e4ftsf\u00e4higkeiten geb\u00fcndelt. Deshalb spricht man hier auch von \u201cPacked Business Capabilities\u201d, kurz PBCs.<\/p>\n\n\n\n
Beispiele f\u00fcr PBCs im eCommerce-Umfeld sind:<\/p>\n\n\n\n
- \n
- Commerce<\/li>\n\n\n\n
- Inhalte und Assets (CMS \/ DAM)<\/li>\n\n\n\n
- Customer Identity and Access Management (CIAM)<\/li>\n\n\n\n
- Analytics<\/li>\n\n\n\n
- Payment Provider<\/li>\n\n\n\n
- Product Recommendations \/ Personalisierung<\/li>\n\n\n\n
- Suche<\/li>\n<\/ul>\n\n\n\n
Man integriert also jene Dienste, welche man braucht und die den eigenen Anforderungen am besten entsprechen.<\/p>\n\n\n\n
Ein Beispiel einer solchen Composable Commerce-Landschaft k\u00f6nnte so aussehen:<\/p>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/diselva.com\/wp-content\/uploads\/2025\/07\/composable-ecommerce-pbc.png?resize=1360%2C801&quality=78&ssl=1\")
<\/figure>\n\n\n\nMACH mir einen Shop daraus<\/h3>\n\n\n\n
Wie kommen die verschiedenen Elemente nun zusammen? In der Abbildung oben steckt bereits ein bew\u00e4hrter Architektur-Ansatz, der die beschriebenen Elemente miteinander verbindet: MACH. In dieser Kombination k\u00f6nnen die Technologien ihr Potenzial entfalten und bilden daher die ideale Grundlage f\u00fcr Composable Commerce.<\/p>\n\n\n\n
M (Microservices)<\/strong>: Einzelne Anwendungen bzw. Services zum Bereitstellen von Business Funktionalit\u00e4t, welche unabh\u00e4ngig entwickelt, deployed und gewartet werden k\u00f6nnen.<\/p>\n\n\n\n
A (API)<\/strong>: Die gesamte Funktionalit\u00e4t ist mittels API (Schnittstelle) zug\u00e4nglich. Services kommunizieren untereinander \u00fcber die bereitgestellten APIs.<\/p>\n\n\n\n
C (Cloud)<\/strong>: Typischerweise werden die L\u00f6sungen nicht mehr selbst gehostet, sondern als SaaS Modell in der Cloud betrieben. Dadurch werden Wartungsaufwand, Skalierung und automatische Updates ausgelagert.<\/p>\n\n\n\n
H (Headless)<\/strong>: Frontend wird vom Backend entkoppelt gebaut und ist somit kanalunabh\u00e4ngig und nicht an spezielle Technologien gebunden.<\/p>\n\n\n\n
Wer mehr \u00fcber diesen Ansatz erfahren m\u00f6chte, wird bei der MACH Alliance (<\/em>https:\/\/machalliance.org<\/em><\/a>) f\u00fcndig, die den Ansatz entwickelt und zertifiziert hat.<\/em><\/p>\n\n\n\n
Fazit 1 – Das Baukastenprinzip ist sinnvoll<\/h2>\n\n\n\n
Die Vorteile des Composable Commerce Ansatzes mit einer MACH-Architektur liegen auf der Hand: es k\u00f6nnen f\u00fcr einzelne Business Anforderungen die besten auf dem Markt verf\u00fcgbaren Anwendungen (Best-of-Breed) miteinander kombiniert werden. Seien es Tools von einem oder mehreren Herstellern oder in einzelnen F\u00e4llen auch Eigenentwicklungen, alle Komponenten lassen sich \u00fcber APIs miteinander vernetzen und sich so zu einem leistungsf\u00e4higen Gesamtsystem zusammenstellen.<\/p>\n\n\n\n
Mit einem solchen Gesamtsystem kann auf kurzfristige Bed\u00fcrfnisse wie Spitzenlasten unmittelbar reagiert werden (tempor\u00e4re Leistungssteigerung einzelner Microservices). Auch zuk\u00fcnftige ver\u00e4nderte Marktanforderungen k\u00f6nnen so sehr schnell und zielgerichtet bedient werden (Integration neuer Komponenten, Weiterentwicklung\/Erweiterung bestehender PBCs).<\/p>\n\n\n\n
Fazit 2 – Es ist ein Umdenken erforderlich<\/h2>\n\n\n\n
Warum braucht es dennoch Zeit und auch etwas Mut, diese Entwicklungen f\u00fcr sich selbst zu nutzen und im eigenen Unternehmen zu etablieren?<\/p>\n\n\n\n
Um ein Composable Commerce auf die Beine zu stellen, braucht es mehr als nur funktionierende Einzelteile. Ein wichtiger Erfolgsfaktor ist die Gesamtarchitektur, und darin liegt auch die erste Herausforderung. Das Thema Architektur hat sich im Vergleich zu jener von monolithischen Systemen stark ver\u00e4ndert und daher fehlt es den Verantwortlichen oft an Erfahrung in diesem Bereich. Die Konzeption eines hoch modularen Systems ist jedoch sehr komplex und braucht einiges an \u00dcberlegungen.<\/p>\n\n\n\n
Hat man diese H\u00fcrde genommen und Ideen und Konzepte ausgearbeitet, steht schon die n\u00e4chste Herausforderung vor der T\u00fcr: die damit verbunden Business-Prozesse passen vermutlich nicht mehr in die neue Welt und sind ebenfalls anzupassen. Was mit nicht zu untersch\u00e4tzenden Spannungen mit den betroffenen Abteilungen verbunden sein kann: die Produktmanager, die Verkaufsleute, die Servicemitarbeiter, … alle wollen mitreden, das Beste f\u00fcr ihren Bereich herausholen und sich dabei keinem IT System unterwerfen. Hier ist Change Management gefragt, um bei den betroffenen Personen Verst\u00e4ndnis zu schaffen, was diese ver\u00e4nderten Rahmenbedingungen genau bedeuten. Gemeinsam kann man dann er\u00f6rtern, welche Vorteile und Erleichterungen daraus entstehen und welche Umstellungen in der gewohnten Zusammenarbeit und Prozessen n\u00f6tig sind. <\/p>\n\n\n\n
Wenn der Change Manager dort seine Arbeit getan hat, darf er auch schon zu seinen n\u00e4chsten Klienten ziehen: diejenigen, welche die Systeme bedienen, werden inzwischen sicher auf die Barrikaden gegangen sein. CMS ohne WYSIWYG -Experience, CRM ohne integriertes Newsletter-Tool, f\u00fcnf verschiedene nicht-gebrandete Systeme, um eine News zu publizieren?! Das kann \u00c4rger geben. Wer Gl\u00fcck hat, findet einen netten Entwickler, der den Anwendern technische Helferlein zur Seite stellt, die ihm die Benutzung einfacher machen. Doch da steht auch schon der CTO auf der Matte und beschwert sich, dass ihm genau die f\u00e4higen Entwickler ausgehen. Wie soll er denn in Zeiten des Fachkr\u00e4ftemangels noch einen erfahrenen Commerce-Entwickler UND einen Data-Science-Spezialisten auftreiben?! Das wird spannend\u2026<\/p>\n\n\n\n
Die gute Nachricht ist: diese Herausforderungen sind h\u00e4ndelbar.
Es gibt viele M\u00f6glichkeiten, die einzelnen Schritte technisch zu unterst\u00fctzen. Vor allem aber ist es wichtig, die Menschen in diesem Prozess mitzunehmen, ihre Bed\u00fcrfnisse ernstzunehmen und sie zu unterst\u00fctzen.<\/p>\n\n\n\nNur so steht ein Composable Commerce letzten Endes nicht nur auf technologisch bestem Fundament, sondern wird auch aktiv genutzt und von allen wichtigen Beteiligten weiterentwickelt. Das ist der wirkliche Grundstein f\u00fcr eine zukunftssichere eCommerce-L\u00f6sung.<\/p>\n\n\n\n
Kommende Beitr\u00e4ge zum Thema<\/p>\n\n\n\n
Michael Schlegel-Iten<\/a> wird anhand unserer Erfahrungen n\u00e4her auf die Vorteile aber auch Herausforderungen von Composable Commerce aus Business-Sicht eingehen.<\/p>\n\n\n\n
Auch f\u00fcr alle Techies folgt ein Beitrag, in dem wir mit einem Praxisbeispiel die geeigneten Technologien und unsere Learnings aufzeigen.<\/p>\n\n\n\n
Wie gef\u00e4llt Ihnen unser Blog? Schreiben Sie uns: hello@diselva.com<\/a><\/p>\n\n\n\n
\n\n\n\nWir bei diselva bringen die Erfahrung und Kompetenz mit, um Sie in einem eCommerce- oder auch anderen Projekten zielf\u00fchrend zu unterst\u00fctzen. Wir begleiten den Weg hin zu einer modernen und zukunftsf\u00e4higen Software-Architektur, von der Konzeption \u00fcber die technische Umsetzung bis hin zur Einf\u00fchrung des neuen Systems und bieten Hilfestellung bei der Koordination aller involvierten Stakeholder. <\/p>\n\n\n\n