In diesem Beitrag geht es darum, wie eCommerce-Systeme gedacht und entwickelt werden müssen, damit sie auf Dauer den sich rasch ändernden Anforderungen der Käufer gewachsen sind.

Was ist Headless Commerce?

Manche sehen in Headless Commerce eine Revolution, wir sehen darin eher eine logische Entwicklung: weg von E-Commerce-Systemen, die als monolithische Anwendung gebaut sind, hin zu Architekturen, die aus vielen funktionalen Bausteinen, sogenannten Services, zusammengesetzt sind.

Die Vorteile von Service orientierten Architekturen (SOA) haben wir in einem früheren Artikel vorgestellt. Im wesentlichen lassen sich SOA flexibler an neue Anforderungen anpassen als traditionelle Architekturen, in denen alle Funktionen in einer Applikation stecken.

“Headless” steht für eine bestimmte Form von Service-Architektur, bei der das Nutzer-Frontend, beispielsweise die Shop-Oberfläche, fehlt. Headless-Systeme beinhalten also nur die Funktionen, die “unter der Haube” (Backend, auch Applikationsebene genannt) des Online-Verkaufs nötig sind.

Die Nutzeroberfläche (Frontend, auch Präsentationsebene genannt) wird je nach Bedarf des Händlers individuell entwickelt und angedockt. Die Kommunikation zwischen der Applikations- und der Präsentationsebene erfolgt über Schnittstellen (API).

Wenn beispielsweise ein Käufer im Shop auf den Button “Kaufen” klickt, dann sendet die Präsentationsebene eine Anfrage an die Applikationsebene, wo die Bestellung dann bearbeitet wird. Bei einem traditionellen System “aus einem Guss” geschieht das Ganze innerhalb einer einzigen Applikation. Das ist der wesentliche Unterschied.

Wozu Headless Commerce?

Kurz gesagt, bietet die Trennung von Front- und Backend in Verbindung mit einer Service orientierten Architektur mehr Flexibilität bei der Anpassung eines Systems an neue Anforderungen im Online-Verkauf. Dazu ein kurzes Beispiel…

Der digitale Verkaufsraum besteht bei vielen Händlern heute noch aus einem Online-Shop, in dem Produkte präsentiert, gesucht und gekauft werden können. Mit der zunehmenden Nutzung von mobilen Endgeräten hat sich der E-Commerce bereits in Richtung mobile Endgeräte erweitert. Der Verkauf ist aber immer noch relativ linear auf einen Kanal beschränkt, obwohl Kunden in einer Vielzahl von Kontaktpunkten (“Touchpoints”) kaufen würden – Stichwort: Omnichannel.

Auswahl neuer Touchpoints für den Online-Verkauf

(Quelle: Whitepaper commercetools, lesenswert!)

Nicht jeder Verkaufskanal ist für jeden Händler interessant, entscheidend ist jedoch, was der Kunde wünscht. Der Trend geht dahin, dass auch dort gekauft wird, wo sich der Kunde gerade aufhält, ohne dass er erst den Online-Shop eines Händlers besuchen muss.

Wenn Ihre Kunden beispielsweise ab morgen ihre Käufe über Sprachassistenten wie Amazon Echo oder Google Home tätigen wollen, oder plötzlich Chatbots im Facebook Messenger dem persönlichen Gespräch mit Ihrem Vertrieb vorziehen, dann muss Ihr E-Commerce darauf reagieren können. Ein “Headless”-System könnte schnell und mit geringem Aufwand angepasst werden, wogegen ein System klassischer monolithischer Bauart unter Umständen zunächst grundlegend umgebaut werden müsste.

Aufwand, um neue Touchpoints einzubinden

Klassische ArchitekturHeadless Architektur
Bestehenden Monolithen um passende Schnittstellen erweitern und neuen Touchpoint über diese anbindenNeuen Touchpoint über die vorhandenen Schnittstellen anbinden

Eine große Herausforderung für viele Händler besteht darin, zu erkennen, dass ihre aktuelle Lösung, bzw. ihr aktuelles System zu schwerfällig geworden ist, um es flexibel und wirtschaftlich an Veränderungen anpassen zu können. Jede einzelne Anpassung scheint auf den ersten Blick nicht ins Gewicht zu fallen. Die Problematik zeigt sich erst in der Summe der Aufwände über längere Zeit betrachtet.

