von Im letzten Jahr durfe ich kurz vor Weihnachten bei der oddity open einen Vortrag halten. Das Oberthema war „Composable Commerce“ und als Vortragende dabei waren Michelle Beeson (Forrester) und Moritz Zimmermann (Hybris-Gründer und Investor unter anderem bei Emporix). Ich hatte mich entschlossen, ein paar Thesen zur Zukunft von E-Commerce-Technologie zu präsentieren, die ich euch hier kurz vorstellen möchte.
#1: Shoptech wird granularer.
Es gab mal Zeiten, da ließ sich ein Shop-System-Programm installieren, und Händler*innen standen alle wichtigen Funktionen zur Verfügung, um einen eigenen Webshop einzurichten und zu betreiben. Produkt- und Bestellungsverwaltung sowie Suche, Warenkorb und Bestellprozess kamen aus einer Hand.
Diese Programme, die man auch als „Suites“ bezeichnet, haben viele Vorteile. Unternehmen bekommen eine Software aus einer Hand, und auch aus Entwickler*innen-Sicht hat ein solcher Monolith durchaus seinen Charme: man muss sich nicht mit API-Calls über ein Netzwerk beschäftigen, sondern nutzt interne APIs, was oft schneller und kontrollierbarer ist. Es gibt allerdings auch Nachteile. Aus Business-Sicht bindet man sich an einen Hersteller und ist, was Sicherheit, Stabilität und Updates angeht, komplett von diesem abhängig. Und aus technischer Sicht sind Monolithen in der Regel schwerer zu skalieren, außerdem gestaltet sich paralleles Arbeiten an verschiedenen Teilen der Applikation als schwierig, vor allem wenn hoher Innovationsdruck herrscht und Änderungen schnell umgesetzt werden sollen.
Besonders wegen der letzteren Tatsache hat sich in den letzten Jahren ein vielfältige Ökosystem an Software-Anbietern etabliert, die E-Commerce-Technologie erweitern oder in Teilen ersetzen. So ist es beispielsweise üblich, eine externe Suche einzubinden, Produkte über ein externes PIM (Product Information Management) zu pflegen und externe Zahlungs- und Logistikanbieter anzubinden. Diese Anbieter stellen ihre Dienste in der Regel als SaaS-Produkte zur Verfügung, die sich über Schnittstellen einfach in die bestehende Geschäftslogik einfügen.
Diesem Gedanken entspringt auch die Idee einer „headless“-Architektur, also der Trennung zwischen Frontend und Backend. Unternehmen können auf Basis stabiler Backends ihre Geschäftsmodelle aufbauen, und sind gleichzeitig sehr flexibel wenn es um den Aufbau der berühmten „Customer Experience“ geht (siehe unten). Und, etwas weiter getrieben, entspringt auch die Logik der sogenannten Microservices der gleichen Idee bzw. dem gleichen Bedürfnis: Funktionalitäten so zu kapseln, das sie sich autonom weiterentwickeln und neu kombinieren lassen.
Nun ist die Kapselung von Funktionalität so alt wie die Software-Entwicklung selbst. Schon immer haben Entwickler*innen sich bemüht, Teile ihres Codes wiederverwendbar zu machen und ihn in Form etwa von Klassen und Libraries in neuen Projekten anzuwenden. Entwickler*innen, die heutzutage etwa mit Node arbeiten, werden über npm neue Pakete in ihr Projekt einfügen und das Rad nicht neu erfinden.
Neuer ist allerdings, dass diese zunehmende Granularität in zunehmendem Maße kommerzialisiert wird. Rund um einzelne Funktionsbereiche entstehen komplett neue Unternehmen, die ein Rädchen im System der Händler*innen werden möchten. Neben den oben genannten Spezialservices für Suche & Co. gibt es viele gute Beispiele in den App-Stores von Shopsystem-Anbietern. Über den App-Mechanismus bringen Entwickler weltweit die speziellsten und granularsten Funktionen in die Shops, die ihnen möglicherweise den entscheidenen Vorteil im Wettbewerb um die Aufmerksamkeit der Kund*innen bringt.
Aber: wo ein Trend ist, ist auch ein Gegentrend. Michelle hat in ihrer Präsentation den Begriff der „composable suite“ geprägt: Unternehmen haben demnach das Bedürfnis, unterschiedliche granulare Komponenten zu einem Gesamtkonstrukt zusammenzufügen, nutzen aber trotzdem konzeptionell das Bild einer „einheitlichen“ Gesamtkonstruktion, in der alle diese unterschiedlichen Dienste gebündelt werden.
#2: APIs, Webhooks und die Bedeutung von Interoperabilität nehmen zu.
Einhergehend mit oben Genanntem kommt in Zukunft keine ernsthafte Technologie ohne die Möglichkeit aus, Daten und Logik mit anderen Anwendungen zu teilen. Über APIs und Webhooks kommuniziert Software untereinander und macht Konzepte wie Microservices oder die Anbindung externer Anbindungen an SaaS-Produkte erst möglich.
Aber API ist nicht gleich API, wie viele leidgeprüfte Software-Implementierer wissen werden. Um richtig damit arbeiten und performante Lösungen bauen zu können, sollten APIs wohldokumentiert und skalierbar sein. Kein Anhängsel, das man an die arg angestaubte eigenen Software anflanscht, sondern ein integraler Bestandteil. Von Technologie-Seite werden Unternehmen daher verstärkt auf GraphQL setzen, das durch seinen maßgeschneiderten Datenaustausch für hochdynamische Anwendungen prädestiniert ist.
In der Praxis bedeutet das: Einkäufer von Software werden sich bei ihrer due diligence verstärkt darauf konzentrieren, wie leistungsfähig diese Schnittstellen sind. Anbieter reagieren darauf mit öffentlich zugänglicher Dokumentation und unkomplizierten Testmöglichkeiten.
#3: Cloud ist das neue normal.
Diese These hat aus meiner Sicht das größte No-Brainer-Potential. Die Vorteile von Cloud-Delivery sind hinlänglich bekannt, von Skalierbarkeit bis Kosteneffizienz ist alles dabei. Natürlich wird es immer Szenarien geben, in denen On-Premise-Lösungen das Mittel der Wahl sind – die Welt ist nicht schwarz und weiß. Aber wer im Shoptech-2022 signifikante Kundenzahlen oder Investments erreichen möchte, wird das nicht über eine Download-Software tun.
Es gibt aber aus meiner Sicht noch einen Punkt, der oft übersehen wird, nämlich die Funktion von Cloud-Infrastruktur während der Software-Entwicklung und -Implementierung. Als ich mich vor gut 20 Jahren zum ersten Mal in die E-Commerce-Manege begeben habe, war es vollkommen normal, eine lokale Entwicklungsumgebung auf dem eigenen Rechner zu haben, dort zu programmieren und zu testen und den fertigen Code dann auf den Live-Server zu deployen. Eine Internetverbindung war eigentlich nur erforderlich, um Dokus zu lesen oder Code von Stack Overflow zu copypasten. Eine der wichtigsten Eigenschaften von git als Versionierungstool gegenüber Subversion war demnach auch, dass man auch ohne Netzverbindung in sein lokales Repo comitten konnte.
Aber die Grenzen zwischen offline und online verschwimmen schon seit einigen Jahren. Durch Services wie etwa Dropbox bekommt jede eine eigene, in Echtzeit synchronisierte Festplatte im Netz – und wer kann schon mit Gewissheit sagen, welche eigenen Daten auf seinem Mobiltelefon oder schon in der Cloud des Handy-Anbieters liegen? Was im Consumer-Bereich schon lange zur Normalität gehört, geschieht auch in der Code-Welt. Cloud-Anwendungen sind teilweise so komplex, dass sie auf einer lokalen Entwicklungsmaschine nicht mehr sinnvoll repliziert werden können, und spätestens hier hat sich das Konzept der „cloud-native“-Entwicklung etabliert. Der gesamte Lebenszyklus einer Anwendung, von der Progammierung über Testing und Deployment findet verstärkt in und mit SaaS- und PaaS-Diensten statt. Das Sahnehäubchen in dieser Hinsicht: das Hosten von Funktionen und einzelner Code-Bestandteile (Stichwort function-as-a-service).
#4. Projekt-Planung bedingt Software-Einsatz – und umgekehrt.
Meine Lieblingsthese. Software alleine löst keine Geschäftsprobleme, es ist das Modell dahinter, es sind die Prozesse, die durch Software verbessert und beschleunigt werden sollen und können (und ich bringe hier nicht das Zitat von den suboptimalen analogen Prozessen, die in ihrer digitalen Form ebenso, nun ja, suboptimal sind). Wie oft sehen wir noch, wie sich Händler*innen und Agenturen an meterlangen Excel-Sheets abarbeiten, um auch ja alle derzeit und in Zukunft absolut sicherlich benötigen Funktionalitäten zu erfassen und Teil eines festgezurrten, Jahre dauernden Projektplans werden zu lassen (ihr versteht wahrscheinlich, warum das hier meine Lieblingsthese ist).
Um es klar zu sagen: nur weil man eine Headless-Lösung mit eigener Microservices-Infrastruktur und eingebautem Flux-Compensator einkauft und verwenden möchte, bedeutet das noch gar nichts für den wirtschaftlichen Erfolg der Nutzung dieses so innovativ klingenden Konzepts. Viel wichtiger ist die Projektplanung dahinter und letztlich das wirtschaftliche Ziel, dass man mit diesen Infrastrukturentscheidungen verfolgt. Also etwa, geht man kleinschrittig genug vor, um so früh wie möglich testen zu können, ob das, was die eigenen Teams entwickeln, tatsächlich Früchte trägt? Wie schnell lassen sich den Kund*innen neue Dinge präsentieren – und ist Innovation diesen überhaupt wichtig? Es geht also um eine bestimme Haltung, ein Wissen darum, nicht alles im Block und am grünen Tisch entscheiden zu können, sondern agil und im Dauerlernmodus Software einzusetzen und weiterzuentwickeln.
#5. Das Geld wird mit der Customer Experience verdient.
Daran schließt sich auch die letzte These an. E-Commerce-Technologie ist kein Selbstzweck, sondern dient immer dazu, das Finden, das Inspiriertwerden, das Kaufen von Produkten und Dienstleistunger für Kund*innen so einfach, schnell und sicher wie möglich zu machen. Es ist also zweitrangig, welche Suchtechnologie beispielsweise verwendet wird oder ob die Anwendungen im Hintergrund mit Scala oder Ruby geschrieben worden. Entscheidend ist, dass für die Nutzer tatsächlich ein Nutzen entsteht.
Wir sprechen oft von der „commoditisation“ von Technologie. Manche Dinge sind so klar, standardisiert, einfach anzuwenden und preiswert, das man sie nicht ad infinitum neu bauen muss. Entscheidend für den Erfolg für Shoptech und deren Anwender*innen wird auch in Zukunft sein, Energie in den Teil der Software zu stecken, der für Kund*innen wirklich einen Unterschied macht, und zwar im wahrsten Sinne des Wortes: nur durch eine stetig verbessere Customer Experience werden sich Marken und Händler*innen nachhaltig von ihren Mitbewerber*innen unterscheiden.
