Jonas und Günter bei den E-Commerce-Tagen 2021

Dem Thema “Replatforming” bei den E-Commerce-Tagen-Online 2021 ist Günter Heiß, Geschäftsführer von eCube nachgegangen und warum es (nicht nur) im E-Commerce unmöglich ist, absolut richtige Entscheidungen zu treffen und wie mit der richtigen Technologie-Strategie dennoch nachhaltiger E-Commerce gelingen kann. Durch das Gespräch führte Jonas Vogel, Business Development Manager bei eCube.

Dies ist ein Transkript des Vortrags beginnend mit einer kurzen Info zu eCube…

Günter: eCube gibt es mittlerweile seit unfassbaren 21 Jahren und fast genau so lange beschäftigen wir uns hauptsächlich mit E-Commerce. Dabei kommen wir aus der Software-Entwicklung, also von der technischen Seite und haben schon sehr viele Projekte auf unterschiedlichen Plattformen realisiert. Wir wollen das Thema daher heute etwas mehr von der technischen Richtung betrachten, aber keine Angst, keine “bits & bytes”.

Günter, in 21 Jahren sind wahnsinnig viele Projekte gelaufen. Wenn Du mal zurückblickst, würdest du die alle wieder so umsetzen, wie Du das getan hast?

Günter: Nein, natürlich nicht, man lernt ja schließlich dazu. Auch als Dienstleister macht man manchmal Fehler oder man stellt irgendwann fest, dass man Dinge auch anders hätte machen können. Besonders im E-Commerce ändert sich die ganze Umgebung, die Anforderungen, die Endgeräte ändern sich. Unser erster Kunde damals war Zooplus, da stand der Desktop im Mittelpunkt. Handys waren noch große “Knochen” und heute ist mobile das Hauptthema. Und so ändern sich einfach viele Rahmenbedingungen. Und natürlich ändern sich Technologien. Inzwischen gibt es einfach andere Technologien als vor 20 Jahren oder auch vor 10 Jahren. Damals haben wir im Prinzip alles selber gebaut und fast jede Zeile Code selbst programmiert. Es gab zwar schon E-Commerce-Systeme, aber die waren noch nicht so toll.

Technologien und die Marktbedingungen ändern sich. Ist das der Grund, warum aktuell viel von “Replatforming” gesprochen wird? 

Günter: “Replatforming” ist eine Art Damoklesschwert für viele, die E-Commerce, was ihre Systeme betrifft, teilweise schon in der zweiten oder dritten Iteration betreiben. Warum ist das so? Weil sie einfach merken, dass man irgendwann einfach in der Entwicklungsmöglichkeit blockiert ist und dass es nicht mehr weitergeht. Ein Hauptgrund dafür ist, dass die Systeme mit der Zeit einfach sehr “verbastelt” sind und deswegen eben irgendwo blockieren.

Bei “verbastelt” muss ich an so ein Haus denken. Kann man sich das in etwa so vorstellen?

Wann ist ein Replatforming unumgänglich
Quelle: Photo by Linh Ha on Unsplash

Günter: So ungefähr kann man sich das vorstellen, wobei dieses Haus noch vergleichsweise harmlos ausschaut. Aber das kann durchaus auch schlimmer werden. Klassische E-Commerce-Systeme, die Monolithen, wie man so schön sagt, sind technisch gesehen Frameworks und werden von daher von innen heraus erweitert. Die Konsequenz davon ist eine enge Verzahnung zwischen dem Basissystem und den Erweiterungen oder dem Customizing. Dadurch lassen sich die Systeme mit der Zeit schwieriger pflegen. Die Dinge, von denen man eigentlich denkt, dass sie einfach sein sollten, werden dann plötzlich ganz kompliziert, neue Features zum Beispiel.

Günter: Dieses Bild drückt es ganz schön aus. Der Fachbereich will eigentlich eine Kleinigkeit und die Technik sagt “boah, das wird ein größeres Ding”. Und alle sind am Ende schockiert, wie teuer es tatsächlich wird. Besonders fatal ist auch, dass die Updates der Basisplattform, also vom eigentlichen E-Commerce-System schwieriger werden mit der Zeit, einfach weil diese Abhängigkeit zu den eigenen Erweiterungen besteht. Updates, die wirklich notwendig sind und die man ja nicht immer ignorieren kann, etwa weil sie Security-Probleme beheben, sind irgendwann wirtschaftlich fast nicht mehr vertretbar, weil daraus plötzlich Projekte von zig Manntagen werden. Das ist natürlich fatal, weil ich am Ende keinen Mehrwert geschaffen habe, außer dass ich jetzt eine Version weiter bin.