Statt über eine grundlegende Neuorganisation ihrer Systemlandschaft nachzudenken, hangeln sich viele Händler von Anpassung zu Anpassung, die bei zunehmender Komplexität ihrer Systeme immer aufwändiger werden. Es lohnt sich deshalb, von Zeit zu Zeit das gesamte Ökosystem kritisch auf den Prüfstand zu stellen.

Wie gelingt der Wechsel zu Headless Commerce?

Der Schlüssel zum Erfolg liegt sowohl im Aufbau als auch im Umbau in einer inkrementellen Vorgehensweise. Dabei wird die bestehende Architektur schrittweise verändert, statt sie in einem großen Wurf umzubauen. Bei monolithischen Systemen, wie in den meisten “organisch” gewachsenen Shops zu finden sind, geht es darum, die Architektur zu entflechten und in eine Service-Architektur zu überführen.

Mehr zum Thema “Monolithische Systeme schrittweise entflechten” finden Sie in einem früheren Artikel in diesem Blog.

In manchen Fällen kann es sinnvoll sein, ein “Shop-System”, das sich nur in bestimmten Grenzen an individuelle Anforderungen anpassen lässt, gegen eine flexiblere Lösung zu ersetzen. Eine Headless-Lösung, die wir bereits bei erfolgreichen Händlern implementiert haben, ist die E-Commerce-Plattform von commercetools. Sie bietet sich besonders dann an, wenn es auf maximale Flexibilität durch 100% Service-Architektur (in diesem Fall in der Cloud) ankommt. 

Trennung von Frontend- und Backend-Funktionalität bei commercetools 

Quelle: commercetools

Vorhandene Systemlandschaft auf den Prüfstand stellen

Wenn sich die Anzeichen dafür mehren, dass ein E-Commerce-System zu starr geworden ist, um mit den Anforderungen mitzuhalten, dann ist es Zeit für eine kritischen Analyse. Dabei wird der Status im Lichte kurzfristiger und mittelfristiger Veränderungen bewertet. Lassen sich notwendige Anpassungen technisch und wirtschaftlich im Rahmen des bestehenden Systems durchführen? Oder sind umfassende Veränderungen notwendig?

Ein objektiver Blick von aussen hilft dabei, die Situation klarer und mit der nötigen Unvoreingenommenheit zu analysieren. Wir als Berater und Umsetzer bieten hierfür entsprechende Analyse-Workshops an, in denen technologische und strategische Aspekte gleichermaßen in die Bewertung einfliessen.

Serviceorientierte Architekturen (SOA) sind heute Standard in E-Commerce-Systemen. Erfahren Sie hier, was hinter Microservices & Co. steckt und wie die Umstellung von monolithischen auf servicebasierte Systeme gelingt.

Online-Händler stehen vor der Herausforderung, dass sich die Rahmenbedingungen für ihr E-Commerce laufend verändern. Kunden ändern ihr Kaufverhalten, neue Technologien setzen neue Standards im Wettbewerb um die Gunst der Käufer. Mit jeder neuen Anforderung an den E-Commerce, vergrößert sich automatisch die Komplexität von Systemen, Prozessen und Daten beim Händler.

Systeme aus einem Guss, sogenannte monolithische Systeme, stoßen schnell an Grenzen, weil sie sich ab einer bestimmten Komplexität oft nicht mehr ohne Weiteres flexibel anpassen lassen. Der Klassiker: Ein Standard-System wird punktuell oder über einen längeren Zeitraum so sehr auf die den individuellen Bedarf eines Händlers angepasst, sodass am Ende das System aus 20 % Standard- und 80 % individuellem Software-Code besteht. Ein solches System lässt sich, wenn überhaupt, nur mit sehr hohem Aufwand erweitern. Versions-Updates können im Einzelfall viele Manntage kosten, ohne dass dadurch viel Funktionalität bzw. Mehrwert gewonnen wird.

Aus diesem Grund teilt man heute vor allem komplexe Systeme in einzelne Programme und Aufgaben in serviceorientierte Architekturen auf. Besonders große Unternehmen mit komplexen Softwaresystemen, die laufend weiterentwickelt werden, setzen auf Services. Bei sehr kleinem Funktionsumfang spricht man von Microservices.

Der E-Commerce-Riese Amazon stellt alle 11,7 Sekunden neuen Code online. Ohne Microservices wäre das nicht möglich.” – Dirk Hörig, CEO Commercetools

Die Idee hinter serviceorientierten Architekturen findet sich schon in der UNIX-Philosophie:

  • Ein Programm soll nur eine Aufgabe erfüllen,
  • Programme sollen zusammenarbeiten können und
  • sie sollen dafür Standard-Schnittstellen nutzen.

