Überlegungen zur Architektur bei internationalen Rollouts von B2C-Webshops zwischen Monolith, Microservices und Self-contained Systems

Durch internationale Webshop-Rollouts neue Umsätze generieren – mit diesem Plan liebäugeln zurzeit viele Handelsunternehmen. Allerdings ist der digitale Schritt ins Ausland aufgrund zahlreicher Fallstricke alles andere als ein Kinderspiel. Eine gründliche Planung der Internationalisierung ist daher die Grundvoraussetzung, um neue Märkte zu erobern.

Die Umsatzkurve im E-Commerce zeigt weiter nach oben: Laut Prognosen des US-amerikanischen Marktforschungsunternehmens eMarketer wird der globale Onlinehandel 2017 erstmals über 2 Billionen US-Dollar erwirtschaften. Bis 2020 könnte sich diese Summe sogar noch einmal verdoppeln. Eine Erfolg versprechende Strategie, um an diesem Wachstum zu partizipieren, sehen viele Händler in einer Internationalisierung ihres Onlinegeschäfts.

Die Strategie bestimmt die Anforderungen

Dieses Wachstum zu realisieren, ist allerdings ein hochkomplexes Unterfangen, das eine umfassende Internationalisierungsstrategie nötig macht. Händler müssen hierbei die individuellen Gegebenheiten des eigenen Unternehmens analysieren und darauf aufbauend eine individuelle Vorstellung der bevorstehenden internationalen Expansion formulieren. Besonders wichtig ist dabei vor allem eine Frage: Wie stark möchte man als Handelsunternehmen auf die länderspezifischen Besonderheiten der ins Auge gefassten Zielmärkte eingehen?

Die zentrale Frage ist: Wie stark sollen länderspezifische Besonderheiten berücksichtigt werden?

Die Antwort auf diese Frage hängt in hohem Maße von den spezifischen strategischen Überlegungen des Unternehmens ab. Daher existiert zum Leidwesen so mancher Händler keine über jeden Zweifel erhabene Patentlösung für einen erfolgreichen internationalen B2C-Shop-Rollout. Stattdessen muss jede Firma innerhalb einer großen Bandbreite an Optionen ihren eigenen Weg finden.

So besteht beispielsweise die Möglichkeit, ein Unternehmen auch über Ländergrenzen hinweg zentralistisch zu führen. In der Firmenzentrale getroffene Entscheidungen müssen in diesem Fall auch international umgesetzt werden. Derartig geprägte Unternehmen legen logischerweise Wert darauf, auch neu entstehende Webshops zentral entwickeln und pflegen zu können oder alle Produkte über einen einzelnen Shop zu verkaufen.

Daneben existieren jedoch auch Firmen, die im Zuge ihrer Internationalisierung eigene Ländergesellschaften gründen, die das Geschäft in den Zielmärkten selbst managen und aufgrund ihres Detailwissens über den Markt auch geschäftskritische Entscheidungen – wie die Ausgestaltung eines Webshops – weitestgehend eigenständig fällen (dürfen). Auch das Marketing mit seinen für den Geschäftserfolg zentralen Elementen wie Pricing, Angebotsmanagement und Entwicklung eines durchgängigen Look & Feel in allen Vertriebskanälen wird häufig den Länderorganisationen überlassen. Demnach fällt die Entscheidung, ob ein Produkt, das in Frankreich herausragende Umsätze erzielt, auch in Russland angeboten und dort zum selben oder zu einem anderen Preis verkauft wird, in derartig aufgestellten Unternehmen meist direkt in den Zielmärkten und nicht in der Konzernzentrale. Die Zentrale überträgt den Ländergesellschaften somit ein hohes Maß an Flexibilität und Verantwortung. Diese sind damit in der Lage, selbstständig auf die Konkurrenzsituation in ihrem Markt zu reagieren.

Die beiden soeben vorgestellten Varianten dienen lediglich als Beispiele dafür, wie sich die allgemeine Unternehmensstrategie auf die Planung und Umsetzung der Internationalisierung des Webshops auswirken kann. Daneben existieren unzählige weitere Wege, das eigene Unternehmen in neue Märkte zu führen. Fest steht dagegen, dass die Webshop-Facharchitektur zur favorisierten Internationalisierungsstrategie und den daraus entstehenden Anforderungen passen muss.

