Über die Digital Experience Platform (DXP) im Allgemeinen wird in der letzten Zeit viel gesagt und geschrieben. Insbesondere über das Aufsetzen einer DXP auf der Grundlage einer MACH- oder Composable-Architektur, wobei MACH für Microservices-based, API-first, Cloud-native SaaS und Headless steht.
Allerdings stellt sich die Frage, ob ein wirklicher Unterschied zwischen diesen beiden Architekturen besteht. Und je mehr ich darüber lese, desto eher neige ich dazu, zu sagen, dass dem nicht so ist. Es gibt durchaus Unterschiede, aber das Problem, das beide Architekturen aufgreifen, bleibt das gleiche. Da Kunden immer häufiger Fragen dazu haben, erläutere ich dieses Thema gerne.
Composable DXP: Alter Wein in neuen Flaschen
Über die Digital Experience Platform ist man sich im Großen und Ganzen einig, dass wir nämlich nicht in einer Zeit leben, in der nur eine einzige, zusammenhängende Digital Experience Platform eine vollständige Ende-zu-Ende-Erfahrung für eine Customer Journey leisten kann. [Mit Customer Journey meine ich: Branding, Targeting, Engagement, Bereitstellung von Produkten, Diensten und Kundenservice für einen bestimmten Kunden, Kundenbindung und ihn zum Markenbotschafter machen.] Darüber hinaus umfasst eine DXP die Implementierung digitaler Funktionen, die Sie für den Teil der Customer Journey benötigen, den Sie integriert unterstützen möchten, um Ihren Kunden eine reibungslose und positive Erfahrung zu bieten.
Eine einzige, allumfassende Definition für die DXP gibt es jedoch nicht. Es geht um die Breite der Customer Journey, die Sie unterstützen möchten sowie Tiefgang und Intensität der Personalisierung, mit der dies geschehen soll.
Wir können eine DXP somit als eine Art Referenzarchitektur betrachten, die Sie nutzen können und bei der Sie wissen, dass sich die Einsatzweise im Laufe der Zeit verändern wird, beispielsweise, wenn Sie Ihr Geschäftsmodell anpassen. Oder sobald Kunden etwa eine neue Technologie einsetzen.
MACH und Ihre Composable DXP
Wenn Sie also Flexibilität bei Ihrer DXP-Architektur benötigen, jetzt und in der Zukunft, und außerdem den Überblick und die Kontrolle über Ihre Investitionen behalten möchten, ist eine DXP – die nur Funktionalitäten umfasst, die zu bestimmten Zeiten gebraucht werden – die richtige Entscheidung.
Spezifische Funktionsanforderungen (z. B. nach dem Umstieg von einem indirekten Kanal zu einem eher hybriden direkten Kanal im Einzelhandel) können sich im Laufe der Zeit ändern. Somit müssen Sie in der Lage sein, diese Funktionen relativ schnell zu isolieren und zu ersetzen, um mit den sich ändernden Geschäftsanforderungen Schritt zu halten.
Gleiches gilt für den Bedarf an neuen Funktionen, zum Beispiel wenn Sie durch den Einsatz einer Customer Data Platform in Kombination mit KI zu einer stärker automatisierten Arbeitsweise auf der Grundlage von Hyperpersonalisierung übergehen.
Dieser Einsatz einer Composable DXP ist nur möglich, wenn Ihre DXP neben den composable DXP-Funktionen über zwei Grundelemente verfügt:
- Eine Zwischenschicht zwischen der Composable DXP-Funktionalität, die aus APIs besteht, die mit einer DXP-Funktionalität (z. B. Ihrer E-Commerce- oder CRM-Anwendung) und einer Reihe von (Micro-)Services verbunden werden können.
- Ein Headless-Ansatz. Da sich alles um die Interaktion mit dem Kunden dreht, muss jede benötigte Anwendung nach Headless-Prinzipien entwickelt werden, sodass sie technisch unabhängig von der zugrunde liegenden Composable DXP-Funktionalität ist. Aus architektonischer Sicht bietet dies die Flexibilität, Headless-Apps für die Kundeninteraktion bzw. Composable DXP-Funktionalität nach Bedarf auszutauschen.
Die Kommunikation mit den Kunden in einer digitalen Welt und mit der notwendigen Unterstützung durch eine DXP, die mehrere zusammenstellbare Funktionen umfasst, erfordert aus technischer Sicht meiner Meinung nach eine Cloud-Plattform.
Wenn wir Microservices (für Verknüpfungen), APIs zu Composable DXP-Funktionen, die Cloud und Headless-Apps aufgreifen, um flexibel mit den Kunden zu kommunizieren und kundenorientierte Bedürfnisse und Erwartungen zu erfüllen, landen wir automatisch bei einer MACH-Umgebung.
Die Implementierung einer erfolgreichen und nachhaltigen Composable DXP führt automatisch zu „MACH by design“. Eine Composable DXP-Funktionalität ist viel mehr als eine zusammenstellbare konventionelle DXP-Funktionalität wie Content Management, E-Commerce, Campaigning, (E-Mail-)Marketing usw. Daten (mittels Kundendatenplattform) werden immer der wichtigste Erfolgsfaktor für eine DXP sein. Und wie ein MACH-Design sollte auch Ihre Kundendatenplattform von Anfang an Teil Ihrer DXP-Lösung sein.
Während ein MACH-Design es Ihnen ermöglicht, Elemente (Composable DXP-Funktionalität) über Ihre Digital Experience Platform zu verknüpfen, um mit Ihren Kunden zu kommunizieren, gibt Ihnen Ihre Customer Data Platform Aufschluss darüber, wie Sie diese in der richtigen Reihenfolge anordnen können.
Microservices, APIs, Cloud – kommt Ihnen das bekannt vor?
Wir brauchen Microservices, APIs und Cloud-Technologie, um jedes System über Ihre DXP zu verknüpfen. Je mehr „Breite und Tiefgang“ Sie sich von Ihrer DXP wünschen und benötigen, um die Customer Journey zu unterstützen, desto mehr wirkt sie sich auf andere Systeme aus, beispielsweise Ihr CRM-, SCM-, ERP-System oder Ihre Geschäftsanwendungen.
Wenn Sie nicht über eine Plattform zur Unterstützung Ihrer alltäglichen Tätigkeiten verfügen, haben Sie eine hybride Palette an Systemen: von standardisierten bis zu unternehmensspezifischen. Tatsächlich handelt es sich auch hier um eine Art Composable Architektur, die allerdings weniger dynamisch ist als im DXP-Bereich.
Um diese Systeme miteinander zu verknüpfen, verwenden wir seit Jahrzehnten eine Middle-Layer-Architektur. Irgendwann entwickelte sich diese zu einem Enterprise Service Bus und dann zu einer API bzw. (Micro-)Services-Schicht, die wir heute noch verwenden.
Aber auch in der eher klassischen Backend-Welt ist mehr Flexibilität gefragt. Denken Sie zum Beispiel an eine Low-Code-Unternehmensanwendung, die es den Mitarbeitern ermöglicht, flexibler auf die sich ändernden Bedürfnisse und das Verhalten der Kunden zu reagieren. Dieser Trend verstärkt den Bedarf nach einer ausgereiften Mittelschicht, die aufgrund ihrer Struktur zunehmend eine Cloud-Umgebung benötigt, um zu existieren. Es gibt also eine Parallele zu einem der Grundelemente des DXP. Diese digital operations setting wird derzeit von den Forschungseinrichtungen als Digital Operations Platform bezeichnet.
Das ist im Grunde eine gute Nachricht. Denn wenn Sie Ihre DXP auf Ihre operativen digitalen Systeme ausdehnen, werden Sie feststellen, dass die Verknüpfung aus architektonischer Sicht nicht viel anders ist als bei einer Composable DXP-Umgebung.
Holen Sie den maximalen Nutzen aus Ihrer DXP-Plattform
Wenn Sie die ersten Schritte auf dem Weg zur DXP gemacht haben, haben Sie einen entscheidenden Meilenstein erreicht. Aber damit ist der Prozess noch nicht abgeschlossen. Denn wie stellen Sie sicher, dass die Plattform auch langfristig einen Mehrwert bietet? Dafür braucht es eine durchdachte Umsetzung und eine größtmögliche Akzeptanz. Sie müssen sich auch fragen, ob Sie über die richtigen Kompetenzen verfügen und wie sie in eine flexible Anwendungslandschaft passen. In diesem Whitepaper gehen wir auf die Herausforderungen einer DXP für CTO und CMO ein und geben Ihnen 4 Tipps an die Hand, mit denen Sie den maximalen Mehrwert aus Ihrer Plattform ziehen können.
