Glossar & Hintergrund
Monolithen
Es gibt verschiedene, grundlegend unterschiedliche Ansätze für die Architektur von Ecommerce Systemen. Nach der ersten Reihe von oft selbstgebauten Systemen Ende der 90er Jahre, gab es in den frühen 2000er Jahren die ersten massentauglichen Shopsysteme. Dies waren meist große, monolithische PHP-Applikationen, die durch Entwickler der Kunden oder Agenturen angepasst und auf dedizierten Servern gehostet wurden. Um diese Systeme, von denen heute noch viele sehr weit verbreitet sind, hat sich über die Jahre ein umfangreiches Ökosystem aus Agenturen und Entwicklern von Extensions gebildet. Im Kern handelt es sich aber weiter oft um 15 oder 20 Jahre alte monolithische Systeme, die aufgrund der umfangreichen Erweiterungen nur schwer zu erneuern sind und die erhebliche Herausforderungen bei der Skalierung bereiten. Für die Anforderung eines Enterprise Systems kommen diese daher heute kaum moch in Frage.
API First, Headless
Im Laufe der 2010er Jahren gab es eine neue Welle von Ecommerce Systeme, deren Architektur moderner und skalierbarer war. Im Gegensatz zu ihren monolithischen Vorgängern, wurde auf eine Trennung von Frontend und Backend geachtet. Zuerst wurden ältere Systeme um APIs ergänzt, die Teile der Shop Funktionen abbildeten. Später wurden auch "API First" Systeme entwickelt, die vollständig über die API bedient werden konnten. Eine weitere Spezialität waren die ersten "Headless"-Systeme, bei denen das Ecommerce System im Grunde ohne Frontend angeboten wird, also nur eine API bereitgestellt wird. Dies ist der Annahme geschuldet, dass große (Enterprise-) Kunden ihre Frontends aufgrund des hohen Individualisierunggrades in der Regel selbst entwickeln, und nur die dahinterliegenden Shop Funktionalitäten (Warenkorb, Zahlung, Bestellabwicklung) nicht selbst entwickeln wollen. Dies sind aus technischer und funktionaler Sicht Commodities, die als Services eingekauft werden. Der Nachteil ist natürlich, dass das Frontend bei dieser Lösung erst komplett entwickelt werden muss, was meist Monate dauert und dazu führt, dass Entwicklungsteams an vielen Stellen das Rad neu finden müssen.
All-in-One-Suites
Es gibt eine Reihe von nicht-modularen Systeme, die die gesamte Funktionspalette des Online Shops abbilden. Der Nachteil der komplexen, geschlossenen Systeme ist ein alles oder nichts Ansatz. Man bekommt zwar alle Funktionen aus einem Guss und alles ist idealerweise gut aufeinander abgestimmt, die Elemente sind aber nicht modular und austauschbar. Wenn einzelne Funktionen für die eigene Anforderung nicht ausreichend sind, ist das System kaum erweiterbar. Der Shopbetreiber ist also im Guten wie im Schlechten mit dem Standard des Systems verhaftet. Viele Systeme am Markt sind über die Zeit auch durch Akquisitionen gewachsen, dadurch wurde das System der Anbieter durch Zukäufe weiterer Produkte schnell erweitert. Die Integration unterschiedlicher Software-Produkte gestaltet sich sehr schwierig, dadurch hat man in der Praxis oft einen "Frankenstein Effekt", bei dem verschiedenste Funktionalitäten nicht nahtlos zusammenpassen, sondern sie eher zusammengeflickt wirken und man merkliche Brüche und Inkonsistenzen in der Nutzung hat.
Best of Breed
Als Gegenentwurf zu All-in-One-Suites hat sich der "Best of Breed" Ansatz weitgehend durchgesetzt. Hier wird anerkannt, dass eine vollständige E-Commerce Landschaft an sich zu komplex ist und die jeweiligen Anforderungen zu unterschiedlich sind, als dass ein einzelnes System jeden einzelnen Funktionsbereich optimal abdecken kann. Das Funktionsspektrum wird also auf verschiedene Komponenten aufgeteilt, wobei man aus jedem Funktionsbereich, das beste Tool der Wahl ("Best of Breed") von unterschiedlichen Anbietern verwendet, z.B. Recommendation Engine, Email Marketing, Personalization, CRM, ERP, Logistik, Pricing, etc.
Die Shopsysteme, die diesem Standard folgen, fokussieren sich auf Kernfunktionen wie Katalogverwaltung, Produktseiten, Warenkorb und Bestellerfassung. Weitergehende Funktionen (z.B. Personalisierung, Recommendations, AB-Tests) werden als Teil des Shopsystems abgebildet, dafür nutzt man dann spezialisierte Produkte und bindet diese an. Der Vorteil ist, dass man dadurch ein maßgeschneidertes und in jedem Bereich optimiertes System aufbauen kann. Der Nachteil ist, dass dies mit erheblichen Aufwand und Kosten verbunden ist. Nicht selten muss man Dutzende von Systemen einkaufen (die jeweils sehr teuer sein können) und diese alle miteinander verbinden. Dafür benötigt man wiederum große Entwicklungsteams, die sich mit den verschiedenen Produkten auskennen und diese auf einer Plattform vereinen. In der Praxis führt dies dazu, dass sehr viele mittelgroße Shops nur einige Kernfunktion anbieten und viele erweiterte, aber wichtige Funktionen einfach nicht abbilden können, darunter leiden die Customer Experience und am Ende auch die Conversion.
Composable Commerce
Composable Commerce beschreibt erst einmal dabei das Idee, dass die verschiedenen Komponenten, die unterschiedliche Business Domänen abbilden (Produkt Stammdaten, Warenkorb, Order Management), beliebig miteinander kombinierbar sein sollten (s. "Best of Breed"). In der Praxis gibt es hier allerdings keine technischen Standards. Auch wenn die verschiedenen Hersteller jeweils Schnittstellen anbieten, zum Beispiel Rest oder GraphQL, müssen diese alle noch miteinander verbunden werden. Es gibt keine einheitlichen Standards für Datenaustausch-Formate (Produktdaten, Bestelldaten), es bedeutet also viel Programmieraufwand, Einsatz kostspieliger Middleware und mühsames Nachhalten bei Änderungen. Hinzu kommt, bedingt durch die hohen Anforderungen an die Performance von Onlineshops (z.B. Google Web Vitals, Time-To-First-Byte), ist es kaum möglich, diese verschiedenen Komponenten und Micro Services in Echtzeit miteinander zu verbinden. Die zusätzliche Logik wird in der Regel erst nachgelagert ausgeführt, d.h. asynchron eingebunden, oder z.B. über das Frontend (z.B. AB-Tests), was ebenfalls zu Problemen in der Usability führt (z.B. CLS).
Micro Services
Einer der größten IT Architektur Trends der letzten Jahre war es, monolithische Applikationen in kleinere Services aufzuteilen, die jeweils in sich geschlossene, logische Funktionalitäten abdecken und untereinander kommunizieren, sofern nötig. Dies hat eine Vielzahl von Vorteilen bei der Entwicklung und Wartung der einzelnen Services, die kleiner und überschaubarer sind. Nachteil hierbei sind vor allem der Mehraufwand bei der Überwachung und dem Betrieb vieler einzelner Services, sowie die zusätzliche Latenz bei Kommunikation zwischen den Services.
Cloud Native
Dies bezeichnet den Ansatz, die Software bzw. einzelne Services als Container (Docker, Kubernetes) auf Cloud Servern zu betreiben, wodurch sie (jeder für sich) leichter zu verwalten und skalierbarer sein sollen. Es gibt keine offizielle Definition zu diesem Begriff und heute wird er auch von vielen Anbietern irreführend verwendet, die lediglich ihre monolithischen Applikationen auf einem virtuellen Server bei einem Cloud-Anbieter hosten. Dabei ist die Applikation nicht viel skalierbarer als vorher, lediglich die Hardware wurde ausgelagert.