Serviceorientierte Architekturen ermöglichen ein hohes Maß an Flexibilität in der Entwicklung, denn kleine, bedarfsorientierte Services lassen sich jederzeit leicht ergänzen oder ersetzen, wenn neue Anforderungen aufkommen.

Eine kurze Einführung in das Konzept der Microservices gibt Kelly Goetsch, CPO von commercetools im folgenden Video:

Lesetipp: Einen Überblick und Starthilfe für die Arbeit mit Microservices bietet das E-Book von Eberhard Wolf, dass man hier kostenlos herunterladen kann.

Monolith versus Service Mashup


Monolithische ArchitekturService-Architektur
Anwendungeine einzige, integrierte Software-Instanzin modulare Komponenten zerlegt
Umgebungeinzelner Server oder VMkann über Clouds und eigenes Rechenzentrum verteilt werden
Erweiterungenerfordern Redeployment der gesamten Anwendungerfordern nur die Aktualisierung der einzelnen Services
HauptvorteilEinfache Installation und DeploymentEntwicklung neuer Funktionen einfach und flexibel
HauptnachteilSkalierbarkeit der Funktionen begrenztOrchestrierung der Funktionen und Wartung aufwändig
Geeignet fürKleine und mittlere Shops überschaubarer InnovationsrateAmbitionierte E-Commerce-Plattformen, mit raschen Innovationszyklen und Wachstumsplänen

Es gibt keine allgemeingültige Liste der Vor- und Nachteile von Monolithen und Microservices, beide sind mit bestimmten Kompromissen verbunden. Deshalb analysieren wir bei eCube bei jedem Projekt sehr sorgfältig die Anforderungen, um im konkreten Fall die optimale Lösung für unsere Kunden finden zu können.

Abbildung: Monolithische Architektur versus Service-Architektur (Quelle: Commercetools)

Monolithische Systeme schrittweise entflechten

In vielen unserer Projekte geht es darum, monolithische E-Commerce-Systeme, die im Laufe der Jahre sehr komplex und dabei gleichzeitig zu unflexibel für eine wirtschaftliche Weiterentwicklung geworden sind, zu entflechten.

Statt das gesamte System von Grund auf neu zu bauen (was in den meisten Fällen mit einem nicht verantwortbaren Risiko verbunden wäre), lösen wir schrittweise einzelne Funktionen aus dem Monolithen heraus und ersetzen sie durch Services, die diese Funktionen übernehmen. Dabei folgen wir dem Prinzip der “Strangler Pattern”.

Prinzip der Strangler Pattern im E-Commerce

In diesem Beispiel wird im ersten Schritt das Preismanagement aus dem System in einen Service ausgelagert. Danach folgen schrittweise die übrigen Funktionen, sodass am Ende ein Netzwerk von Services steht, die miteinander kommunizieren. Wir nennen dies “Service Mashup”. In diesem Prozess bietet sich auch die Möglichkeit, einzelne Funktionen zu erneuern oder durch Standard-Services z.B. für die Produktsuche zu ersetzen.

Während beim monolithischen System in der Regel verschiedene Teams damit beschäftigt sind, mehr oder weniger trennscharf an “ihren” System-Bereichen zu arbeiten, können im Service Mashup die Zuständigkeiten entsprechend der Organisationsstruktur definiert werden. Im Idealfall wird jeder Service von einem dedizierten Team betreut. So ergibt sich die Möglichkeit, Systemstrukturen mit Organisations- oder Teamstrukturen gemäß Conways Law in Einklang zu bringen. 

Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“
– Melvin E. Conway

Tipps für die Entwicklung

Der Umfang jedes einzelnen Services ist begrenzt. Das macht die Entwicklung, Wartung und Aktualisierung der Dienste einfacher als in monolithischen Systemen.

Andererseits wächst mit jedem neuen Service die Komplexität des Gesamtsystems. Bei eCube wägen wir deshalb in jedem Projekt genau ab, ob und an welchen Stellen eine Zerlegung nach Aufgaben bzw. Funktionen möglich, ohne dass der Aufwand den Nutzen übersteigt. 

Damit auch kleinere aber ambitionierte Online-Shops ohne großes Entwicklungsteam von einer Service-Architektur profitieren können, sollte man bei der Planung und Entwicklung folgende Aspekte zu berücksichtigen:

