Eindrücke von der code.talks Commerce 2019

Die code.talks Commerce gehört fraglos zu den größten deutschen Entwicklerkonferenzen für den Onlinehandel. Bereits im vergangenen Jahr hatte ich die Möglichkeit, die Veranstaltung zu besuchen, und habe dabei beste Erfahrungen mit dem Format gemacht. Daher war ich auch in diesem Jahr wieder in Berlin, um mich – zugegebenermaßen mit Nicht-Techie-Brille – in den bequemen Kinosesseln der KulturBrauerei über die aktuellen Entwicklungen im Techumfeld des Onlinehandels zu informieren. Für alle Daheimgebliebenen und all jene, die in Berlin nicht jeden Talk mitbekommen konnten, möchte ich meine Notizen in diesem Beitrag zusammenfassen.

Noch ein Hinweis für alle Interessierten: Schon 2018 habe ich meine Eindrücke von der code.talks Commerce auf LinkedIn geteilt.

Zwischen Alexa und Microservices (Teil 1: Architektur)

Zwischen Alexa und Microservices (Teil 2: IT-Organisation / Digitalisierung)

Zwischen Alexa und Microservices (Teil 3: Voice & Bots)

Shopbetreiber-Panel: Nette Idee, aber wie macht man das in der Praxis?

Nach dem offiziellen Opening durch die Veranstalter begann die code.talks Commerce für mich mit einem äußerst spannenden Panel. Roman Zenner, Industry Analyst bei commercetools, und Martin Möllmann, Team Lead E-Commerce bei Flaconi, die auch durch den äußerst lesenswerten ShopTechBlog bekannt sind, luden mit Steffen Heilmann, CTO bei Aroundhome, Ingo Mommertz, CTO bei Douglas, und David Beuchert, Lead Developer bei Thomann, drei IT-Verantwortliche zum Gespräch, um mit ihnen die Herausforderungen im Spannungsfeld zwischen IT und Business auszuloten.

  • Technisch darauf vorbereitet zu sein, Ideen aus dem Business schnell und effektiv umsetzen zu können, ist eine der großen Herausforderungen der IT.
  • Steffen Heilmann schilderte hierzu einen Fall, in dem ein Business Need innerhalb einer Woche umgesetzt werden musste. Seine Learnings daraus:
    • Wieso erfährt die IT häufig erst so spät von solchen Anforderungen? Die Kommunikation innerhalb der Organisation muss demnach verbessert werden.
    • Zudem sollte man seine Architektur so aufbauen, dass man sie auch bei solch kurzfristigen To-Dos nicht vergewaltigen muss.
  • Bei Douglas werden Businessanforderungen häufig erst als kleine Spin-offs entwickelt und erst später an den Core angefügt, damit sich der Core nicht zum Servicemonolithen entwickelt.
  • Auf die Frage, wie sich in seinem Unternehmen die Dualität zwischen agiler Arbeitsweise im IT-Bereich und Deadline-Anforderungen aus dem Business darstellt, antwortete Ingo Mommertz, dass bei Douglas nach dem Scaled-Agile-Prinzip geachtet wird. Es gebe Dreimonatspläne. Um in diese aufgenommen zu werden, müssten sich neue Ideen battlen.
  • Steffen Heilmann stellte heraus, dass es vor allem wichtig ist, gegenüber dem Business Transparenz herzustellen. Neues könne nicht „on top“ gemacht werden. Stattdessen müssten sich Dinge verschieben.
  • Im Hinblick auf das Thema Customizing erklärte Heilmann, sich immer die Frage zu stellen: „Was macht uns einzigartig?“ Diese Dinge sollte man selbst bauen. Ansonsten könne man schauen, was man von Drittanbietern einkaufen kann.
  • Auch Douglas hat sich gegen eine komplette Eigenentwicklung entschieden. Ziel sei es, das Beste zusammenzusuchen und optimal miteinander zu verbinden.
  • Dagegen berichtete David Beuchert, dass bei Thomann verhältnismäßig viel selbst gebaut wird. Auf diese Weise behalte man die Kontrolle und könne gegenüber Kunden bei Problemen transparent sein.
  • Diese Sichtweise unterstrich auch Martin Möllmann. Bei SaaS-Lösungen habe man oft keine Ahnung, was darin passiert.

