Headless Commerce Beratung durch Experten
Systeme für Headless Commerce erfreuen sich aktuell einer stark wachsenden Beliebtheit, denn es ermöglicht skalierbaren, flexiblen E-Commerce. Aber was steckt eigentlich genau hinter dem Begriff Headless Commerce? Und wie finde ich heraus, ob sich mein Unternehmen tiefer mit dem Thema auseinandersetzen sollte?
Unsere Expertise ist nachgefragt
Wir sind bekannt aus:
Sie möchten wissen, ob Headless Commerce auch für Ihre Organisation geeignet ist?
Unser Vorgehen
Vorgehen & Methodik
- Durchführung eines Workshops zur Ermittlung der grundsätzlichen IT- Strategie und zukünftigen Anforderungen.
- Potenzialanalyse (Macht Headless Commerce Sinn? Was bringt es?)
- Vorstellung von kurz- und mittelfristigen Unternehmenszielen.
Deliverables
- Leitplanken für die Architektur
- Zieldefinition: Was soll die Ziel-Architektur leisten?
Vorgehen & Methodik
- Analyse vorhandener Prozessdokumentation.
- Durchführen von Workshops zur Erhebung von domänenüber-greifenden Datenflüssen.
- Methoden u. a. Requirements Engineering, Event Storming und Capability Map
Deliverables
- Prozesslandkarte
- Architektur Geschäftsobjekte
Vorgehen & Methodik
- Workshops mit der IT zur Identifizierung von derzeit vorhandenen Systemen und zur Definition von Anforderungen und Abhängigkeiten sowie von Legacy-Systemen, die nicht berücksichtigt werden müssen.
Deliverables
- Grobe Systemübersicht
- Skizze
Vorgehen & Methodik
- Analyse und Recherche, ggf. vertiefende Interviews und Abgleich mit Best-Practices.
- Erstellung von Strategiealternativen und Diskussion von Szenarien.
- Vorbereitung von Entscheidungsvorlagen.
Deliverables
- Entwurf Ziel-Architektur zur Abstimmung
Vorgehen & Methodik
- Vorstellung der Ergebnisse und der abgeleiteten IT-Architektur (Führungs-kreis sowie interessierte und betroffen Personen).
- Vorstellung von Aus-wirkungen der Ent-scheidungen für System- und Implementierer-auswahl und weitere Architektur-Überlegungen.
Deliverables
- Abgestimmter Entwurf der IT-Systemarchitektur bzw. Headless Commerce-Architektur
Erfolgreiche Projekte
Wir arbeiten erfolgreich. Obwohl die Voraussetzungen und Anforderungen an eine digitale Strategie fast immer individuell sind, ist ein Aspekt bei allen Projekten gegeben: Hohe Kundenzufriedenheit und echter Mehrwert nach kürzester Zeit.
Wir freuen uns auf den Austausch mit Ihnen!
Unsere Lösungen klingen interessant? Dann sollten wir uns kennenlernen.
Kostenloses Erstgespräch
Sie möchten wissen, ob Headless Commerce auch für Ihre Organisation geeignet ist?
Jetzt kostenlose Erstberatung vereinbaren!
Wissen vertiefen
Einer der wichtigsten Faktoren bei der Entscheidung für Software- und Systemarchitektur ist der Grad der gewünschten Individualisierung.
- Standardprozesse sind üblicherweise “out-of-the-box” abbildbar.
- Schnittstellen zu marktüblichen Systemen oder über standardisierte Protokolle werden oft entweder direkt oder über Plug-Ins unterstützt.
- UI kann über Themes und Konfiguration in unterschiedlichem Maße angepasst werden.
Bei Anforderungen, die nicht über den marktüblichen Standard abgebildet werden können, muss das System um eigen-entwickelte Komponenten erweitert werden. Der notwendige Aufwand für Eigenentwicklungen orientiert sich dabei an:
- Der inherenten Erweiterbarkeit des Systems.
- Der Komplexität der Anforderung.
- Den im System vorhandenen Abstraktionen.
Definition der Verteilung von Geschäftsobjekten und -prozessen
- Welche Geschäftsobjekte sind für die Anforderungen relevant?
- Welche Geschäftsprozesse finden in welchen System statt?
- Welche sind die „Systems of Record“?
- Wie hoch ist die Geschwindigkeit der Datenflüsse?
Modularisierung und Abstraktionen
- Welche der angeschlossenen Systeme sind stabil?
- Welche Anhängigkeiten haben die beteiligten Systeme?
- Welche zukünftige Funktionalität soll unterstützt werden?
- Welche vorhanden Abstraktionen und Schnittstellen sind vorhanden?
Abruf und Transformation von Stammdaten
- Welche Daten müssen zwischen Systemen ausgetauscht werden?
- Wie müssen die Daten transformiert werden?
- Welche Daten müssen in Echtzeit zur Verfügung gestellt werden?
Skalierung und Weiterentwicklung
- Werden zukünftig weitere Geschäftsvorfälle betrachtet?
- Wie flexibel muss das System skalieren?
- Wie hoch ist die Geschwindigkeit der Weiterentwicklung?
- Sollen Komponenten unabhängig voneinander erweitert werden?
Headless Systeme
- UI und Geschäftslogik sind nicht Teil desselben Systems.
- Das Shopsystem besteht ausschließlich aus Geschäftsprozessen, welche über Schnittstellen angesteuert werden.
- Das Backend des Shops bedient verschiedene Customer-Touchpoints -> Website, App, Integration in Kundensysteme.
- Headless Commerce kann nicht nur mehr als ein Frontend bedienen. Headless Commerce ermöglicht es mehrere Frontends beliebig auszutauschen oder zu erweitern.
API-first Systeme
- Nächster Evolutionsschritt der Headless-Systeme
- Das Backend wird ebenfalls über Schnittsellen gesteuert, kann aber in einzelne Systeme zerfallen.
- Unabhängige Geschäftsprozesse können weiter entkoppelt und auf Einzelkomponenten verteilt werden.
- Die Backendkomponenten kommunizieren untereinander ebenfalls über definierte Schnittstellen.
- Als Konsequenz können einzelne Komponenten unabhängig ausgetauscht werden.
Wie kann ich meine Systeme bzw. mein Shop möglichst skalierbar ausrichten?Die Anforderungen an die Skalierbarkeit von Systemen (und damit auch von Frontend und Backend) müssen von Anfang an berücksichtigt werden. Skalierbarkeit bezieht sich dabei sowohl auf vom Benutzer verursachte Systemlast, als auch auf die bereitzustellenden Daten. Dabei ist es wichtig zu beachten, dass nicht alle Systeme skalierbar sind!
Lastspitzen können sich je nach Integration auf nachgelagerte Systeme auswirken. Hohe Anforderungen an die Skalierbarkeit erfordern, dass die notwendige Betriebsinfrastruktur dynamisch angepasst werden kann (IaaS).
Die Anforderungen an die Skalierbarkeit eines Systems definieren zum großen Teil das Betriebskonzept. Weitere für den Betrieb relevante Eckpunkte sind:
- Verfügbares Know-How und Ressourcen
- Anforderungen an Ausfallsicherheit und Hochverfügbarkeit
- Sicherheitskonzept und Datenschutz
- Betriebskonzepte und Architektur der nachgelagerten Systeme
Die Festlegung von Anforderungen steht im Mittelpunkt von vielen Systemauswahlprojekten. Diese Festlegung von Anforderungen geht jedoch tiefer, als die einfache Beantwortung der Frage “Was soll mein Shop bzw. meine System alles könnnen?”. Um tiefer in die Anforderungen an Systeme und damit auch an das Frontend und an das Backend einzusteigen, unterscheiden wir bei der Definition von Anforderungen in Funktionale und Nicht-Funktionale Anforderungen. Neben den Prozessen im “Hintergrund” (funktionale Anforderungen) legen wir in unseren Projekten somit auch verstärkt das Augenmerk auf das Shop Frontend (z. B. Usability).
Funktionale Anforderungen
Können direkt zugeordnet werden.
- Was soll das System machen?
- Interaktionen zwischen System und Nutzer
- Prozessuale Funktionen
Nicht-Funktionale Anforderungen
Können nicht direkt zugeordnet werden und werden oft vergessen!
- Zuverlässigkeit, Ausfallsicherheit 24/7
- Wartung
- Usability / Benutzbarkeit
- Sicherheit / Datenschutz
- Übertragbarkeit
Umfang
- Leistungsanforderungen (Bsp.: Online-Shop soll täglich 500 Bestellungen verarbeiten können)
- Qualitätsanforderungen (ISO/IEC 25000)
- Randbedingungen (von externen Faktoren bestimmt)