Headless verstehen, einordnen, entscheiden

Microservices, APIs, Cloud und Headless – diese Kombination von Technologien wird im Marketing von Softwareherstellern, Agenturen und Systemintegratoren als „Lösungsansatz der Zukunft” für E-Commerce und Websites propagiert. Im Umfeld von CMS-Systemen 2015 erstmalig erwähnt und häufig nur als „Headless“ bezeichnet, ist die Kombination der vier oben genannten Technologien die Grundlage für alle Headless-Ansätze. Wie jede Technologie muss „Headless“ differenziert betrachtet werden.   

Was ist Headless?

Headless ist im Grunde die konsequent weitergedachte Idee des MVC (Model-View-Controller) Pattern, welches in der Software-Architektur schon lange De-facto-Standard für viele komplexe Systeme ist. Es ist eine Art, Anwendungen per SaaS in der Cloud bereitzustellen (in erster Linie CMS- und E-Commerce-Software – ohne Frontend). Inzwischen bieten alle relevanten Softwareanbieter, wie z.B.  Commercetools, Shopify, Salesforce, SAP, HCL, Spryker, Adobe und E-Spirit ihre Lösungen entsprechend an. 

Headless ist auch ein Architekturmodell, bei dem Microservices der Backend-Applikation und das Frontend mittels wohldokumentierter APIs (meist REST) miteinander verbunden werden. Das E-Commerce der sogenannten „zwei Geschwindigkeiten“ ist abbildbar – das Frontend kann deutlich schneller verändert werden und neue Kanäle können einfacher zugefügt werden. Funktionalitäten im Backend sind weitestgehend unabhängig und meist auch langlebiger.  

Headless kann auch eine Strategie zur Transformation von bestehenden E-Commerce- und CMS-Architekturen sein, um bei gewachsenen Systemen durch einen horizontalen Schnitt eine Vereinheitlichung der Frontends zu erreichen. In Multi-Shop-Szenarien mit verschiedenen Shoplösungen in einem Unternehmen ist das der trivialste Weg zumindest im Frontend eine Standardisierung zu erreichen. 

Das große Versprechen

Headless ist neu, gehypt und somit automatisch interessant für Entscheider, die innovationsfreudig sind. Als Kernargument liefert Headless mehr Flexibilität in Frontends. Und dadurch mehr Geschwindigkeit in der Entwicklung / Weiterentwicklung von Frontends für viele Plattformen. 
Doch Obacht, dieses Leistungsversprechen kommt nicht automatisch. Vielmehr sind Vorbereitungen notwendig, um überhaupt die Vorteile nutzen zu können. Andere Skills werden benötigt, Backend-Systeme müssen neue Attribute für Personalisierung / Segmentierung zur Verfügung stellen, Datenintegration wird bedeutsamer und die Komplexität muss gesteuert werden. 

Chancen

• Inhalt, Funktionalität, Layout und Design sind sauber voneinander getrennt 
• höhere Flexibilität und höhere Veränderungsgeschwindigkeiten im Frontend sind möglich; dadurch ist eine bessere User Experience erreichbar und es kann schneller auf Veränderungen im Markt reagiert werden
• Änderungen im Frontend erfolgen in Stunden oder Tagen und benötigen nicht mehr Wochen oder gar Monate 
• Inhalte einer beliebigen Anzahl von Quellsystemen sind sauber in einem Frontend vereinbar; in Sachen Frontend gibt es kein „führendes“ System mehr  
• konsistent kommunizieren und verkaufen auf mehreren Kanälen (Omnichannel) wird vereinfacht 
• neue (auch heute nicht bekannte) Kanäle sind vergleichsweise einfach anzubinden 
• in Kombination mit Technologien wie SPA und PWA ist eine bessere mobile User Experience möglich 
• freie Auswahl der Head-Technologie

 

Risiken

