Welche Shopsoftware würdest Du jetzt nehmen?

Die Frage “Welche Shopsoftware würdest Du jetzt nehmen?” stellte mir Lars Jankowfsky bei seinem Vortrag “E-Commerce was wirklich zählt. Die Developer Edition” auf der code.talks eCommerce Konferenz. Zuvor hatte ich bereits erzählt, dass ich 2010 für die Shops der CBR eCommerce GmbH (siehe meine Referenzen) OXID Enterprise Edition ausgewählt hatte. Die wesentlichen Gründe waren damals, dass der Quellcode einsehbar war, die Verfügbarkeit von PHP Entwicklern und die bessere out-of-the-box Performance im Gegensatz zu Magento.

Seinerzeit ist das eine richtige Entscheidung gewesen. Aber was würde ich heute wählen?

Da kam ich ins schwimmen und sagte etwas lahm “Vielleicht eher Shopware”, aber die Antwort war nicht gut. Im Gegensatz zu 2010 ist die verfügbare Technik heute deutlich breiter aufgestellt, wie ja gerade auf dieser Konferenz deutlich wurde. Ehrlicherweise hätte ich sagen sollen, dass ich das neu evaluieren müsste.

Die eCommerce Technik wird immer differenzierter

Interessanterweise schien selbst Alexander Graf, der mit Spryker einer der Hauptsponsoren des Events war, etwas überrascht gewesen zu sein, welch breiten Raum das Thema Microservices auf der Konferenz einnahm. In seinem Artikel “Microservices & Einradfahren” stellte er zunächst etwas verblüfft fest, dass es auch in der Welt der Techies so etwas wie Modetrends gibt, denen viele einfach hinterherlaufen. Er schrieb unter anderem:

“Zu meiner großen Enttäuschung muss ich nun feststellen, dass die Leute in der IT, bzw. Developer wie sie heute genannt werden, mit den gleichen Denkmustern arbeiten wie die Business Kasper [zu denen er sich selber zählt]. Es gibt eine extrem hohe Neigung Trends hinterherzulaufen und grundlegende technische Probleme nicht ausreichend bzw. nicht ehrlich genug zu analysieren.”

Für mich als Entwickler ist das natürlich überhaupt nichts Neues. Sehr viele Techies sind Diven mit aufgeblähtem Ego, die das Rad lieber zum 100. Mal neu erfinden – weil Ihr Rad natürlich viel viel schöner ist…

Der Rest des Artikels befasst sich damit, dass der Microservice-Ansatz gerade so ein angesagtes Ding ist, dass nicht ausreichend hinterfragt wird. Das Gefühl hatte ich allerdings nicht unbedingt. Für die vorgestellten Projekte gab es jede Menge gute Gründe, genau auf diese Architektur zu setzen – nur treffen die Gründe eben für die meisten “normalen” Shops bei weitem nicht zu.

Orientierung zwischen Standard-Cloud und Microservices

Doch wie findet man die passende Technik in dem scheinbaren Wirrwar aus Cloudanbietern, Self Hosting, Out-of-the-box Software, Frameworks, Microservices usw?

Das hängt natürlich vom konkreten Projekt ab. Zwei wesentliche Kriterien zur Einordnung von eCommerce Projekten wurden bei der Konferenz für mich deutlich: Das Umsatzvolumen und der Grad der Individualisierung des Geschäftes. Ich habe mal für mich selber aus diesen beiden Kriterien eine Entscheidungsmatrix mit neun Feldern aufgezogen.

Kriterium 1: Das Umsatzvolumen

Bei geringem Umsatzvolumen ist eine einfachere technische Architektur ausreichend, dafür ist hier die Preissensibilität hoch. Bei sehr großen Umsätzen kann und muss man größere Ressourcen in die technische Skalierung stecken, hat aber dafür auch einen größeren Investitionsspielraum.

Kriterium 2: Grad der Individualisierung