Der klassische Monolith

Viele Händler sehen in einer monolithischen Architektur zunächst die pragmatischste Lösung, wenn sie ihr Internationalisierungsprojekt beginnen. In diesem Fall wird ein neu entstehender Shop aus dem bereits bestehenden Shopsystem heraus entwickelt. Alle auf diese Weise in Produktion gebrachten internationalen Shops sind somit Teil eines abgeschlossenen Systems. Diese Variante bietet einen großen Vorteil: Da die neuen Shops den Mustern der bestehenden folgen können, verursacht ein internationaler B2C-Shop-Rollout innerhalb eines Monolithen relativ wenig Aufwand – und ist damit verhältnismäßig schnell und preisgünstig möglich.

Eine erhebliche Herausforderung der monolithischen Struktur zeigt sich dagegen später, wenn bereits einige Länder-Shops gelauncht sind: Obwohl der Ausgangsshop die Basis für die neu entstehenden Webshops darstellt und viele Charakteristika übernommen werden können, müssen auch zentralistisch geprägte Händler ihre internationalen Shops zumindest minimal an die länderspezifischen Besonderheiten anpassen, die der jeweilige Markt vorgibt. So können sich nicht nur Sprache, Schrift und Währung von Land zu Land unterscheiden, auch die Präferenzen hinsichtlich der Zahlungsmethoden gehen oftmals weit auseinander. Darüber hinaus besitzt beinahe jeder Staat seine ganz eigenen Regeln im Hinblick auf Informationspflichten oder Steuern.

Diese Besonderheiten können in einem Monolithen zu zusätzlichen Aufwänden führen. Zum einen sind die Möglichkeiten, auf sie einzugehen, innerhalb eines Monolithen begrenzt, da alle Shops teilweise auf dieselben Elemente zurückgreifen und jede fachliche Änderung oder Erweiterung die internen Zusammenhänge berücksichtigen muss. Jedem Zielmarkt beispielsweise die im jeweiligen Land populären Zahlungsmethoden anzubieten, ist unter diesen Voraussetzungen ebenso aufwändig wie die Einhaltung der unterschiedlichen rechtlichen Rahmenbedingungen in den einzelnen Ländern. Zum anderen wird der Monolith mit jedem weiteren Shop und jedem weiteren Sonderfall größer und komplexer, sodass das System immer unübersichtlicher und schwerer wartbar wird.

Ab einer bestimmten Anzahl von Shops ist darüber hinaus eine effiziente Testabdeckung in einer reinen monolithischen Architektur nur noch mit hohem Aufwand möglich. Schließlich können sich Änderungen aufgrund der gemeinsamen Nutzung der funktionalen Elemente potentiell auf alle Shops auswirken. Die Auswirkungen derartiger Updates müssen somit in sämtlichen Ländern getestet werden – selbst wenn ein Update aus fachlicher Perspektive lediglich für einen einzigen Shop von Belang ist. Die Gefahr, in eine Testfalle zu geraten, ist groß. Die Gewährleistung der Testbarkeit bei steigender Komplexität ist daher ein zentrales Kriterium bei der Auswahl einer Architektur. Eine hohe automatisierte Testabdeckung kann dieses Problem entschärfen, ist jedoch ebenfalls mit erheblichem Aufwand und entsprechenden Kosten verbunden.

Modularisierung innerhalb eines Monolithen

Die stetig wachsende Komplexität zu begrenzen, ist eine der großen Herausforderungen, denen sich Händler stellen müssen, die ihr Internationalisierungsprojekt mit einer klassischen monolithischen Architektur vorantreiben. Die vielversprechendste Möglichkeit, der Komplexität Herr zu werden, besteht in der Modularisierung der großen Gesamtstruktur in kleinere, fachlich abgegrenzte Komponenten. Hierfür muss die monolithische Basis des Systems jedoch nicht zwangsläufig aufgelöst werden. Stattdessen leistet dieses Vorgehen innerhalb eines Monolithen einen Beitrag dazu, die Testbarkeit des Systems effizienter zu gestalten: So müssen neue oder veränderte Systemkomponenten nicht mehr in allen Ländershops getestet werden. Man muss für ein Update somit nicht das komplette System überblicken.