Das wäre dann der Punkt, an dem das Thema Replatforming im Raum steht?

Solche Probleme werden erst mit der Zeit sichtbar, das muss sich im Prinzip eine ganze Branche klar machen. Wenn ein Replatforming ansteht, was nicht selten einen Totalverlust des Systems bedeutet, fängt man neu an. Man hat natürlich die Learnings, die man mitnimmt, aber fängt wieder an, Code neu zu schreiben. Das ist manchmal gar nicht schlecht, weil man vielleicht alte Zöpfe abschneiden kann. Aber im Sinne von nachhaltigem Investitionsschutz ist es natürlich ganz schön sportlich. Der Grund ist eben, wie gesagt, die enge Verzahnung zwischen den eigenen (customized) Funktionalitäten und der Plattform.

Entweder ich behalte das Alte und es wird immer schmerzhafter, oder ich muss in einen sehr, sehr großen sauren Apfel beißen, weil Neubau natürlich auch nicht gerade günstig ist. Das klingt nach “rote Pille oder blaue Pille?” – kein Weg ist optimal oder?

Mit der blauen Pille bleibst Du in Deiner Welt. Mit der roten Pille entscheidest Du Dich für die Erkenntnis, deshalb sollte man eigentlich immer die rote Pille wählen. Aber was ist eigentlich die Erkenntnis? Ich glaube, die Erkenntnis ist nicht, dass wir heute zwingend viel schlauer sind und immer bessere Entscheidungen treffen. Es wird auch in Zukunft so sein, dass das wir heute Entscheidungen treffen, die wir vielleicht in ein paar Jahren so nicht mehr treffen würden. Deswegen würde ich von der Unmöglichkeit, die richtige Entscheidung zu treffen, sprechen – einfach weil wir in einem extrem dynamischen Umfeld unterwegs sind, wo sich die Rahmenbedingungen ändern.

Was wir tun können – für uns als Software-Entwickler ein wichtiges Learning: Software besser bauen im Hinblick auf die Flexibilität. Wie lassen sich die Systeme so bauen, dass eben nicht mehr dieser Totalverlust droht? Wie kann ich ein System bauen, das nachhaltiger ist, das länger lebt und das sozusagen resilienter ist gegenüber Fehlentscheidungen? Das Ziel muss es sein, nicht an den Punkt zu kommen, wo ich mein System neu bauen muss, sondern immer die Transparenz und die Feingliedrigkeit zu haben, damit das System auch weiterhin wartbar bleibt und ich, wenn ich eine Fehlentscheidung getroffen habe, an einen Punkt im System herankomme, ohne den ganzen Rest anfassen zu müssen.

Wie schafft man es, die Auswirkungen einer Fehlentscheidung lokal einzugrenzen?

Hier kommen wir zum Thema serviceorientierte Architekturen, SOA, Headless Commerce, Composable Commerce. Das sind die Stichworte, die momentan in der Gegend herumschwirren. Man muss schon aufpassen, denn man darf nicht jeder Sau nachlaufen, die durch das Dorf getrieben wird. Aber es ist schon ein wesentlicher Paradigmenwechsel, wie ihn zum Beispiel Anbieter wie commercetools vollziehen, indem sie einfach mal völlig anders denken, wie ein System und eine Architektur funktionieren können.

Und um den Unterschied zu verstehen, muss ich etwas ausholen und technisch werden: wie gesagt, sind die klassischen monolithischen Systeme eigentlich Frameworks, die man sich wie einen Emmentaler Käse vorstellen kann. Der Käse an sich ist quasi das Basissystem, das man sich irgendwann mal zugelegt hat. Und wenn ich das System erweitern will, dann baue ich in die Löcher irgendwelche Ergänzungen, Abänderungen oder sowas rein. Was ist das übertragen auf den E-Commerce?

