ShopTechTalks #5: Globetrotter

In der fünften Ausgabe der ShopTechTalks spreche ich mit Sebastian Heuer, Lead-Developer bei Globetrotter. Er gewährt uns einen Blick hinter die technischen Kulissen des Outdoorartikel-Händlers und erläutert, warum sich das Team für eine Eigenentwicklung entschieden hat, anstatt auf eine Standardlösung zu setzen. Außerdem skizziert er den Weg von der Planung der Architektur über die Auswahl der konkreten Technologie hin zur Umsetzung und Weiterentwicklung.

Die im Podcast erwähnte Präsentation findet sich bei Slideshare:

Die erwähnten Veranstaltungen sind:

8 Gedanken zu „ShopTechTalks #5: Globetrotter

  1. Alexander Hofmann

    Sehr sehr sehr interessanter Podcast Roman! Definitiv höhrenswert!

    Eigentlich für alle größeren Stores interessant, wenn ein Relaunch etc. ansteht.
    Evtl. wird die globetrotter Entwicklerabteilung noch zur Agentur aufgrund des gesammelten KnowHows? 😉

    Und doch: Die beschriebene, proprietäre Eigenlösung und damit ein verhältnismäßig großes Entwickler-Team kann sich doch nur ein wirklich großes Online-Handels-Unternehmen leisten.
    Wie erwähnt bleiben die Shop-Features von der Bedeutung her hinter den elementaren Fragestellungen (Was will und braucht der Kunde) zurück.
    Aber die individuelle Anbindung z.B. von spezialisierten Shop-Suche-Anbietern wie Fact-Finder (die existierenden und gewarteten Plugin-Ins zu Standard-Shopsystemen sind schließlich nicht verwendbar) sind somit mehr oder minder aufwändig und sollten zumindest bedacht werden.

    Auch die Angesprochene Problematik bei z.B. Ausfall des Frontend-XML-Entwicklers/Designers (Stichwort: Frontend als größte Baustelle)
    ist sehr interessant.

    Die Eigenentwicklung muss hier im konkreten Falle schon extreme Vorteile gegenüber einigen Kompromissen hinsichtlich der individuellen Anpassung bei Umsetzung mittels eines der am Markt bewährten Standard-Shopsysteme bieten, zumal auch eine Plugin-Eigenentwicklung verhältnismäßig „strukturiert“ und problemlos möglich ist und weil sich alle zukünftigen Entwicklungen direkt in „manuellen“ Anpassungsaufwand und damit Personalbedarf niederschlagen.

    Was noch interessant gewesen wäre, sind die Unterschiede bzw. die erfolgten Entwicklungen bzgl. der M-Commerce Strategie (Responsive vs. Single-Page-App etc.)
    Aber dies hatten die letzten Shoptech-talks schon sehr intensiv zum Thema.

    Gefällt 1 Person

    Antwort
  2. Sebastian Heuer

    Hallo Alexander!

    Tatsächlich setzt eine Individualentwicklung, wie wir sie umgesetzt haben, eine entsprechend gut ausgebildete (und motivierte!) Entwicklermannschaft voraus. In den 1,5 Jahren Projektlaufzeit haben wir alle wahnsinnig viel gelernt und auch eine ganz neue Perspektive auf die Entwicklung qualitativ hochwertiger (und damit langlebiger) Software erhalten. Dieses aufgebaute Wissen muss natürlich im Unternehmen bleiben, was aus Arbeitgebersicht eine gewisse Herausforderung darstellt. Trotzdem halte ich persönlich eine Abhängigkeit des Unternehmens von einer internen Entwicklungsabteilung für angenehmer als die von einer externen Agentur – gerade bei einem inzwischen so lebenswichtigen Bereich wie dem Shop.

    Von der technischen Warte aus ist eine individuelle E-Commerce-Lösung DIE Plattform für Innovation; auch das war ein wichtiger Faktor bei der Entscheidungsfindung. Natürlich hätte man globetrotter.de auch mit einer Standardlösung an den Start bringen können – das Unternehmen hätte seine Anforderungen einfach an den Möglichkeiten des gewählten Shopsystems ausrichten müssen. Aber damit geht eben auch fast automatisch eine Mitläuferrolle am Markt einher.

    Ich baue darauf, dass die großen Vorteile des von uns eingeschlagenen Weges in naher Zukunft auch für den Nutzer sicht- und spürbar(er) werden. Schon jetzt sind wir sehr flexibel und schnell, wenn es um die Entwicklung neuer Features oder kurzfristiger Deployments kleinerer Änderungen geht. Auch die direkt in die Applikation integrierten Möglichkeiten von A/B Tests können ein hervorragender Katalysator für die Evolution des Shops darstellen. Der im Cast angesprochene Wandel mit einem stärkeren Fokus auf dem Onlinehandel wird (und muss) dazu führen, dass wir diese Stärken besser ausspielen können.

    Und um noch das Beispiel Suchmaschinen-Anbindung aufzugreifen: Der Austausch von Solr gegen FACT-Finder ist bei uns zwar nicht durch die Installation eines (bestenfalls) vom Hersteller zur Verfügung gestellten Plugins erledigt, stellt aber durch eine saubere Abstraktion des Suchbackends keine große Herausforderung dar. Und wir holen uns nicht eine weitere kleine Blackbox ins Haus, von der wir einfach annehmen, dass sie funktionieren wird. 😉

    Was das Thema M-Commerce angeht: Vor wenigen Tagen wurde m.globetrotter.de gelauncht und wir sammeln gerade die ersten Erfahrungen damit. Wenn ein paar Wochen ins Land gegangen sind, setze ich mich mit diesem Projekt gerne (auch kritisch) öffentlich auseinander und freue mich über jede Diskussion!

    Gefällt mir

    Antwort
    1. Alexander Hofmann

      Hallo Sebastian!

      Danke für deinen schnellen und umfangreichen Kommentar! Die Offenheit (auch schon im Podcast) ist einmalig (sehr selten) und gewährt evtl. anderen, die vor ähnlichen Problemen stehen, sehr tiefe und v.a. praktische Einblicke!

      @Agentur: Gemeint war nur, dass das erlernte Wissen (Projekterfahrung) idealerweise für andere Projekte dieser genutzt werden „könnte“. 😉 Dem Vorteil der langfristigen Unabhängigkeit stimme ich auch so zu!

      @m-Commerce: Viel Erfolg hierbei!

      Gefällt mir

      Antwort
  3. Pingback: ShopTechTalks #5: Wie Globetrotter ohne Caching auskommt | Exciting Commerce

  4. sbehn

    Hallo zusammen,

    ungeheuer interessanter Podcast. Ich würde nur gerne in einem kleinen Detail wiedersprechen. Im Endeffekt setzt ihr ja einen Cache ein, oder? Meiner Interpretation nach, nimmt Redis doch genau diese Rolle bei euch ein. Und euer Worker, der aus dem Backend die Daten als pre-rendered HTML im Redis ablegt übernimmt die Aufgabe des Cache-Warm-Ups. Kein Varnish und kein FPC, aber doch ein Cache.

    So oder so, finde ich die herangehensweise genial, unkonventionell und pragmatisch. Eine Detailfrage habe ich jedoch noch. Sebastian erwähnte, dass man überrascht ist wie schnell das hantieren mit XMLs ist. Das legt die Frage nah, ob ihr wirklich fertige HTML Schnipsel im Redis ablegt, oder einfach alle benötigten Daten zb in Form eines JSON? Bzw. ob ihr das mal gegeneinander getestet habt. Gerade in Hinblick auf das Mobile Frontend dürfte zweiteres doch Vorteile haben, weil für eine Produkt-Detail-Seite eines Produkts nicht zwei Einträge vorhanden sein müssen (eins je Frontend). Auf der anderen Seite würde das einem eurer Grundprinzipien wiedersprechen: „Das Frontend so dumm wie möglich gestalten, damit es so schnell wie möglich ist.“ Klar, ein plakativer Satz, aber trotzdem hilft er einem bei jeder Entscheidung ob ein neues Stück Logik im Frontend oder eben doch im Backend abgefackelt werden soll.

    Danke und Grüße,
    Steffen

    Gefällt 1 Person

    Antwort
  5. Sandra Felber

    Technik hin oder her – es wurden bei diesem Relaunch ganz Entscheidende Dinge vergessen:

    Die MARKE, die NUTZERFÜHRUNG, das DESIGN.

    Insofern wurde m.E. komplett am Ziel vorbeigearbeitet, den Shop als Teil einer Gesamtstrategie Online und Offline als zu etablieren.

    Es sei denn, Globetrotter möchte demnächst eher als Softwarebude an den Markt gehen.

    MFG
    Sandra Felber

    Gefällt mir

    Antwort

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s