Die passende DXP-Architektur für Ihre Journey.
Eine DXP-Architektur ist kein Baukasten, den man einmal kauft und dann hat. Sie entsteht aus der Frage, welche Berührungspunkte Ihre Zielgruppen auf dem Weg zu Ihnen brauchen – und welche Systeme diese Punkte zuverlässig bedienen. Wir bauen diese Brücke: von der Customer Journey zur technischen Architektur, die sie trägt.
Was ist eine Digital Experience Platform (DXP)?
Seit einigen Jahren fasst man das Zusammenwirken von CMS, DAM, PIM, eShop und weiteren Systemen unter dem Begriff Digital Experience Platform zusammen. Architektur entscheidet, wie diese Systeme zusammenspielen: als ein großes System, als Kombination spezialisierter Systeme oder als viele kleine, unabhängige Dienste. Welche Zusammenstellung passt, richtet sich nicht danach, was ein Anbieter verkauft, sondern danach, welche Capabilities Sie tatsächlich brauchen.
DXP ist ein Überbegriff für eine lösungsorientierte Zusammenstellung von Marketing-Technologien – vom Content-Management-System als Herzstück über DAM, PIM und E-Commerce bis zu CRM, Personalisierungs-Engines, Analytics und API-Layer. Welche Systeme in welcher Kombination eingesetzt werden, ist kundenindividuell und nicht vorab definiert.
Architektur folgt der Journey, nicht umgekehrt
Bevor man fragt, welches System das richtige ist, muss man fragen, welche Phasen Ihre Nutzer durchlaufen – von der ersten Wahrnehmung über die Abwägung bis zur langfristigen Bindung – und welche Berührungspunkte in jeder Phase wirklich zählen. Aus diesen Touchpoints leiten sich die Prozesse ab, die dahinterstehenden Verantwortlichkeiten, und erst danach die Anwendungen, die das leisten müssen. Wer mit dem System beginnt statt mit der Journey, baut eine Architektur, die zufällig passt statt gezielt.
Wie wir zur passenden Architektur kommen
-
Ist-Landschaft als Capability Map erfassen
Nicht als Liste einzelner Systeme, sondern gruppiert nach den fachlichen Fähigkeiten entlang Ihrer Journey. So wird sichtbar, was heute welche Rolle spielt – und wo sich Systeme unnötig überschneiden.
-
Laufende Vorhaben einordnen
Parallel laufende Großprojekte – neue Fachverfahren, Systemwechsel, Rebranding – geben der Architektur ihre Zeitachse vor und dürfen nicht isoliert betrachtet werden.
-
Zielarchitektur und Muster festlegen
Auf Basis der Capabilities und Rahmenbedingungen: monolithisch, composable oder Microservices – oder eine begründete Kombination daraus.
Drei Wege, die Bausteine zusammenzuführen
Ein Anbieter deckt möglichst viele Capabilities in einem System ab, externe Frontends sprechen über eine gemeinsame API. Das hält die Anbieterlandschaft einfach und lässt sich mit Bordmitteln schnell umsetzen.
Wer allerdings über die mitgelieferten Funktionen hinauswill, handelt sich Zusatzintegrationen ein – und eine Abhängigkeit vom gewählten Anbieter, die sich später nur schwer auflösen lässt.
Spezialisierte Systeme verschiedener Anbieter werden über APIs zu einer Erlebniswelt zusammengeführt – „best of breed” statt „ein Anbieter für alles”. Das passt zu spezifischen Anforderungen, die ein Monolith nicht abdeckt.
Der Preis dafür ist Verantwortung: Mit wachsender Systemzahl braucht es eine klare Orchestrierungsebene, sonst wächst die Komplexität schneller als der Nutzen.
Ein System wird in viele kleine, unabhängig lauffähige Dienste zerlegt, die über klar definierte Schnittstellen kommunizieren – ideal für große, dynamische Systeme mit hohem Skalierungsbedarf.
Das bringt eine deutlich höhere Betriebskomplexität mit sich, die entsprechendes DevOps- und Sicherheits-Know-how im Team voraussetzt – unabhängig von der Unternehmensgröße.
Wie setzt sich eine DXP zusammen?
Auch wenn es keinen branchenspezifischen, normierten und allseits akzeptierten Glossar für die Begriff in unserer Branche gibt, versuchen wir es an dieser Stelle, damit wir über die gleichen Dinge sprechen können.
Eine DXP ist eine Zusammenstellung und Integration von Marketing Technologien, die den Zweck haben, die digitale Customer Journey als ein durchgehendes Nutzererlebnis (Experience) zu ermöglichen. Die verschiedenen Bestandteile können wir in zwei Lager einteilen:
- Im DXP-Core liegen die Systeme, die Inhalte und Daten führen: CMS, DAM, PIM, eShop, TMS.
- Die DXP-Extension ergänzt Fähigkeiten wie Personalisierung, Tracking, Suche, Marketing Automation, CRM, A/B-Testing, CDP und Reporting.
Verbunden wird beides über eine API- und Orchestrierungsschicht, die wiederum das Ziel hat Datenflüsse flexibel zwischen den Systemen und auch zu den Output Channels zu verwalten.
Die Zusammenstellung sollte sich immer an den benötigten Capabilities orientieren – nicht an dem, was ein Hersteller gerade im Portfolio hat. Denn: Einzelne Systemekönnen dieselben Fähigkeiten in sehr unterschiedlicher Tiefe und Qualität bündeln. Zwei Systeme, die beide „Personalisierung” auf der Featureliste stehen haben, können in der Praxis meilenweit auseinanderliegen, erzeugen aber parallel Kosten.
Drei Denkfehler, die teuer werden
Nur, wenn die Orchestrierung mitgedacht wird. Ohne eine zentrale Schnittstellen-Verwaltung wächst mit jedem neuen System die Komplexität schneller als der Nutzen.
Einfach im Betrieb, aber gebunden an das, was ein Anbieter liefert. Fehlende Funktionen bedeuten Zusatzintegrationen – und die vermeintliche Einfachheit löst sich auf.
Sie passen überall dort, wo hohe Skalierbarkeit und häufige, unabhängige Weiterentwicklung gebraucht werden – unabhängig von der Unternehmensgröße, aber nicht ohne entsprechendes Betriebs-Know-how.
So geht`s weiter!
Die neue DXP-Architektur ist konzipiert. Wie geht es jetzt weiter? Das kommt in erster Linie darauf an, welche konkreten nächsten Schritte sich ableiten lassen. Um Ihre Ziele aber zu verfolgen, kann SUTSCHE Sie in den unterschiedlichsten Bereichen unterstützen.
SUTSCHE übernimmt die Rolle der Projektleitung, ergänzt als Projektsupport für Product Owner und dient als Sparringspartner für Kundeninterne Rollen im Projekt. Dabei unterstützen wir die Projektplanung und Steuerung aber auch inhaltliche Tätigkeiten von Budgetierung bis Funktionstesting.
Damit das Projekt wirklich schlüsselfertig vorbereitet ist, fehlt noch ein Implementierungspartner. Die Agentur baut das Projekt technisch nach den Anforderungen, Vorgaben und Rahmenbedingungen aus dem Backlog. Ein perfekter Zeitpunkt also nach der Konzeption auf die Suche nach einem Dienstleister für die Umsetzung zu gehen.
Ein häufiger Irrglaube ist, dass die Migration bzw. Aufbereitung des Contents erst beginnen kann, wenn ein Dienstleister gefunden und die Implementierung gestartet hat. Tatsächlich ist die Content Migration häufig das Nadelöhr und der kritische Pfad im Projekt, der gerne unterschätzt wird. Starten Sie die Content Migration frühzeitig, wir helfen Ihnen auf dem Weg.
Lassen Sie es
uns anpacken
„Projektkümmerer“ hat uns vor Jahren ein Kunde genannt. Der Name ist geblieben, weil er stimmt. Sagen Sie uns, wo es gerade hakt – wir kümmern uns.