Prepare for warp speed – How to establish a scalable IT organization

In seinem direkt anschließenden Vortrag widmete sich Steffen Heilmann dem Aufbau der IT-Organisation in seinem Unternehmen Aroundhome, einer Vermittlungsplattform für Produkte und Dienstleistungen rund ums Haus.

  • Ziel bei Aroundhome: IT-Organisation soll skalierbar werden. Dieses Vorhaben gleicht dem Umbau eines Hauses, während es bewohnt ist. Schließlich warten Businessprojekte nicht.
  • Für ein solches Vorhabens gibt es keine „Silver Bullet“. Stattdessen müssen zahlreiche kleine Dinge ineinandergreifen. Es muss somit gleichzeitig an vielen verschiedenen Bereichen gearbeitet werden (von der Firmenvision über Technologie und Prozesse bis hin zum Personal).
  • Auch während des Umbaus läuft das Geschäft weiter. Daher kann es helfen, dedizierte Ressourcen trotz des Gesamt-IT-Plans bewusst unverplant zu lassen.
  • Für die Zielorganisation stellt sich Aroundhome für jedes Team drei Managementrollen vor: Product Owner, Tech Lead & People Lead). Diese Rollen sollte man nicht in einer Person bündeln. Dann besteht die Gefahr, dass gerade die Aufgaben des People Leads nicht ausreichend abgearbeitet werden können.
  • Sobald diese Voraussetzungen geschaffen sind, kann auch das Recruiting beginnen. Dieses sollte jedoch nicht als abzuarbeitendes Projekt, sondern als Dauerprozess im Unternehmen etabliert werden.
  • Um skalieren zu können, sind insbesondere leichtgewichtige Prozesse notwendig. Darüber hinaus kommt auch der Kommunikation entscheidende Bedeutung zu. Hierzu gibt es verschiedene Formate, um auf möglichst allen Ebenen zu kommunizieren, bspw. CTO Updates, Tech Talks, Tech-Lead-, People-Lead und PO-Runden oder auch das kurze Gespräch beim Mittagessen oder am Kaffeeautomaten.

Back for the future: Wie transformiert sich ein traditioneller Händler?

Über einen spannenden Transformationsprozess sprach auch Frank Leue, CTO von Lobenbergs Gute Weine, in seinem Vortrag.

  • Bei Lobenbergs Gute Weine hat sich über 20 Jahre ein Monolith mit gewachsener Komplexität entwickelt, der von gerade einmal zwei Entwicklern gemanagt wurde.
  • Doch auch im Weinhandel ist unklar, wie der Kunde seinen Wein in Zukunft kaufen wird. Flexibilität ist daher äußerst wichtig. Aus diesem Grund wurde das Ziel ausgegeben, das IT-System modularer zu gestalten.
  • Zu diesem Zweck hat man sich für einen Umbau in ein auf Microservices basierendes System entschieden.
  • Leues wichtigste Learnings aus diesem Projekt:
    • Die Services sollten aus Businesssicht entwickelt werden und nicht auf Basis des alten Datenmodells.
    • Es ist empfehlenswert mit kleinen Usecases zu starten, um aus ihnen zu lernen.
    • Auch die Komplexität sollte anfangs reduziert sein.
    • Es macht zudem Sinn, einen Microservice-Blueprint zu entwickeln, um Integration und Tests auf diese Weise zu vereinheitlichen.
    • Es sollte von Anfang an eine CI/CD-Pipeline etabliert werden, um schnell entwickeln zu können.

On-premise, Cloud, Headless – A comparison of different e-commerce systems

