4. September 2020
Oliver Goerke
Wer die aktuelle Diskussion um das Buzzword headless verfolgt, der findet es in fast in jedem Kontext – egal ob es um CMS oder Shopsysteme geht. Es scheint das neue Allheilmittel für die moderne Zeit und eine Konsequenz aus dem Microservice-Hype. Das hier von piazza blu realisierte Projekt bietet einen praxisbezogenen Blickwinkel in Bezug auf die Nutzen eines solchen Ansatzes.
Der Projektkunde agiert als reines Distanzhandelsunternehmen mit umsatzstarkem B2B-Schwerpunkt und kleinerem, aber auch relevantem B2C-Anteil. Die Vertriebsstrategie verteilt sich über mehrere Vertriebsmarken mit verschiedenen Sortimentsschwerpunkten in mehreren Ländern und Sprachen.
Die Webseiten (Shop + CMS) wurden für B2B und B2C zeitlich versetzt auf verschiedenen Systemen aufgesetzt. Für Content hat der Kunde jeweils die internen Möglichkeiten der Shopsysteme genutzt und ergänzend WordPress eingesetzt. Zentral betrieben werden das ERP und das PIM. Diese Vorgehensweise scheint ein guter Kompromiss.
Das B2B-Geschäft mit viel Umsatz ist frei von den „Risiken“ der Änderungen und für den kleineren B2C-Anteil kann man etwas experimentierfreudiger sein. Es bedarf keiner Anforderungskonsolidierung für alle fachlichen Nutzer der verschiedenen Online-Kanäle. Umgekehrt gibt es aber auch das Problem, dass eine Synergie über die Kanäle nicht genutzt werden kann. Dies liegt daran, dass hier entsprechende Silos im Bezug auf Funktion und Daten bestehen.
Die mittlerweile hohe Anzahl der eingesetzten Systeme bringt neben den Vorteilen (fertige Features für eine bestimmte Funktion, „Out-of-the-Box Speed“) auch die Herausforderung der Verwaltung und Integration dieser Systeme untereinander mit sich. Diese wirkt „belastend“, indem die durch fertige Features und deren Nutzung gewonnene Zeit wieder verbraucht wird – für das systemspezifische Management, die Integration und das dauerhafte Betreiben vieler Systeme.
Hier entsteht langfristig betrachtet ganz klar die These: Durch das Reduzieren der Systeme/Instanzanzahl kann man Zeit und Kosten sparen. Die Investition in Konsolidierung der Systemanzahl und Nutzung einer gemeinsamen, parametrisierbaren Schablone trägt langfristiges Potential in sich.
Der jetzige Online-Redaktionsprozess (= jegliche Konzeption, Erstellung und Pflege von Inhalten) ist stark belastet vom systemspezifischen „Einbauen“ der Inhalte in das jeweilige System und bedarf in vielen Fällen der technischen Unterstützung für das jeweilige System. Durch Einsatz eines zentralen CMS und Vereinheitlichung und „Schablonierung & Strukturierung“ kann die Effizienz gesteigert werden, die „qualitativ“ (bessere Inhalte) oder quantitiv (mehr Inhalte) reinvestiert werden kann.
Zunächst gilt es festzuhalten, dass die bestehende Systemlandschaft im Backend (PIM, ERP) komplett stabil bleibt. Im Bezug auf die Shopsysteme wird auf ein System konsolidiert, dass bereits mandantenfähig in die Landschaft integriert ist und die historisch gewachsene CMS-Landschaft wird ebenfalls auf ein System konsolidiert.
Beim Frontend fällt die Wahl auf React, aber kombiniert mit next.js für Server-Side Rendering auf Basis von node. Als Eintritt in die Backend-Services dient ein Graph QL fähiges API Gateway auf Basis von quarkus.io, das als Single Point of Contact für die Frontend-Anwendung dient und auch die Security konsistent nach außen über JWT Token abbildet.
Um das zeitlich eng gesteckte Ziel von 8 Wochen zu erreichen, bedarf es eines sehr klaren Scopes bis zum Livegang. Ein solches Vorhaben ist aufgrund der Risiken und Kompromisse, die nötig sind, nicht sinnvoll bei einem trafficstarken Shop. Also wählen wir einen Markenshop für eine neue Kundengruppe. Wir raten grundsätzlich zur Vorsicht bei Versprechungen über sehr kurze Durchführungszeiträume bei Shopprojekten, die ja in Coronazeiten von allen in den Mund genommen werden. Sie sind möglich, aber das Dreieck aus Zeit, Qualität und Kosten lässt sich auch in diesen Zeiten nicht außer Kraft setzen.
Im Sinne einer Priorisierung erfolgt also eine klare Diskussion im Team, welche Themen klar einem Post-Go-Live Scope zuzuordnen sind, also nicht für den Go-Live absolut notwendig sind. Weiterhin versuchen wir immer, das Projekt selbst von allen „Ramp-up“ Themen zu befreien. Welche Frameworks nutzen wir für’s Styling? Wie ist die Codestruktur? Wie machen wir die Buildpipeline? Welche Systeme muss man aufsetzen? Wenn diese Dinge nicht zum Start schon funktionieren, wird die Projektzeit deutlich belastet. Dies sind aber Prozesse und Fragen, bei denen man sich einer standardisierten Schablone bedienen kann.
Wir haben den Go-Live Termin und einen erfolgreichen Launch erreicht. Die Arbeitsergebnisse dieser ersten Phase kann man nun für die Konsolidierung der Shop-Frontends auf diese Plattform nutzen. Das zentrale headless CMS steht zur Verfügung und erlaubt die Pflege aller Inhalte. Eine Systematik zur Pflege der Seiten, derer Layouts und Grids wurde etabliert. Dadurch ist insbesondere eine komplexere Contentausspielung pflegbar (nach Segmentierung, Preislisten oder Anmeldestatus).