Die Modularisierung erhöht die Flexibilität des Projekts.

Darüber hinaus erhöht die Modularisierung die Flexibilität des Projekts: Durch die Anpassung der Komponenten an konkrete fachliche Anforderungen ist es möglich, gleichzeitig verschiedene Entwicklerteams relativ unabhängig voneinander an unterschiedlichen Modulen arbeiten zu lassen. Auf diese Weise können auch länderspezifische Sonderfälle effizienter umgesetzt werden. Grenzenlos ist diese Flexibilität jedoch nicht. Da der Monolith weiterhin auf einer gemeinsamen technischen Basis aufgebaut ist, können neu entwickelte oder überarbeitete Komponenten nur gemeinsam deployed werden. Stattdessen muss ein Release des gesamten Monolithen so koordiniert werden, dass die Module auch weiterhin zueinander passen. Unerwünschte Wechselwirkungen innerhalb des Monolithen auszuschließen, ist somit weiterhin eine aufwändige Verwaltungsaufgabe.

Verteilte Systeme: Microservices und Self-contained Systems

Monolithische Strukturen sind nicht die einzige Möglichkeit, einen Webshop aufzubauen. Daneben besteht auch die Option, die Module in separate Services zu kapseln und ein verteiltes System aus einzelnen Komponenten zu schaffen. Derartige Systeme können z.B. aus Microservices oder Self-contained Systems (SCS) aufgebaut werden.

Innerhalb der Microservices-Architektur werden komplexe Anwendungen aus sehr feingranularen, voneinander unabhängigen Services zusammengesetzt. Darauf basierend können individuell für jeden Shop die Microservices, die er benötigt, bis ins Detail ausgewählt werden. Allerdings hat der kleinteilige Aufbau einen Nachteil: So gestaltet sich die Verwaltung und Pflege der Microservices aufgrund ihrer meist hohen Anzahl sowie ihrer zahlreichen Schnittstellen untereinander als schwierig. SCS sind im Gegensatz zu Microservices größer angelegt. Im Gegensatz zu ihrem feingranularen Pendant sind sie als eigenständige Webanwendungen konzipiert, die aufgrund einer eigenen Datenhaltung sowie einer integrierten Businesslogik und eines User Interfaces separat nutzbar und flexibel austauschbar sind. Bei Bedarf können SCS als Basis wieder auf Microservices zurückgreifen.

Für welche Variante sich ein Händler auch entscheidet: Durch die stark ausgeprägte Verkapselung der einzelnen Module innerhalb des verteilten Systems, ist es nun möglich, länderspezifische Komponenten unabhängig zu entwickeln und separat zu deployen. Dadurch bietet diese Architektur insbesondere Händlern Vorteile, die ihren Ländergesellschaften möglichst viel Gestaltungsspielraum in der Ausgestaltung ihrer Webshops bieten möchten und diese auf lokalen Servern in den Ländern betreiben. Die Entwicklerteams, die eventuell sogar in den verschiedenen Gesellschaften verortet sind, sind somit in der Lage, sich und ihre Arbeit eigenständiger zu organisieren. Theoretisch ist sogar die Auswahl unterschiedlicher Technologien möglich. Zudem erhöht sich auch in dieser Architektur die Testeffizienz, da die Auswirkungen von Updates nur in den Shops überprüft werden müssen, die die Komponente aktiv nutzen.

Zentraler Kern im verteilten System

Dass den Ländergesellschaften für jede Funktionalität ein individuell entwickelter Service zur Verfügung gestellt werden könnte, heißt jedoch nicht, dass dies auch aus Perspektive der Effizienz sinnvoll ist. Stattdessen können Services, die von sämtlichen Shops genutzt werden, in einem zentralen Kern zusammengeführt werden. Länderspezifische Services sind in diesem Fall dagegen ausgelagert und lediglich lose an den Kern gekoppelt. Dieses Vorgehen hat zwei Vorteile: Zum einen bleiben die Kernservices übersichtlich, testbar und beherrschbar und zum anderen gefährden Änderungen in den lokalen Services nicht den Kern.

