Unser Kollege Alexander Knöller hat in den letzten 4 Jahren verschiedene E-Commerce Anbieter beraten und mit ihnen Vertikalisierungsprojekte durchgeführt. Wir sprachen mit ihm.
Jens: Hallo Alex, an was für Projekten hast du in den letzten Jahren gearbeitet?
Alexander: Es waren zwei Vertikalisierungsprojekte. Die Projekte hatten bei allen Unterschieden im Detail viele Züge gemein.
Kannst du das genauer erklären?
Es waren Shopplattformen, Eigenentwicklungen. Ihr Ziel war vor allem, auf Skalierung, Time to Market und Businessorientierung einzuzahlen.
Das sind große Worte. Warum hat man nicht mit den bestehenden Plattformen weitergearbeitet?
Die Plattformen waren monolithisch. Sie waren an ihre Grenzen gestoßen. Es bereitet große Schwierigkeiten, mit mehreren Teams an ihnen zu arbeiten und schnell neue Features an den Markt zu bringen. Arbeitet man mit mehr als einem Team an einem Monolithen, ist es schwer, Abhängigkeiten zu managen. Das kostet Zeit, und die Struktur, die dabei entsteht, ist nicht unbedingt die Optimale für das Business.
Diese Entwicklung beobachten wir bei vielen Kunden, aber den Schritt, die Plattform umzubauen, machen wenige.
Ja, es erfordert Mut, so einen Schritt zu gehen. Man hatte sich bewusst gegen Durchschnittslösungen entschieden und organisatorisch wie technisch auf moderne E-Commerce-Konzepte gesetzt.
Du sprachst von Skalierung, Time to Market und Businessorientierung. Vielleicht gehen wir die Begriffe einzeln durch und du erklärst mir, wie neue Plattformen sie adressieren. Fangen wir mit Skalierung an.
Gern. Skalierung heißt zweierlei. Erstens, mit mehreren Teams an einer Plattform arbeiten, und zweitens, mehr Transaktionen und mehr Requests performanter verarbeiten. Um das zu erreichen, werden alle Funktionalitäten, die man für den E-Commerce braucht, auf 5 Systeme aufgeteilt. Diese Systeme haben zur Laufzeit praktisch keine Abhängigkeiten und reichen von der Datenhaltung bis zum User Interface. Sie sind also selbst kleine, vollständige Systeme. Dadurch, dass jedes System von einem eigenen Team entwickelt wird und diese Systeme unabhängig voneinander sind, erreicht man eine organisatorische Skalierung. Man konnte in den Projekten mit 5 Teams arbeiten und musste, vor allem nach der Startphase, als der Prozess sich eingespielt hatte, kaum noch Abhängigkeiten zwischen den Teams managen.
Die Performance wurde dadurch erreicht, dass die Systeme keine Laufzeitabhängigkeiten - oder synchrone Kopplungen, wie wir das technisch nennen - haben. Jedes System ist auf seine Use Cases optimiert und kann diesen Vorteil optimal ausspielen, weil es nicht auf die anderen warten muss. Die Fokussierung der Systeme sorgt dafür, dass ihre Performance über das Maß eines Ich-befriedige-alle-Use-Cases-Monolithen hinaus optimiert werden konnte.
Verstehe - und wie steht es mit Time to Market?
Die eine Hälfte der Erklärung steckt schon in der vorherigen Antwort. Durch die Unabhängigkeit der Teams findet die Entwicklung eines Features nur noch in genau einem Team statt. Das zahlt auf die Entwicklungsgeschwindigkeit ein. Die andere Hälfte der Wahrheit heißt Continuous Deployment. Jedes Team hat eine Pipeline, die, sobald ein Entwickler oder eine Entwicklerin ein Stück Source Code commitet, losläuft. Der Code wird zunächst getestet - eine umfangreiche Testsuite rettet einem hier das Leben - und dann wird er automatisiert deployt. Es war für die Entwicklungskultur ein großer Schritt, von 'einmal die Woche' zu 'permanent deployen' überzugehen, aber das verbessert die Time to Market enorm.
Jetzt bist du uns noch die Erklärung von Businessorientierung schuldig.
Ja, das klingt zunächst wie ein Schlagwort und man fragt sich, wie man Businessorientierung in den Aufbau einer Plattform hineindesignen kann. Der Grundgedanke ist folgender: Die Plattform ist ja in Vertikalen aufgeteilt, aber nach welchem Muster sind die Vertikalen geschnitten? Sie sind aus der Kundenperspektive geschnitten. Die Frage lautete, welche Phasen gibt es in der Customer Journey eines Kunden? An diesen Phasen wurden dann die Systeme ausgerichtet. Man könnte also von kundenzentrierten Vertikalen sprechen. Bei jedem Feature wurde danach gefragt, in welcher Phase der Customer Journey es verortet ist. Der Vertikale dieser Phase wurde das Feature zugeschlagen. Wenn ein Feature nicht genau einer Vertikale zugeordnet werden konnte, lag es oft daran, dass bei der Betrachtung die Brille der Kundensicht fehlte.
Der Ansatz kommt mir bekannt vor. War das nicht auch das Schnittmuster beim Lhotse-Projekt für die aktuelle Shopplattform von Otto?
Ja, das war eine der Inspirationen für den Ansatz. Man darf aber nicht vergessen, dass es sich bei Otto um einen klassischen Distanzhändler handelt. Viele unserer Kunden stehen vor der Herausforderung, eine Plattform für digitale Services zu entwickeln, die sowohl im Distanz- als auch im Stationärgeschäft funktioniert.
'Digitale Services im Distanz- und Stationärgeschäft' - das klingt wie das Versprechen für einen interessanten Blogartikel.
Vielleicht. Was ich sagen wollte: Unsere Kunden haben sich mit einer vertikalisierten Plattform gute Voraussetzungen geschaffen, um digitale Services zu entwickeln: 5 autonome Teams, die business-fokussiert arbeiten. Aber die Vertikalisierung ist erst der Anfang der Reise.
Kommen wir noch einmal auf die Vertikalen zurück. Zwei Fragen stellen sich mir immer, wenn ich von Vertikalen höre. Ist es für den Kunden nicht komisch, bei der Customer Journey von Vertikale zu Vertikale gereicht zu werden? Ich würde mir eigentlich eine einheitliche User Experience wünschen.
Ja, das stimmt. Um das zu gewährleisten, gibt es tatsächlich so etwas wie eine Horizontale, aber nur eine virtuelle. Es gibt eine Pattern Library oder, in einem der Projekte, einen lebenden Style-Guide. Dort sind die Grundkomponenten unseres User Interfaces mit ihrem Verhalten verankert. Diese Library wird von allen Teams benutzt. Sie ist zunächst von einem zentralen Team entwickelt worden. Dadurch hat jedes Team die Bausteine zur Verfügung bekommen, die zu einer einheitlichen Erfahrung der Customer Journey führen. Die Library wird mittlerweile von den einzelnen Teams weiterentwickelt.
Meine zweite Frage bezieht sich auf die Daten. Wenn die Vertikalen an der Customer Journey ausgerichtet sind, gibt es doch viele Daten mehrfach, oder?
Ja und nein. Jede Vertikale braucht bspw. einen Begriff von einem Produkt, sicher, und insofern gibt es 5 Interpretationen des Produktbegriffs. Man könnte meinen, das ist das gleiche Datum 5 mal. In der Praxis zeigt sich aber, dass jede Vertikale ihre eigene Interpretation des Produktbegriffs besitzt. Die Datenmodelle sind wesentlich spitzer und funktionaler. Das Produkt hat im Suchen-Kontext die Struktur eines Suchdokuments, im Bewerten-Bereich die Form einer Pyramide von Farben und Größen und im Warenkorb nur eine flache Ausprägung, die aber einen physischen Ort besitzt. Ich will sagen, dass die Datenmodelle der Vertikalen einfacher geworden sind als die des Monolithen vorher, der ein Produktmodell brauchte, welches für Suche, Detail- und Listenseite, Warenkorb und diverse andere Kontexte funktionierte - eine eierlegende Wollmilchsau.
Kann man denn alles 'vertikalisieren' oder gibt es technische Koordinationsthemen, die immer bleiben?
Ein paar bleiben, zumindest bislang. Die Endkunden sollen bspw. nicht negativ erleben, dass das UI von verschiedenen Services stammt und zusammengesetzt ist. Dazu ist es notwendig, UI-Elemente über die Teams zu standardisieren. Und bei shared Services wie bspw. kubernetes - einer möglichen Laufzeitumgebung für Systeme - oder dem Frontend-Proxy ist Abstimmung notwendig, wenn man etwas Grundsätzliches verändern möchte.
Eine letzte Frage. Warum haben die Kunden auf eine Eigenentwicklung gesetzt?
Ich hab' dir die Anforderungen und die Art, wie sie adressiert wurden, ja eben beschrieben. Wenn man die Shopsysteme am Markt betrachtet, stellt man fest, dass es im Kern zwei Typen von Systemen gibt. Es gibt die Monolithen, die sich in Größe und Umfang unterscheiden und von leichtgewichtigen PHP-Lösungen bis zu ausgewachsenen Java-Boliden reichen, und es gibt die Lösungen, die einen stärkeren Servicebegriff implementieren, eine Richtung, in die ja auch einige Hersteller wie z.B. Hybris gehen wollen. Die monolithische Lösung kam nicht in Frage, weil mit ihr und den Problemen, die sie mit sich bringt, bereits Erfahrungen gesammelt worden waren. Serviceorientiertere Lösungen, die am Markt sind, folgen leider nicht dem Muster, ihre Services an der Customer Journey zu orientieren. Insofern liegt der Entschluss nahe, eine Eigenentwicklung auf Basis der mittlerweile sehr guten Open-Source-Bibliotheken zu starten.
Ich würde gerne noch über die Erfahrungen sprechen, die ihr bei der Implementierung gesammelt habt, aber das heben wir uns vielleicht für ein zweites Gespräch auf. Also: erst einmal vielen Dank für das Gespräch und nur noch eine kurze Frage: Was steht als nächstes auf dem Plan?
Ich würde gerne ein Projekt machen, in dem die kundenzentrierte Vertikalisierung nicht nur die Plattform für digitale Services umgestaltet, sondern das gesamte Unternehmen ergreift. Mal sehen, was kommt ...
