Viele Unternehmen ziehen die Headless-Architektur als neuen Technologiestandard in Betracht. Die Vorteile der Architektur liegen unter anderem bei der Integration von Best-of-Breed-Lösungen.
Die Headless-Architektur ermöglicht es Marken auf der einen Seite ihren aktuellen Branding-Anforderungen zu unterstützen und sie gleichzeitig für zukünftiges Wachstum und Veränderung zu rüsten.
In unserem Vortrag werden wir Ihnen an Beispielen aus der Praxis zeigen, wie eine Headless-Architektur führende Markenunternehmen dabei unterstützt hat, die UX pro Kanal zu optimieren, kurze Time-to-Market für neue Features sowie wenig Abhängigkeiten und überschaubare Entwicklungs- und Betriebskosten zu erreichen.
2. C
0
-
P
U
B
L
I
C
2
REFERENT
HEAD OF E-COMMERCE &
ENGAGEMENT
49 JAHRE
VERHEIRATET, EIN KIND UND
EINE KATZE
22 JAHRE ERFAHRUNG IN MARKETING-,
DIGITALISIERUNGS- UND COMMERCE-PROJEKTEN
MKOSSMANN@SQLI.COM
MATHIAS KOSSMANN
6. C
0
-
P
U
B
L
I
C
6
Einfache und flexible
Integration von zusätzlichen
Services
Agile Entwicklung und kürzere
Release-Zyklen
Front- und Backend-Entwicklung können
voneinander getrennt werden
Verbesserte Entwicklungs-
geschwindigkeit
(wenn die Architektur etabliert
ist)
Entwicklungen können parallel
durchgeführt werden
Skalierbarkeit - Keine Ausfallzeiten, sogar
bei Spitzenbelastungen
TECHNICAL BENEFITS
HEADLESS
7. C
0
-
P
U
B
L
I
C
7
Time-to-Market
Höhere Innovationsmöglichkeiten
durch schnelles Testen neuer
Geschäftsmodelle und Funktionen
Schnelles Reagieren auf die sich ständig
ändernden Kundenerwartungen im
Omnichannel
Best-of-Breed-Ansatz
(Spezialisierte Software-Lösungen
für das Unternehmen)
Zukunftssicher, weil flexibel und
komponentenbaisert
Optimale Customer Experience
BUSINESS BENEFITS
HEADLESS
11. C
0
-
P
U
B
L
I
C
11
HEADLESS
Kein zentrales Shop- und
Content-Management
Spezifikation der
Schnittstelle
Höhere Komplexität
der Gesamtarchitektur
Performance muss
ausbalanciert werden
Erhöhter Aufwand für
Wartung und Tests
Komplexeres
Stakeholder-
Management
Höherer Investitionen &
Verwaltungsaufwand
HERAUSFORDERUNGEN VON
HEADLESS
Verwaltung mehrerer
Lösungsanbieter und
Lieferanten
WYSIWYG-
Bearbeitungsfunktionen
nicht standardmäßig
vorhanden Business & Marketing Perspektive
Technische Perspektive
13. C
0
-
P
U
B
L
I
C
13
HERAUSFORDERUNG
TYPISCHES PROJEKTBRIEFING: ENTWICKLUNG EINER EXPERIENCE- UND
COMMERCE-PLATFORM FÜR EIN NEUES MARKEN- UND
PRODUKTPORTFOLIO
TYPISCHE PROJEKT ZIELE
• Eine Marken-, Konfigurations- und Commerce-Platform, die die bestmögliche
Customer Experience bietet.
• Multi Country basierend auf einem zentralen Prozess- und Technology-Stack
• Möglichkeit der Feature-Variationen auf Länderebene (Sortiment, Checkout- und
Bezahloptionen etc.).
• Integration von bereits vorhandenen relevanten Service- Daten- und Software-
Lösungen, Implementierung neuer Lösungen.
14. C
0
-
P
U
B
L
I
C
14
WARUM HEADLESS?
OMNICHANNEL UND BEST OF BREED
• Die besten Tools und Software Lösungen für alle involvierten Business- und
Marketing-Kompetenzen (ERP, MDM, CRM, CMS, COMMERCE) sollen Anwendung
finden.
• Flexibles Frontend für eine zielgruppenspezifische Experience und Time to Market.
• Distribution an verschiedene UIs (Web, App, B2B, B2C) über eine technische Platform.
15. C
0
-
P
U
B
L
I
C
15
HEADLESS COMMERCE
DIE THEORIE
HEADLESS PLATTFORM
• Frontend ist von der Commerce
Plattform entkoppelt
• Kommunikation zwischen
Frontend und Backend per API
• Dadurch beliebige Frontends
möglich (Web Apps)
HEADLESS DXP/COMMERCE
PLATTFORM
• Redaktionelle Inhalte und
Personalisierung über DXP
Javascript
Storefront
Commerce
Commerce API
Javascript
Storefront
API
DXP/
CMS
Commerce
16. C
0
-
P
U
B
L
I
C
16
HEADLESS COMMERCE
DIE REALITÄT – KOMPLEXITÄT STEIGT SCHNELL
Javascript
Storefront
API
DXP/
CMS
Commerce
ERP CRM PIM/DAM IDM …
API/Middleware
FRONTEND TECHNOLOGIE
• Verschiedene Frameworks möglich
(Angular, Vue, React…)
• Customized Frameworks vom
Lösungsanbieter (Bsp. Spartacus)
COMMERCE / XP LÖSUNG
• Komplette Suite von einem Anbieter (Bsp.
SAP CX mit Spartacus)
• Integration von verschiedenen Anbietern
WEITERE SYSTEME
• Daten- / Logiktransfer über
Schnittstellen (Customizing)
17. C
0
-
P
U
B
L
I
C
17
SAP S4
Platform
Engagement/ CMS
SOLR
Content
Index
OCC
SAP Commerce
Datahub
SOLR
Product
Index
Hotfolder
CSV
export
Realtime REST
(shop functionalities)
Index
Index/Query
Query
Payment
Provider
User
Accounts
Payment
Plugin
Logistik
Services
Marketing
Automation
Tracking
Returnlabels
HEADLESS COMMERCE
DIE PRAXIS – VOM MONOLITHEN ZU HEADLESS
App
Storefront
18. C
0
-
P
U
B
L
I
C
18
HEADLESS ALS EVOLUTION
HEADLESS, OK – ABER WIE KOMME ICH DAHIN?
Headless
Frontend
ERP
CRM
PIM/DAM IDM …
SELTEN GIBT ES EIN „GREENFIELD“ SZENARIO
START MIT DEM FRONTEND
ANBINDUNG WEITERER SYSTEME PER API
NEUER MICROSERVICES AUF CLOUD ARCHITECTUR
Hoch Business Impact Niedrig
ENTWICKLUNG ALS EVOLUTIONÄRER PROZESS
MEHR FLEXIBILITÄT AM FRONTEND KANN SCHNELL
ERREICHT WERDEN
ABER: ARCHITEKTURVORTEILE GREIFEN ERST
SUKZESSIVE
19. C
0
-
P
U
B
L
I
C
19
OHNE CHANGE KEIN ERFOLG
TECHNOLOGIE VERÄNDERT SICH EXPONENTIELL
DIE UNTERNEHMENSORGANISATION MUSS DARAUF
EINGESTELLT WERDEN
DIGITALISIERUNG ALLER DISZIPLINEN IST EIN ENTSCHEIDENDES
ERFOLGSKRITERIUM FÜR EINEN WECHSEL ZU HEADLESS
20. C
0
-
P
U
B
L
I
C
20
OHNE CHANGE KEIN ERFOLG
DXP/
CMS
Commerce
ERP CRM PIM/DAM PLM …
• Finance/
Controlling
• HR
• Sales
• Marketing
• Produktmanagement
• Marketing
• Produktmanagement
• Produktion
• Commercemanagement
• Contentmanagement
OMNICHANNEL =
INTEGRATION UND VERBINDUNG ALLER
DATEN- UND INFORMATIONSQUELLEN
ALLE DISZIPLINEN UND ABTEILUNGEN
MÜSSEN IHREN „DIGITALEN BEITRAG“
LEISTEN
KOMMUNIKATION UND KOOPERATION IST
DER SCHLÜSSEL ZUM ERFOLG
(KEINE SILOS)
21. C
0
-
P
U
B
L
I
C
21
PROJECT LEARNINGS
DAS PROJEKT MANAGEMENT IST KOMPLEXER
• Integration verschiedener Systeme bedeutet auch das Zusammenbringen
verschiedener Stakeholder auf Kunden- und auf Dienstleisterseite…
• …und diese müssen auch im Projektverlauf verfügbar sein.
• Im Scoping bedarf es einer ausgeprägten Genauigkeit, alle Systeme und damit
verbundenen Prozesse und Datenflüsse müssen berücksichtigt werden.
DIE ABSTIMMUNG ZWISCHEN DEN ENTWICKLERTEAMS MUSS PASSEN
• Getrennte Entwicklungsteams sind möglich und notwendig, die technischen
Abhängigkeitsmomente müssen jedoch klar definiert und berücksichtigt werden
(z.B. Verbindung von Front- und Backend über Schnittstellen).
DEFINITION DER BENÖTIGTEN INFORMATIONS- UND DATENFLÜSSE
• Datenflüsse und –herkünfte müssen final definiert sein. Das klingt einfach und
logisch, ist es in der Realität von gewachsenen Systemen aber in den meisten Fällen
nicht. Redundante Datenhaltung und Insellöungen sind spätestens bei der
Entwicklung einer Headless Architektur ein No Go.
22. C
0
-
P
U
B
L
I
C
22
FAZIT
TIME-TO-MARKET
EIN MUSS FÜR OMNI-CHANNEL BASIERTE BUSINESS MODELLE
ES BRAUCHT KONSTANT ABGESTIMMTE TEAMS, DIE UNABHÄNGIG VONEINANDER
ARBEITEN, ABER VERSTEHEN, WAS DER ANDERE MACHT (T-SHAPED
PROFESSIONALS)
HEADLESS HAT HÖHERE INITIALKOSTEN UND WIRD ABER MITTELFRISTIG GÜNSTIGER
UND EFFIZIENTER
HEADLESS GEHT ALLE ABTEILUNGEN IM UNTERNEHMEN AN
23. C
0
-
P
U
B
L
I
C
23
HEADLESS FÜR UNS?
1. Hohe Anzahl der Kanäle und Touchpoints
Je mehr User-Touchpoints desto höher die Synergieffekte
2. Viele zu integrierende Umsysteme
Mit jedem weiteren zu integrierenden System steigt die Effizienz
3. Häufige UX-Anpassungen für die verschiedenen Kanäle
Je Häufiger Veränderungen an den Touchpoints vorgenommen werden desto
mehr lohnt sich ein Headless Ansatz
24. C
0
-
P
U
B
L
I
C
24
DAS FAZIT: AUF HEADLESS MUSS
MAN SICH EINLASSEN
…UND ALS UNTERNEHMEN TRAGEN KÖNNEN
SAP
Commerce
Move2Cloud
for
Westfalen
AG
„Auf Headless muss
man sich als
Unternehmen
einlassen können“