Infrastruktur auslagern: Systeme wie beispielsweise Kubernetes für die Bereitstellung, Skalierung und Verwaltung von Services sollten so weit wie möglich ausgelagert werden, um die Komplexität der eigenen System-Landschaft nicht unnötig zu erhöhen. In Frage kommen hier Platform-as-a-Service-Angebote, die neben der Server-Infrastruktur auch das Betriebssystem beinhalten. Diese Komplettpakete sind zwar teurer, als das Hosting auf eigenen Servern, aber in der Gesamtbetrachtung eines Projektes oft kostengünstiger.

Fertige Services nutzen: Nicht alle Services müssen individuell entwickelt werden, vielmehr empfiehlt es sich, möglichst viele fertige Services wie z.B. den E-Commerce-Service von commercetools, die Produktsuche von Factfinder und andere zu nutzen. Fertige Services lassen sich einfacher und zuverlässiger Updaten, da die Service-Anbieter ihre Schnittstellen und Funktionen in der Regel fortlaufend pflegen.

Fazit: Händler sollten rechtzeitig handeln

Händler werden häufig erst dann aktiv, wenn sie mit ihren E-Commerce-Systemen bereits an Grenzen stoßen. Etwa wenn Funktionen nur bedingt mit vertretbarem Aufwand ergänzt oder erweitert werden können. Dann muss schnell gehandelt werden und es bleibt oft zu wenig Zeit, die Situation gründlich zu analysieren und Optionen abzuwägen. Es lohnt sich deshalb, regelmäßig die eigene Systemlandschaft auf den Prüfstand zu stellen, um mögliche Engpässe für die Weiterentwicklung frühzeitig zu erkennen und darauf adäquat reagieren zu können.

Wir haben hierfür einen speziellen Analyse-Workshop entwickelt, in dem Online-Händler mit unserer Unterstützung ermitteln können, ob und wann sich beispielsweise eine Umstellung von monolithischem Shop-System auf eine Serviceorientierte Architektur anbietet. 

Jedes Jahr zeigt die W-JAX Konferenz für Java, Architektur- und Software-Innovation wo die Reise in der Software-Entwicklung hingeht. Erfahren Sie im Folgenden mehr über die wichtigsten Java-Trends.

Agile Entwicklung & DevOps

„Agil“ ist seit langem ein großer Trend in der Software-Entwicklung, trotzdem nutzen noch nicht alle Unternehmen agile Methoden. Das liegt vor allem daran, dass agil nicht nur eine Methodik sondern eine Kultur im gesamten Unternehmen ist, die sich nicht von heute auf morgen entwickeln lässt. Damit agile Kultur in der Software-Entwicklung funktioniert, müssen auch andere Unternehmensbereiche agil denken und handeln. Im E-Commerce sind das zum Beispiel der Vertrieb und das Marketing, die IT, Einkauf und Fulfillment und letztendlich auch die Geschäftsführung, die E-Commerce-Projekte strategisch steuert. Treffen hier agiles und „klassisches“ Denken und Handeln aufeinander, führt dies zu Reibung und viele Chancen des „agilen“ bleiben ungenutzt.

Der Schlüssel zum Erfolg agiler Software-Projekte liegt also in einem gemeinsamen Verständnis von agiler Methodik sowie in der Integration verschiedener Unternehmensbereiche in Softwareprojekten. Hier kommt ein weiterer neuer Ansatz ins Spiel, der in Fachkreisen diskutiert wird: DevOps. Dahinter steckt die Idee, Business und Technologie so zu integrieren, dass beispielsweise Betriebs- und Entwicklungsingenieure über den gesamten Software-Lebenszyklus, vom Design- und Entwicklungsprozess bis hin zur Produktionsunterstützung Hand in Hand arbeiten. DevOps will das traditionelle Denken und Handeln in Silos ersetzen, in denen ein Team den Code schreibt, ein anderes Team testet, ein weiteres Team bereitstellt usw. Auch hinter DevOps steckt eine Kultur, die Grenzen in Unternehmen überwindet, um gemeinsam beispielsweise den E-Commerce weiterzuentwickeln. Das bedeutet auch, gemeinsam Verantwortung für Projekt zu übernehmen.

Agile Entwicklung und Prinzipien des DevOps wie etwa Continious Delivery finden sich in nahezu allen Projekten von eCube, wenngleich sie uns regelmäßig vor Herausforderungen stellen. Denn unsere Kunden „ticken“ in der Regel „klassisch“, wenn es darum geht, E-Commerce im Unternehmen zu entwickeln. Hier sind neben der Shop-Entwicklung selbst viele Brücken zwischen Fachabteilungen zu bauen, die bisher in parallelen Welten gelebt haben. Hier entwickeln wir nicht nur Software sondern oft auch eine neue Kultur.