Am Nachmittag des ersten Tags gab Ulrike Müller einen äußerst lehrreichen Überblick über die Entwicklung verschiedener E-Commerce-Systeme.

  • Ulrike Müller sieht drei Wellen in der Entwicklung von E-Commerce-Plattformen.
  1. 90er/Anfang der 00er dominierte lizensierte E-Commerce-Software, die vom Händler selbst oder einem beauftragten Dienstleister betrieben und an die eigenen Bedürfnisse angepasst wird.
  2. Im Laufe der 00er Jahre entstanden vermehrt SaaS-Provider, die Händlern eine vollwertige E-Commerce-Lösung in der Cloud zur Verfügung stellen.
  3. In den letzten Jahren entstanden schließlich noch Anbieter von Headless Software. Der Händler bzw. sein Dienstleister können ihre Frontends selbst entwickeln und diese über APIs an die Headless-Lösung der Anbieter anschließen.
  • Die Entwicklung dieser Geschäftsmodelle war stark an die Technologieentwicklung und die sich daraus ableitenden E-Commerce-Anforderungen gekoppelt. Während es in den 90ern und den 00ern vor allem darum ging, überhaupt ins Netz zu kommen, steht für viele Händler nun im Fokus, die Vielzahl an verschiedenen Customer Interaction Points zu managen.
  • Für wen eignen sich die unterschiedlichen E-Commerce-Systeme vorrangig?
    • Lizensierte Software eignet sich vor allem dann, wenn man speziellen Customization-Bedarf hat und/oder mehrere Tools von Drittanbietern einbinden möchte.
    • SaaS-Lösungen entbinden den Händler hingegen weitestgehend vom technischen Betrieb, sodass er sich auf seine Kernkompetenzen konzentrieren kann. Dafür fällt die Differenzierung schwerer, da SaaS-Anbieter ihr Featureset selbstverständlich mehreren Händlern zur Verfügung stellen.
    • Auch Headless-Systeme helfen dabei, technische Aufwände zu reduzieren. Diese werden auf die Arbeit an Kundentouchpoints fokussiert. Diese Lösungen eignen sich also insbesondere für Unternehmen, die Wert auf vielfältige Kundeninteraktionen legen.
  • Müller geht davon aus, dass sich Innovationen in Zukunft vor allem im Rahmen des Frontends abspielen werden. Backendsysteme dürften hingegen verstärkt zur Commodity werden.

FOND OF partners: How we built a delightful offline-first order platform for our B2B partners

Über die besonderen Herausforderungen eines B2B-E-Commerce-Projekts sprachen am zweiten Tag Till Hess und Philipp Brumm, Head of Digital Product und Software Developer bei der Taschenmarke FOND OF.

  • FOND OF beschäftigt im B2B-Geschäft über 100 Vertreter, die etwa 20.000 Stunden pro Jahr mit der Eingabe von Bestellungen beschäftigt sind. Hier existiert also erhebliches Potenzial, um die Effizienz zu erhöhen.
  • Es wurden drei Customer Journeys erprobt:
  1. Vertreter bestellt über den B2B-Onlineshop (Problem: Was passiert, wenn er keinen Zugriff auf das Internet hat?)
  2. Vertreter befüllen manuell Excel-Sheets (Problem: sehr zeitintensiv)
  3. Vertreter befüllt spezielles Excel-Order-Sheet mit automatischem Upload, sodass der Checkout im B2B-Shop stattfinden kann (Problem: Upload funktioniert bei Eingabefehlern nicht)
  • Daher wurde als Ziel ausgegeben, eine schnelle und personalisierbare App zu bauen, die auch offline nutzbar ist.
  • Dies hatte verschiedene Herausforderungen zur Folge:
    • Lange Produktlisten erhöhen Ladezeit – Lösung: Mit Virtual Rendering wird nur das gerendert, was der Nutzer aktuell sieht.
    • Spreadsheet-Experience – Lösung: Musste von FOND OF selbst gebaut werden. Die existierenden Lösungen waren zu schwergewichtig.
    • Offline-Fähigkeit – Lösung: Über Service Worker wird die gesamte Seite und all ihre Ressourcen gecacht, sodass sie auch offline verfügbar ist. Der Checkout muss aber selbstverständlich online ablaufen.