• weniger gelieferte Funktionalität des Software-Anbieters (das System wird „Headless“ geliefert, d.h. ohne Frontend oder mit einem eher schwachen exemplarischen Frontend) – dies ist durch den Kunden bei den Projektaufwänden zu beachten
• es besteht keine Gewährleistung bei Frontend-Fehlern durch den Softwarehersteller 
• es liegt mehr Verantwortung bei dem Systemintegrator (eigene Mitarbeiter oder Agentur); ein Systemarchitekt mit Durchblick ist unbedingt erforderlich 
• mehr Freiheitsgrade im Frontend bedeutet jedoch auch mehr Verantwortung bei der Implementierung; möglicherweise wird weniger User Experience oder weniger Flexibilität im Frontend erreicht; das hängt einzig von der Qualität der Implementierung ab
• eine Vorschau (Preview) der ausgelieferten Darstellung für den Kanal ist nicht Produktbestandteil und muss gebaut werden 
• durch die Abfrage zur Laufzeit (near realtime) des Frontends ergeben sich erhöhte Anforderungen an die Backend Lösungen – meist muss eine API-Zwischenschicht zusätzlich als Abstraktionsebene gebaut werden (ERP / Logistiksysteme sind alles, nur nicht near realtime fähig) 
• durch ein fehlendes Standard-Frontend des Shops oder des CMS muss das neue Frontend und die bestehenden Backends in Sachen Attributen / Segmentierung / Personalisierung  / Tagging durchdacht werden 
• erschwertes Monitoring und Fehlersuche: das Frontend ist kein Produktbestandteil und erfordert ein eigenes Monitoring in Sachen Performance und Fehler; die Verantwortung für Performanceoptimierung und Fehlersuche liegt beim Kunden bzw. der Agentur – auch dafür gibt es gute Lösungen, sie müssen nur implementiert werden

Headless Antipattern (Headless Architektur mit Vorsicht und standardisiertem Frontend nutzen oder nicht umsetzen)

• nur der Kanal Web wird bedient und die Daten für das Frontend kommen nur aus einem Backendsystem (bleibt das auch mittel- / langfristig so?) 
• Standard-Shop ohne Besonderheiten in Sachen User Experience wird umgesetzt 
• User Experience und mobile Experience sind keine Business-Themen beim Kunden 
• Agentur ohne Headless-Referenzen bietet an (neue Frontend-Technologien folgen anderen Mustern – HTML / CSS / Javaspript sind Skriptsprachen, Angular und Vue ähneln klassischem Java) 
• kein eigenes Frontend Know-how des Kunden vorhanden (Angular, Vue oder ähnliches Framework, allein HTML / CSS ist als Skill nicht ausreichend, s.o.)

 

Sind Aufwände und zusätzliche Komplexität beim Headless-Ansatz durch Vorteile in Flexibilität und Standardisierung im Frontend gerechtfertigt?

Eine weitere Indikation, ob Headless als Architekturmodell passt, liefern Antworten auf die folgenden Fragen: 

• Wie groß ist die Anzahl der Vertriebs- oder Kommunikationskanäle (Multimarken-Shops, B2B, B2C, Social Commerce, POS, IoT)?  
• Wie groß ist die Anzahl der Umsysteme wie CMS, CRM, DAM, PIM, Versandsysteme, Payment, ERP, BI-Systeme? Mit jedem Drittsystem steigen die Synergien und somit die Vorteile, die aus dem Headless-Ansatz gewonnen werden können
• Wie oft verändert das Unternehmen aktiv und bewusst die User Experience für die Endkunden in den Kanälen?

  

Fazit

Headless einfach umzusetzen ist kopflos. 

Vorsicht bei Marketingaussagen in der Branche. Für Web- und E-Commerce-Projekte mittlerer und größerer Komplexität können die Vorteile einer Headless-Architektur überwiegen. Der Nutzen ist jedoch nur sichtbar, wenn die Implementierung handwerklich sauber erfolgt und die Business Ziele vorher klar benannt wurden. Ein großer Teil der Verantwortung liegt bei Headless-Projekten in den Händen von Agenturen / Systemintegratoren / eigener Entwicklungsabteilung. 

Für Projekte mit geringer Komplexität ist im Einzelfall sehr genau abzuwägen, ob die gewonnene Flexibilität Risiken und Aufwände wert ist. Das bedeutet jedoch im Umkehrschluss auch, dass ggf. Software-Systeme ohne mitgeliefertes Frontend nicht ausgewählt werden sollten. 

Mehr Infos:

piazzablu.com/headless

Forrester: https://go.forrester.com/blogs/retail-commerce-never-headless/

Gartner: https://www.gartner.com/en/documents/3988551/hype-cycle-for-api-and-business-ecosystems-2020

McKinsey: https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/building-an-e-commerce-business-lessons-on-moving-fast

Und Headless-Konzepte findet man natürlich bei #sap, #salesforce, #commercetools, #spryker, #shopify. Worin sich diese Konzepte deutlich unterscheiden, stellen wir gern im Gespräch dar.

Bei Interesse hilft ein Gespräch mit piazza blu.