Microservices

Um große Systeme geht es auch beim Thema Microservices: Diese dienen dazu komplexe Systeme in einzelne Programme und Aufgaben aufzuteilen. Einen ganz ähnlichen Ansatz verfolgt schon die UNIX Philosophie, die auf drei Ideen basiert: Ein Programm soll nur eine Aufgabe erfüllen, die Programme sollen zusammenarbeiten können und die Programme sollen eine universelle Schnittstelle nutzen. Der Haken bei der Sache: Microservices-Architekturen ermöglich ein hohes Maß an Flexibilität in der Entwicklung, erhöhen aber gleichzeitig die Komplexität des Gesamtsystems. Die Herausforderung besteht deshalb darin, die vielen Komponenten des Systems so zu orchestrieren, dass die Übersicht nie verloren geht. Bei eCube wägen wir deshalb in jedem Projekt genau ab, ob und an welchen Stellen eine Zerlegung nach Aufgaben sinnvoll ist, ohne dass der Aufwand den Nutzen übersteigt.

Spezielle Werkzeuge wie Istio und Linkerd können helfen, einen solchen “Service Mesh” in den Griff zu bekommen. Bei eCube nutzen wir aktuell Docker für die Containerisierung, Keycloak für IAM & Standard REST-APIs mit Spring MVC. Es empfiehlt sich, diese Tools in Software-Projekten so früh wie möglich einzusetzen, um von Beginn an die volle Kontrolle über die wachsende Zahl von Services zu behalten.

Lesetipp: Einen kurzen Überblick und Starthilfe für die Arbeit mit Microservices bietet das E-Book von Eberhard Wolf, dass man hier kostenlos herunterladen kann.

Damit hochkomplexe Microservice-Architekturen nicht im Chaos versinken, nutzen wir die Techniken des Chaos Engineering.

Chaos Engineering

Eine sehr praktische Herausforderung der Software-Entwicklung adressiert das „Chaos Engineering“: Wie schafft man es, resiliente IT-Systeme zu bauen, die auch bei Teilausfällen noch funktionieren? Wie lassen sich Flexibilität der Entwicklung und die Geschwindigkeit der Bereitstellung (Time to market) in verteilten Softwaresystemen erhöhen, ohne dass beispielsweise die Wechselwirkungen zwischen verschiedenen Diensten in verschiedenen Systemen zu unvorhersehbaren Ergebnissen bzw. Fehlern oder Ausfällen führen?

„Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.“ (principlesofchaos.org)

Die Herausforderung in der Software-Entwicklung besteht darin, Schwachstellen zu identifizieren, bevor sie sich in systemweiten, anormalen Verhaltensweisen manifestieren. Das ist leichter gesagt als getan und setzt voraus, dass Architekten und Entwickler wieder lernen, mehr systematisch zu experimentieren, statt jeden erdenklichen Fall voraussehen zu wollen. Ein Ansatz kann hier sein, „Chaos“ durch kleine Experimente in der Staging-Umgebung zu testen. Russ Miles, CEO von ChaosIQ hat dazu auf der JAX Konferenz 2018 einen sehr inspirierenden Vortrag gehalten:

Einen groben Überblick, wie Chaos Engineering in der Praxis aussehen kann, geben die „Principles of chaos engineering“. Wir werden in einem weiteren Artikel hier im Blog näher darauf eingehen.

Fazit: neue Ansätze brauchen neues Denken

Neben den hier skizzierten Trends entstehen laufend neue Ideen und Konzepte für die Java-Enwicklung. Viele etablieren sich in der Praxis, während andere wieder verpuffen. Bei eCube greifen wir neue Methoden und Tools auf, wenn uns diese sinnvoll und praktikabel erscheinen, um Projekte flexibler und wirtschaftlicher umzusetzen. Dazu gehört derzeit etwa Kubernetes für die Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen. Dabei gehen wir ebenso agil bzw. iterativ vor wie in unseren Projekten. Das ist vor allem dann wichtig, wenn neue Ansätze eine Veränderung im Denken und in der Kultur erfordern, damit sie ihre volle Wirkung entfalten können. Wir werden in unserem Blog weiterhin von unseren Erfahrungen berichten.