Doch welche Services können Bestandteil der auf alle Ländershops ausgerichteten Zentralkomponente sein und welche Problemfelder sollten für jedes Land individuell gelöst werden? Aufgrund der immensen Unterschiede zwischen den Internationalisierungs- und IT-Strategien einzelner Unternehmen lässt sich auf diese Frage keine allgemeingültige Antwort geben. Das Motto „Global, wo möglich – lokal, wo nötig“ bietet nach unserer Erfahrung jedoch eine grobe Richtschnur.

Global, wo möglich – lokal, wo nötig

Um sich nicht doch in eine Testfalle zu manövrieren, sollte die Zentralkomponente diesem Motto entsprechend nicht zu viele – und vor allem für häufige Updates anfällige – Features beinhalten. Stattdessen ist es sinnvoll, insbesondere die absoluten Basisstrukturen in ihr zu integrieren. Diese beschränken sich auf die wesentlichen Bausteine eines Onlineshops wie den Produktkatalog, in dem die Bestandteile des Sortiments abgelegt sind. Darüber hinaus können auch Funktionalitäten wie die Suchfunktion oder die Grundfunktionen des Warenkorbs hinzukommen, die sich auch international in der Regel problemlos vereinheitlichen lassen.

Wie schnell länderspezifische Besonderheiten ins Auge gefasst werden müssen, zeigt sich dagegen mit Blick auf die Preiskalkulation innerhalb des Warenkorbs: Regionale Unterschiede wie verschiedene Versandkosten sprengen im Handumdrehen die Grenzen einer global angelegten Standardfunktionalität. Daher sollte die Preiskalkulation so angelegt werden, dass sie sich mühelos durch regionenspezifische Komponenten erweitern lässt. Für ein neues Feature müsste dann lediglich eine weitere Komponente erarbeitet werden, die prinzipiell für sämtliche Länder verfügbar ist – auch wenn sie letztendlich nur von einigen Shops genutzt wird. Eine Änderung an dieser Komponente würde sich dann – wie oben beschrieben – ausschließlich auf die Länder auswirken, die sie auch aktiv nutzen. Der Testaufwand wäre somit überschaubar.

Eine weitere Möglichkeit, sowohl den Programmieraufwand als auch die Testproblematik zu reduzieren, ist die Einrichtung von Mehr-Länder-Clustern. Die Grundlage für die Bildung derartiger Cluster bildet jedoch bildet jedoch nicht unbedingt die Sprache – indem beispielsweise alle englischsprachigen Shops auf gemeinsamen Servern zusammengefasst werden. Stattdessen spielen ähnliches Einkaufsverhalten und vergleichbare Formen der Kundenansprache sowie daraus entstehende kompatible Muster in der Komponentenstruktur eine Rolle bei der Entscheidung, welche Länder einen Cluster bilden. Darüber hinaus lassen sich über derartige Cluster auch Shops kleinerer Märkte – sofern diese nicht über die nötige Infrastruktur verfügen, um die Pflege in Eigenregie zu übernehmen – zentral oder von einem größeren Land pflegen. Auf diese Weise lässt sich die Verantwortung für die Shop-Pflege zwischen lokalen und zentralen Teams nahezu stufenlos variieren.

 

Fazit: Die Architektur bestimmt maßgeblich über den Erfolg

Die Auswahl einer zum individuellen Expansionsprojekt passenden Architektur ist einer der zentralen Schlüssel zu einem erfolgreichen (und langfristig bezahlbaren) internationalen B2C-Shop-Rollout. Handelsunternehmen sehen sich dabei insbesondere mit der Herausforderung konfrontiert, den Wunsch nach Flexibilität in der Ausgestaltung der einzelnen Webshops mit der Notwendigkeit der Effizienz vereinen zu müssen. Der Aufbau eines modularisierten Systems, das sowohl das Deployment flexibilisiert als auch die Testbarkeit erhöht, ist der entscheidende Schritt zu dieser Balance. Auf diese Weise ist es möglich, digitales Geschäft unmittelbar aufzubauen und gleichzeitig flexibel genug aufgestellt zu sein, um zukünftige Geschäftsmöglichkeiten mit der bestehenden Architektur schnell zu verwirklichen.