Die Auswahl des Shopsystems ist irrelevant. Erfolg von E-Commerce hängt einzig und allein von Know-how, Team, Engineers und guter Strategie ab!

Zu einem Panel unter provokativem Titel hatte Lars Jankowfsky, General Partner bei NFQ.Asia, die Vertreter verschiedener Shopsystemanbieter geladen. Boris Lokschin, CEO von Spryker, Pierluigi Meloni, Product Manager bei Oxid, Nils Breitmann, Principal Enterprise Architect bei Intershop, und Christian Zacharias, Senior Lead bei Oberlo-Shopify, diskutierten die Ausgangsthese teils äußerst kontrovers.

  • Aus Sicht Lokschins ist Erfolg im E-Commerce vom Dreiklang „Team – Methode – Tool“ abhängig. Wenn eines davon fehlt, habe man ein Problem.
  • Zacharias war hingegen der Meinung, dass sich 80 Prozent der Herausforderungen bereits mit einem Standardsystem lösen lassen. Erst in den letzten 20 Prozent müsse viel customized werden. Händler sollten daher überlegen, wie viel Customization sie brauchen und anhand dessen das für sie passende Werkzeug auswählen.
  • Breitmann gab zu bedenken, dass die Technologieauswahl sehr komplex ist. Schließlich gebe das ausgewählte Shopsystem häufig die Architektur der Lösung vor.
  • Nach Meinung Melonis sind daher die Unternehmensroadmap und die architektonische Philosophie entscheidend für die Systemauswahl.
  • Lars Jankowfsky stellte anschließend die These in den Raum, dass Kunden häufig nicht die Kompetenz besitzen, um die für sie richtige Entscheidung zu treffen. So entstünden blöde Projekte.
  • Meloni bemerkt ebenfalls häufig, dass Entscheider wenig Ahnung haben. In Pitches gehe es daher oftmals vor allem darum, eine zum Gegenüber passende Geschichte zu erzählen.
  • Lokschin knüpfte daraufhin an Ulrike Müllers Vortrag an und erklärte, das jede Shoplösung ihren Markt habe, da diese auch ein Abbild der Historie sein. Sein Unternehmen Spryker habe den Anspruch, Probleme zu lösen, die es vor einigen Jahren noch nicht gab.
  • Jankowfsky machte anschließend darauf aufmerksam, dass gute Software nicht reichen würde. Man brauche das kompetente Team, über das Händler oftmals nicht verfügen. Müssen sie sich also zwangsläufig in Abhängigkeit von einer Agentur begeben?
  • Zacharias war der Meinung, dass das Ziel sein müsse, dass die In-house-Entwickler ihre Lösung selbst betreuen können.
  • Aus Sicht Breitmanns sollten Unternehmen darauf achten, ihre Entwickler an den Differenzierungsmerkmalen der Organisation arbeiten zu lassen und nicht an den Standardfunktionalitäten.
  • Nach Meinung Melonis können aufgrund des Personalmangels in der IT und der häufig fehlenden Digital-DNA auch nicht alle Unternehmen Tech-Companies werden. Eine Gefahr der Abhängigkeit sei also immer da.
  • Aus Sicht eines Zuschauers zeigt der Trend – zumindest bei großen Händlern – auch zunehmend in Richtung Individualentwicklung. Hiervon rät Jankowfsky allerdings ab. Die hierfür nötige Anzahl an Entwicklern und eine entsprechende Tech-DNA könnte in Deutschland nur eine Handvoll Händler (bspw. Amazon, Zalando) aufbringen.

What do you get when PowerPoint and Excel are having a baby?