Zum Beispiel wird in jedem System typischerweise erstmal das Frontend komplett neu gemacht, weil jeder seine ganz spezifischen Vorstellungen für die Storefront hat. Aber auch Funktionalitäten wie etwa im B2B ganz spezifische Preisfindungsalgorithmen, die so von keinem System abgebildet werden. Das ist dann so eine Funktionalität, die custom-made ist und die dann in so einen Schweizer Käse reingepackt wird. Da merkt man schon, wie eng verzahnt der Käse und die Löcher sind.

Aber natürlich auch der Platz in den Löchern ist irgendwo begrenzt und letzten Endes wahrscheinlich auch ziemlich eng. Ich habe letztens ein Bild gesehen von einem Porschebesitzer, der wahrscheinlich etwas transportieren musste und seinen 928 einfach zu einem Pick-up umfunktioniert hatte – das trifft die Sache schon ganz gut. Der wollte irgendwas transportieren, mit einem 928 ist das so ohne Weiteres nicht möglich. Also baut er eine Ladefläche dran und hat auf diese Weise einen Transporter.

Klingt erstmal schlüssig, hat aber ein paar Downsides und Drawbacks. Garantie wird es nicht mehr geben, aber die gibt auf einen 928 ohnehin nicht mehr. Aber ich denke, jeder weiß was gemeint ist. Wenn da mal was kaputt ist bezweifle ich, dass man einfach in ein Porsche-Center fährt und den reparieren lässt. Die schicken einen vermutlich weg, weil das mit dem ursprünglichen Auto nichts mehr zu tun hat. 

Die Analogie zur Software: man hat zwar mehr, man bekommt aber auch keine Updates mehr und kommt nicht mehr weiter. Das Originalsystem ist so stark modifiziert, dass sich am Ende keiner mehr findet, der sagt “ja, das kann man noch reparieren”.

Was tun, wenn ich trotzdem mehr brauche – zum Beipiel mit dem Auto etwas transportieren muss? Eine Anhängerkupplung dranbauen?

Das klingt nach einem vernünftigen Plan. Eine Anhängerkupplung dran, Anhänger dran gehängt – damit habe ich im Prinzip die gleiche fachliche Anforderung erfüllt. Aber auf eine ganz andere Art und Weise. Statt das System intern zu ändern, habe ich von außen ein zweites System angehängt, nämlich den Hänger, der genau diese Anforderungen erfüllt. Das ist eine schöne Analogie zu einer serviceorientierten Architektur, wo man einfach mehrere Services miteinander verbindet. 

Services arbeiten immer mit sogenannten APIs, Application Programming Interfaces, das sind die Schnittstellen, mit denen Services miteinander kommunizieren. In unserem Fall wäre die API einfach die Anhängerkupplung. Damit wird die Kohäsion hergestellt, in diesem Fall zwischen Hänger und Auto und im anderen Fall eben zwischen Basissystem und erweiternden Services. Wenn sich die Anforderung ändert, weil ich beispielsweise zum Campen fahren möchte, kann ich natürlich den Anhänger einfach ändern. Oder ich kann auch eine komplette eigene Konstruktion dranhängen. Das ist das Schöne daran. 

Dadurch, dass jeder Service für sich genommen eigenständig ist und eben diese Schnittstelle, diese Anhängerkupplung hat, kann ich wenn nötig auch ein anderes Auto dranhängen und betreibe so quasi Investitionsschutz, denn oft sind sehr viele Mannmonate in die Entwicklung von eigenen Systemen geflossen, eine Investition, die mit einem solchen SOA-basierten Ansatz besser geschützt ist.

Im Kontext von E-Commerce-Plattformen geht es nicht nur um zwei Systeme, sondern um deutlich mehr. Ist das für Unternehmen nicht sehr kompliziert?

Das ist ein absolut berechtigter Einwand. Grundsätzlich wird durch eine andere Architektur – serviceorientiert statt Framework – die Komplexität des Gesamtsystems nicht geringer. Sie verlagert sich in andere Bereiche, mehr in die Infrastruktur. Hier habe ich natürlich das Problem, dass ich mit mehreren Services jonglieren muss. Das fängt schon damit an, dass ich mehrere Ansprechpartner bei verschiedenen Herstellern habe. Es wird dadurch nicht einfacher, aber es lohnt sich langfristig, so zu bauen, dass du dir alle Möglichkeiten offen hältst, nie in eine Sackgasse baust, sondern dass du flexibel bist und jederzeit einzelne Teile austauschen kannst. Das ist unser Learning aus vielen Projekten.

