Die wichtigste Person im Online-Shop Business ist der Kunde. Diesem wollen wir eine optimale User Experience bieten. Hierzu sind permanente Optimierungen und Conversion-Experimente (A/B Tests) notwendig. Unsere gewachsenen IT-Strukturen bremsen uns allerdings oftmals aus. Wir stellen einen Ansatz vor, mit dem wir zurück zur Agilität finden und gleichzeitig eine Reihe weiterer Schätze heben können.
Ein Shopsystem besteht aus unterschiedlichsten Komponenten, eingebettet in ein zumeist komplexes Ökosystem. Technologisch betrachtet sind Shopsysteme sog. Software-Monolithen. Alle für den Shop wesentlichen Funktionen, sind in eine in sich gekapselte Software integriert und funktionieren nicht bzw. eingeschränkt voneinander losgelöst. Alle Komponenten bauen aufeinander auf und können nur gemeinsam bzw. unter vollständiger gegenseitiger Abhängigkeit angepasst und genutzt werden. Dies hat einen unschlagbaren Vorteil: Das System ist grundsätzlich recht einfach zu betreiben, da bswp. externe Abhängigkeiten nicht oder nur in geringem Maße vorkommen. Auch programmatische Änderungen und vor allem neue Featutres sind für Entwickler zukünftig mit überschaubarem Aufwand verbunden.
Dem gegenüber stehen allerdings einige Nachteile. Bei wachsenden Systemen und kontinuierlicher, kurzfristiger Weiterentwicklung (vor allem in größeren Teams) wird es schnell unübersichtlich und Entwicklungen können sich gegenseitig massiv behindern. Sei es funktionell oder einfach nur in der Umsetzungsgeschwindigkeit, da jede Partei auf deine andere Warten muss. Eine weiterführende Erörterung der Vor- und Nachteile sowie einen Lösungsansatz können unter dem Stichwort “Microservice Architekturen” nachgelesen werden.
In diesem Beitrag wollen wir jedoch nicht grundsätzlich auf das Für und Wider von Microservices eingehen, sondern uns einen naheliegenden Use Case herauspicken, für dessen Lösung die Anwendung des Microservice Gedanken nahelegt.
An dieser Stelle, möchten wir einen Lösungsansatz für die unterschiedlichen Anforderungen an eine Shop-Infrastruktur liefern. Das folgende Schaubild zeigt grob den Lebenszyklus der einzelnen Bestandteile bzw. Ebenen eines Shopsystems. Die verwendeten Begrifflichkeiten sind wie folgt zu verstehen.
Backend meint in diesem Kontext nicht das Admin-Interface, sondern alle Prozesse und Verwaltungsfunktionen zur Abwicklung von Bestellungen und der Pflege der Produktdaten und weiterer Inhalte. Diese Teile umfassen beispielsweise Anbindung und Steuerung der Warenwirtschaft und Logistik. Typischerweise werden diese Systeme einmal aufgebaut, wachsen oftmals im Nutzungsumfang und -tiefe mit und werden selten ausgetauscht. Auch die dahinterliegenden Prozesse sind als recht langlebig zu betrachten.
Unter Middleware verstehen wir in diesem Modell solche Komponenten, die Verbindungen zu (externen) Services herstellen oder auch eine unterstützende Komponente wie die Onsite-Suche, Recommendation Engines, Tracking Pixel etc.
Das Frontend wiederum umfasst im Wesentlichen das User Interface; üblicherweise eine PHP/HTML Applikation unter Berücksichtigung des responsiven Webdesign.
Diese drei Ebenen weisen unserer Erfahrung nach nun eine unterschiedliche Lebensdauer, viel wichtiger vor allem einen sehr unterschiedlichen Zyklus auf, in dem diese verändert werden (müssen). Das Frontend ist dabei viel häufiger Gegenstand von Anpassungen bzw. sollte es hinsichtlich eines anspruchsvollen UI sein, als andere Systembestandteile, wie bspw. eine ERP Anbindung.
Vor allem aber stellt das Frontend das Interface für die Interaktion mit den Benutzern dar. An dieser Stelle wird - neben dem Sortiment - durch die User-Experience über den Erfolg einen Online-Shops entschieden. Der Großteil aller Anstrengungen für jede Art von Optimierung, sollte konsequenterweise somit der UI dienen. Hier hängen die niedrigsten und saftigsten Früchte :) Oftmals stellt es sich allerdings vor allem bei wachsenden Projekten als zunehmend herausfordernd dar, in-time und in-budget Anpassungen und neue Funktionen für das User Interface zu implementieren. Die Qualität leidet unter Abhängigkeiten, die vor allem durch die Architektur und das Produktversprechen der oftmals verwendeten Standard-Software gegeben sind. Die integrierten Template Engines sollen möglichst generalistisch Updates und Plug-In Strukturen gerecht werden. Je stärker ein Frontend customized wird, desto mehr schlägt das Pendel Richtung Individualentwicklung aus. Der Aufwand für zukünftige Maßnahmen steigt exponentiell.
Dieser Umstand führt zu verschiedenen Konsequenzen: Notwendige Weiterentwicklungen und Experimente werden nicht mit der notwendigen Geschwindigkeit bzw. zu sinnvollen Budget umgesetzt. Die Tendenz in Kraftakten wie kompletten Relaunches nimmt zu und damit auch das erhebliche Risiko gravierende Fehlentwicklungen zu implementieren (bspw. SEO Risiken eines Relaunch). Vor allem aber kann kein Kreislauf des stetigen Lernens und damit verbundener Optimierungen einsetzen, welche übrigens bei Erfolg direkt einen Return in Form steigender Umsätze bzw. sinkender Marketingausgaben bringen, weil jeder Projektteilnehmer sich ausgebremst sieht.
Finden wir also eine Lösung für dieses Dilemma. Unser monolithisches Shop-System haben wir lieb gewonnen, vor allem ist es komplex, tief integriert und schon alleine der hohen getätigten Investitionen wegen, dazu auserkoren, möglichst unberührt noch viele Monate seinen Dienst zu tun. Das Frontend wollen wir agil aufstellen und permanent und vor allem mit den neuesten Möglichkeiten modernisieren.
Trennen die Bereiche also voneinander: Backend, Middleware und Frontend werden von nun an, voneinander abgekapselte Komponenten darstellen, die über eine formal definierte API miteinander kommunizieren. Backend und Middleware behalten wir unserem bisherigen Setup bei. Die gewachsene Standardlösung tut weiterhin das, was sie besonders gut kann und steuert sämtliche Workflows und stellt ein Tool für die Administration bereit.
Das Frontend agiert zukünftig alleine und kann direkt auf die Erfordernisse des jeweiligen Shops individualisiert werden. Sämtlichen Ballast können wir auf diese Weise abschütteln und fortan gradlinig und unabhängig sehr effizient Optimierungen einziehen. Durch einen technologischen Unterbau, der auf einem leichtgewichtigen PHP, JavaScript und Elasticsearch Stack baisert, können ideale Bedingungen für die Performance der Website geliefert werden, welche ohne Full Page Caching auskommen und auch facettierte (Filter) Darstellungen in Millisekunden ausspielt.
