Von Machiavelli springen wir ganz schnell wieder zum aktuellen e-Commerce. Aber was hat das altbekannte „Teile und Herrsche“-Sprichwort hier verloren? Beleuchten wir einmal kurzweilig, wie Shopware 6 einen cleveren Trend aufgreift – oder einfach die Art und Weise wie Online-Systeme in Zukunft funktionieren sollten.
Rückblick – egal wie oft ihr das schon last
Wie viele andere Systeme auch, waren Shop-Systeme (ganz früher) große unbewegliche Steine. Richtige Monolithen. Für alle aus der e-Commerce und IT-Branche ist klar, was solche Monolithen bedeuten. Für einen Shop wirft man im Grunde alles, was man für einen Auftritt im Online-Handel braucht in den Mixbecher – Warenwirtschaft, Rechnungsstellung, Benachrichtigungssystem, Accounting, Preise, Bilder, erweiternde Inhalte – schüttelt gut durch und hofft, dass dieses System dann solange wie möglich den Anforderungen gerecht bleibt.
Das dies nicht dauerhaft der Fall sein kann, liegt in der Natur der Sache, bzw. dieses Monolithen. So war (früher) der nächste Schritt in der Evolution, dass man keinen großen Monolithen aus einem Guss schafft, sondern den Monolithen aus mehreren Teilen zusammensetzt. Das Endergebnis war immer noch ein Monolith, aber man konnte bei Bedarf das eine oder andere Teil austauschen oder sogar erweitern durch einen, vielleicht auch über Schnittstellen, „angepinnten“ Monolithen-Teil. In dieser Ära war es auch langsam aber sicher soweit, dass sich Spezialisten für einzelne Komponenten eines solchen Monolithen etablierten. Warenwirtschaft, Rechnungsstellung, Benachrichtigungs-System, Payment und viele weitere Kanäle die im Online-Handel an Bedeutung gewannen, hatten ihre eigenständigen Vertreter bzw. Dienste aka Services.
In dieser Ära befinden wir uns eigentlich immer noch. Auch wenn man freudiger Weise feststellt, dass sich kein System mehr auf die Bühne wagt, wenn es nicht umfassend erweiterbar und ausbaufähig ist – mit allem Pipapo was die Communities erwarten – damit man in der digitalen Öffentlichkeit nicht in der Luft zerrissen wird.
Der Open-Source Aspekt ist für das eingangs erwähnte „Teile und Herrsche“-Prinzip sehr wichtig, ebenso wie die Tatsache, dass sich die Dinge von alleine und immer mehr zu „Services“ hin entwickeln.
Anders ausgedrückt: Möglichst kleine, professionelle Einheiten, die ihre ganz spezielle Aufgabe mit Bravour meistern und sowohl vom Anwender als auch von Entwicklerkreisen den Ritterschlag der Akzeptanz erhalten, auf der einen Seite. Und auf der anderen Seite eine Orechestrierung dieser Dienste aka Services, um im gemeinschaftlichen Wirken ein Gesamtsystem zu schaffen, dass einen ganz bestimmten Business-Case abdeckt. Wie zum Beispiel einen Online-Shop.
Zurück zu Shopware 6
An dieser Stelle können wir auch wieder zu Shopware 6 im speziellen zurückkehren, denn nichts anderes hat der Shop-Spezialist aus Schöppingen verstanden und umgesetzt – eine Architektur, welche diese prinzipien der Zukunft aufgreift und Umsetzt.
Wo früher bei Shopware bis zur Version 5 Backend, Frontend und die Persistierung der Daten des Shops monolithisch miteinander verbunden waren – trotz einer durchaus guten Erweiterbarkeit über Plugins, welche Zahlungsdienstleister usw. lieferten – da finden sich heute bei Shopware 6 nur noch getrennt voneinander arbeitende Dienste aka Services.
Diese Services werden orchestriert und finden sich alleine für den Anwender „visuell zusammengefasst“ in einem Backend und einem Frontend wieder. Für Entwickler aber ist es der Beginn einer anderen Art wie mit Systemen umgegangen werden muss, will man mit diesen arbeiten. Schnittstellen hat jeder schoneinmal gehört oder als Entwickler umgesetzt, doch in eine Orchestrierung hineinzuarbeiten, ist dann doch ein bisschen was Anderes.
Aber auch für den Shopbetreiber wird es eine andere Erfahrung sein, wenn er wie früher mitbekommt, dass Warenwirtschaft und Rechnungsstellung Offline sind, der Bestell-Prozess in seinem Shop dennoch problemlos durchläuft. Während dieses Szenario in den Altvorderen auch durch hohen Aufwand und tiefe entwicklerische Kenntnisse erreicht werden konnte, sollte so etwas direkt durch die Architektur selbst gestemmt werden.
Man bedenke: Ein Monolith, wenn er eine Störung hat, hat immer die Chance auch als Ganzes auszufallen. Hingegen können Services nicht erreichbar sein oder ausfallen, den Rest des Orchesters darf dies aber nicht interessieren, es sei denn der Dirigent gibt das Signal zum Stop – solange klingt es höchstens nicht so schön.
Wie entscheide ich mich?
Was bedeutet das also jetzt für diejenigen die darüber nachdenken ein Shopware 6 System aufzusetzen, oder zu Shopware 6 zu wechseln, oder von einem 5er System auf ein 6er zu updaten?
Machen wir es kurz und prägnant und von hinten nach vorne:
Bei einem Update von Shopware 5 auf 6 ist es de Facto kein Update, sondern eine Migrierung der Daten aus einem „Alt-Shop-System“ in ein architektonisch völlig anders arbeitendes Shopware 6 System. Bei einem Wechsel eines vorhandenen Shopsystems zu Shopware 6 macht es umso mehr Sinn, je älter das vorhandene Shop-System ist und dessen Hersteller keine ähnlich modern denkende Architektur als Alternative bietet. Beim initialen Aufsetzen eines Shopware 6 Systems als Erstsystem, sollte man sich im Klaren sein, dass sowohl Agenturen als auch Entwickler, die man beauftragen möchte (aktuell), sich über die Andersartigkeit der Architektur im klaren sein müssen.
Der letzte Punkt geht soweit, dass das angepeilte Prinzip dieser Orchestrierung und seiner Services unter Umständen besser verstanden werden oder mehr Bereitschaft herrschen muss dies umzusetzen als beim Hersteller selbst. Der Hersteller (Shopware), bleibt der Dirigent, aber der einzelne Instrumentalist (Service, Dienstleister, Entwickler), muss zusehen dass er den Dirigent richtig versteht und ihm dass als Resonanz zurückliefert, was erwartet wird und womit dieser arbeiten kann.
Fazit
Machen wir uns nichts vor, es handelt sich um eine neue Art Software-Systeme im elektronischen Handel zu etablieren. Sind die einzelnen Methoden, unterliegenden Prinzipien oder Architekturansätze für sich einzeln genommen vielleicht schon in den 80iger/90iger Jahren gedacht worden, so kommen wir jetzt zum Ende des zweiten Jahrzehnts des neuen Jahrtausends zu den realen Anwendungsfällen im Web.
Das dritte Jahrzehnt wird das der verteilten Software auf BASIS verteilter Services sein – was weit über SaaS (Software as a Service) hinausgehen wird. Aus der Sicht des Pioniergedanken macht es absolut Sinn auf diesen Zug aufzuspringen und es ist Clever – von Shopware, Spryker, SAP Hybris und Allen die sich darum bemühen – jetzt damit zu beginnen. Um seinem Business und seinen Produkten einen seriösen Auftritt im Internet zu verschaffen, der hohe Umsätze erzielt, kann man absolut mit den aktuell gebräuchlichen Architekturen aufwarten. Aber das Drumherum wandelt sich stets und spätestens in 2025 sollte man bereits soweit gewesen sein diesen Zug mitzufahren.
- Monib Asad Masud