Ein zweites Learning: Reduziere die Komplexität, indem du dich auf das Wesentliche fokussiert. Es ist nicht immer sinnvoll, den Service oder die Komponente zu wählen, die vermeintlich die beste ist, die in den Feature-Listen am besten abschneidet oder die, die immer beim Technik-Quartett gewinnt. Die beste Lösung ist die, die für mich meine Problemstellung am besten löst, möglichst ohne viel drumherum, denn das erzeugt nur Komplexität und Komplexität muss gemanagt werden. Je schlanker, desto besser. 

Dazu passt dieses Taschenmesser, ich glaube, das gibt es wirklich. Das ist auf den ersten Blick nett und ich überlege mir, irgendwann könnte ich ja mal so einen Nagelzwicker gebrauchen und vielleicht auch einige von den 87 weiteren Funktionen, die da drin sind. Aber im Endeffekt ist es natürlich Quatsch, denn wenn ich auf dem Berg bin und mit meinem Taschenmesser einfach eine Scheibe Wurst schneiden will, dann ist es ja alles nur hinderlich, es steht mir alles im Weg. Es ist zu schwer und zu unhandlich, zudem ist der Preis dafür enorm hoch. 

Auch bei Software-Systemen ist der Preis dafür, dass man Funktionalitäten mitschleppt, die man eigentlich gar nicht braucht, irrsinnig hoch. Man müsste mal eine Studie machen, die den wirtschaftlichen Schaden durch “Featuritis” ermittelt – der ist mit Sicherheit nicht gering.

Weg von Maximalanforderungen hin zu konsequenter Fokussierung auf das Wesentliche – welche Rolle spielt Best of Breed in diesem Zusammenhang?

Dieses Taschenmesser ist wahrscheinlich das beste Taschenmesser, das man kaufen kann. Es ist vielleicht “Best of Breed”, aber es ist nicht “Best Fit” für meinen Bedarf, eine Scheibe Wurst zu schneiden. Es lohnt sich deshalb, mehr darüber nachzudenken, was brauche ich denn wirklich? Die Problem-Domäne verstehen und überlegen, wo ich als erstes hin will. Was sind meine strategischen Ziele? Und dann die Tools genau danach auswählen. Der Fokus auf das, was ich wirklich brauche, bedeutet im Umkehrschluss aber auch, dass ich etwas weglasse, was ich nicht brauche. Hier ist Mut zur Lücke gefragt.

Übrigens, sollte dieser Mut zur Lücke mal zu einer Fehlentscheidung führen, etwa weil die Lücke irgendwann zu groß wird, dann ist es mit einem serviceorintierten Software-Ansatz viel leichter, diese Lücke zu stopfen, etwa eine alte Funktionalität gegen eine bessere neue auszutauschen. Wie bei einer Lampe, wo ich einfach die Glühbirne austausche, ohne die ganze Lampe wegschmeissen zu müssen. 

Ist ein servicebasierter Ansatz für Unternehmen jeder Größe sinnvoll und machbar?

Ich glaube nicht, dass das dies sonderlich von der Größe abhängt. Auch eine kleine Organisation kann sich heutzutage eine Software-as-a-Service-Architektur hinstellen, weil Systeme wie z.B. commercetools schlanker sind und man damit auch klein anfangen kann. Aber auch dies ist keine One-size-fits-all-Lösung für alle. Auch die Entscheidung für eine Basisarchitektur muss man nach dem Best-Fit-Prinzip kritisch prüfen. Passt dieser Ansatz für mich? Da spielen viele Themen eine Rolle, die den Rahmen dieses Gesprächs sprengen würden. 

Wenn Sie Lust haben, drüber zu reden oder noch Fragen haben, wenn Sie einen Sparringspartner brauchen, rufen Sie uns einfach an!

Vielen Dank für das Gespräch Günter!


Weitere Informationen zu diesem Thema findest du auch im letzten Blogbeitrag vom 28.09.2021 oder wenn du tiefer einsteigen möchtest, registriere dich für das kommende Whitepaper “Die beste Lösung für den Digital Commerce finden”.