Nach dem Panel stellte Nils Breitmann in seinem Vortrag zudem seine Gedanken zum Thema Low Code vor.

  • Zunächst stellte Breitmann die Frage in den Raum, wie Softwareentwicklung in 20 Jahren aussehen wird. Coding oder Low Code?
  • Das Problem an Softwareentwicklern: Sie sind zu langsam, zu teuer und schwer zu finden.
  • Welche Alternativen gibt es?
    • Man kann das Coding optimieren. Dies geschieht z.B. durch Agile, DevOps, Microservices, Frameworks und PaaS.
    • Man kann das Coding minimieren. Hierfür kann man entweder reine Standardsoftware nutzen, sodass gar nicht mehr gecodet werden muss, oder den Fachabteilungen durch Low Code dabei helfen, selbstständig Applikationen zu kreieren.
  • Im Bereich Low Code gibt es verschiedene Anbieter, die es Experten aus den Fachbereichen ermöglichen, durch visualisierende Tools, die teilweise stark an Excel und PowerPoint erinnern, eigene Anwendungen zusammenzuklicken.
  • Low Code kann die Geschwindigkeit und Flexibilität der Softwareentwicklung deutlich erhöhen, birgt aber auch Risiken.
    • Es könnte sich eine Schatten-IT entwickeln.
    • Low-Code-Anwendungen können sich im Laufe der Zeit auch selbst zu komplexem Spaghetticode entwickeln.
  • Aus Sicht Breitmanns werden daher beide in der Eingangsfrage zur Wahl gestellten Optionen weiterleben. Durch den Low-Code-Ansatz werden Fachabteilungen Anwendungen mit überschaubarer Komplexität zunehmend selbstständig entwickeln können, sodass sich die IT um komplexe Herausforderungen fokussieren kann.
  • Seine Ratschläge sind daher:
    • Ans Business: Setzt Softwareentwickler weise ein!
    • An die IT: Unterstützt eure Businesskollegen dabei, selbst kreativ zu sein.

When scalability becomes more than a buzzword, or how to saddle a unicorn

Der Modehändler ABOUT YOU hat sich in nur fünf Jahren vom Start-up zum Unicorn entwickelt. Welche Herausforderungen dies an die IT stellt und wie sich diese bewältigen lassen, schilderte Tech Evangelist Marten Westphal in seinem Talk.

  • Um eine Organisation derart hoch zu skalieren, müssen verschiedene Dinge zusammenkommen:
  1. Der Start-up-Spirit muss trotz des Wachstums erhalten bleiben.
  2. Die Architektur und die Infrastruktur müssen stimmen.
  3. Es muss ein passendes Organisationsmodell gefunden werden.
  • Um den Start-up-Spirit zu erhalten, arbeitet ABOUT YOU selbstverständlich agil. Zudem wird auf Hands-on-Lösungen und eine offene Kommunikation wertgelegt.
  • Für die Architektur wurde ein SOA-Ansatz gewählt. Zudem wurde die gesamte Infrastruktur innerhalb eines halben Jahres in die AWS-Cloud migriert.
  • Das Team wurde in den vergangenen Jahren auf etwa 800 Mitarbeiter vergrößert. Die dadurch entstehende Komplexität und die notwendige Kommunikation erzeugen einen spürbaren Overhead. Daher hat ABOUT YOU das Organisationsmodell MOVE entwickelt, das durch drei Eigenschaften gekennzeichnet ist.
  1. Open Structure: Das Team ist durch Einheiten (Units) gekennzeichnet, die jeweils aus mehreren kleineren Teams (Circles) bestehen. Diese können sich sowohl themenbezogen spezialisieren als auch flexibel angepasst werden.
  2. Striving for Excellence: MOVE ist darauf ausgelegt, dass Entwickler die Teams auf eigenen Wunsch unkompliziert wechseln können, um sich zu spezialisieren, neue Rollen auszuprobieren oder auch Führungsverantwortung zu übernehmen.
  3. Clarity is King: Es wird offen und ehrlich kommuniziert. Transparenz ist ausdrücklich erwünscht – auch wenn Fehler passiert sind. Aus diesen soll ebenso gelernt werden wie aus Best Practices.

Zuerst veröffentlicht auf www.innovation-implemented.com.