Wer ein überschaubares Sortiment mit (datentechnisch) einfachen Produkten anbietet, kommt bereits mit Standardtechnik sehr weit. Je mehr Besonderheiten gefordert sind, desto mehr Aufwand muss in die Anpassung gesteckt werden. Beispiele sind konfigurierbare Produkte, Regionallager und Multichannel. Besondere Geschäftsmodelle, wie z.B. Shoppingclubs, zeitlich begrenztes Angebot, Auktionen etc. lassen sich eigentlich nur noch mit Individualentwicklungen umsetzen.

Die Entscheidungsmatrix

Das Ergebnis meiner Überlegungen ist diese Matrix, deren neun Felder ich kurz erläutere.

Entscheidungsmatrix

1. Bei wenig Umsatz und Traffic können für Standardprozesse mit einem einfachen Sortiment bereits einfache und günstige Cloudlösungen gut geeignet sein.
   Kandidaten wären hier ePages, Prestashop u.ä.
2. Eine Anpassung an viele Besonderheiten kann bereits mit Standard Plugins für die üblichen Shopsysteme abgedeckt werden. Hier sollte aber ggf. bereits ein separates Hosting geplant werden, um in das System eingreifen zu können.
   Geeignete Kandidaten sind u.a. Shopware, Oxid, Magento.
3. Eine weiterreichende Individualisierung lässt sich bei geringem Umsatz eigentlich nur über Standardsoftware mit individuell erstellten Plugins realisieren, wenn man den Kostenrahmen nicht sprengen will.
   Basistechnik entsprechend 2.
4. Bei mittlerem Umsatz und Traffic sind für ein einfaches Sortiment und Standardprozesse leistungsfähige Cloudlösungen, wie Demandware gut geeignet.
5. Bei mittlerer Komplexität und mittlerem Umsatz kann Standardsoftware (siehe 2.) mit Plugins und einem Full Page Cache eine solide Lösung sein.
6. Bei mittlerem Umsatz und hoher Individualität ist eine Frameworkgestützte Individualentwicklung sicherlich nicht die schlechteste Wahl. Kandidaten wären hier Commercetools, Ongr. oder sogar Spryker, falls der Kostenrahmen das hergibt. Falls es zum Geschätsmodell passt sollte man auch NewStore auf die Shortlist nehmen.
7. Standardanforderungen bei hohen Umsätzen kann man m.E. mit gut skalierbaren Systemen, wie Intershop oder Hybris in sorgfältig gebauten Systemsetups erfüllen
8. Mittlere Komplexität bei hohen Umsätzen könnte mit leistungsfähiger Standardsoftware und einem individuellem Hochlastfrontend abbildbar sein, oder man greift gleich zu einer kompletten, frameworkgestützten Eigenentwicklung
9. Und schließlich die Königsklasse: Hoher Umsatz, hohe Komplexität. Hier kommt man nicht mehr um eine Eigenentwicklung mit optimiertem Setup herum. Das ist genau das Feld, in sich dem Otto, Metro und Zalando tummeln (um jetzt mal nicht die rosa Elefanten Amazon und Alibaba zu nennen). Für diese Gewichtsklasse sind Microservice Architekturen sinnvoll. Für alle anderen Felder wären technische Komplexität und Kosten aber einfach zu hoch.

Mal kann jetzt natürlich zurecht fragen “was heißt denn klein, mittel und groß; Standard und komplex?” Wo sind die Grenzen zwischen den aufgemalten Feldern? Zugegebenermaßen sind die Grenzen da fließend und man kann trefflich diskutieren. Trotzdem denke ich, dass man hier erst mal eine Idee und erste Struktur bekommt.

Aber um auf die Eingangsfrage von Lars zurückzukommen:

Heutzutage würde ich für das Projekt von 2010 vermutlich den Ansatz einer Standardsoftware mit vorgeschaltetem individuellem Hochlastfrontend wählen. So kann man schnell starten, das Geschäft gut hochskalieren und gleichzeitig individuelle Features umsetzen.