Die Zukunft Ihres DXP

Wie kann Ihre Infrastruktur für digitale Erlebnisse mit dem ständigen Wandel Schritt halten? Lassen Sie uns einen Schritt von der Technologie zurücktreten und einen Blick auf das große Ganze werfen, damit Ihr DXP lange leben und gedeihen kann.

Im Laufe der Jahrzehnte, in denen ich an digitalen Projekten gearbeitet habe, habe ich einige Faustregeln aufgestellt. Einige davon sind bloße Beobachtungen; einige sind gute Ratschläge; einige sind unbequeme Wahrheiten. Die wahrscheinlich lästigste davon ist die folgende: "Die Lebensdauer Ihrer DX-Implementierung beträgt etwa drei Jahre".

Das ist nicht das, was man hören möchte, wenn man viel in eine komplette Neuplattformierung investiert und viel Zeit und Mühe aufwendet, um es dieses Mal endlich und endgültig richtig zu machen. Eine Neuplattformierung ist kostspielig, ressourcen- und zeitintensiv und definitiv nichts, was man alle drei Jahre machen möchte. Wie kann man also aus diesem Kreislauf ausbrechen?

Ich könnte ein Buch über die Gründe schreiben (und das werde ich auch tun), aber lassen Sie uns einige der wichtigeren ansprechen.

Zunächst einmal, bevor Sie sagen: "In unserem Fall war es nicht so!" Ich gebe zu, dass es nicht immer auf den Punkt genau drei Jahre sind. Ich habe schon erlebt, dass es nach sechs Monaten geschah (als klar wurde, dass der Betrieb der neuen Plattform untragbar teuer war) und sogar nach zwölf Jahren (als die Trägheit der Organisation endlich überwunden wurde, um den Wechsel vorzunehmen). Aber im Allgemeinen setzt sich nach etwa drei Jahren der Gedanke durch, dass die Dinge anders gemacht werden müssen.

Dafür gibt es viele Gründe; ich fasse es als "Revolution versus Evolution" zusammen. Manchmal lässt sich eine Neuplattformierung des gesamten digitalen Angebots nicht vermeiden, aber man sollte es stattdessen kontinuierlich weiterentwickeln. Eine Neuplattformierung ist störend, und das nicht auf eine gute Art und Weise.

Wenn Sie über Erfahrung verfügen und bereits mehrere Runden der Neuplattformierung hinter sich haben, steht Flexibilität ganz oben auf Ihrer Wunschliste. Sie wissen, dass die digitale Erfahrung ein bewegliches Ziel ist, daher möchten Sie die Möglichkeit haben, die Plattform entsprechend den sich ändernden Anforderungen weiterzuentwickeln.

Eine gängige Lösung für dieses Problem ist die "Zukunftssicherung". Da aber niemand von uns eine voll funktionsfähige Kristallkugel hat, gibt es so etwas nicht. Zukunftssicherheit ist eine Übung, bei der man den Ozean zum Kochen bringt und alles hinzufügt, was man eines Tages brauchen könnte. Die drohende Gefahr ist, dass dies zu einer schleichenden Ausweitung des Umfangs auf Steroiden führt und Ihre Neuplattformierung über Jahre hinauszieht.

Was wir eigentlich tun müssen, ist, uns auf den Wandel einzustellen und das Unbekannte anzunehmen. Aber das ist leichter gesagt als getan.

Wenn Sie mit einem Architekten über Zukunftssicherheit oder Bauen für den Wandel sprechen, wird das Gespräch wahrscheinlich in eine dieser beiden Richtungen gehen:

Wenn ich an einen Monolithen denke, denke ich an den in 2001: Odyssee im Weltraum. Ein schwarzes längliches Gebilde, dessen Inneres man nicht sehen kann, das so dunkel ist, dass kein Licht von ihm reflektiert wird - die ultimative Black Box. Wenn Sie versuchen, einen Monolithen zu analysieren, um ihn durch eine modernere Architektur zu ersetzen, sollten Sie sich die Szene aus dem Film ansehen, in der der Monolith auf dem Mond untersucht wird - sie wird Ihnen unheimlich vertraut sein.

Im Gegensatz dazu ist es wichtig zu bedenken, dass eine moderne digitale Erlebnisinfrastruktur niemals nur aus einem System besteht. Selbst mein persönlicher Blog, der nur mit dem Minimum betrieben wird, nutzt etwa ein Dutzend verschiedener Dienste. Wenn Sie eine DXP verwenden, die den Anspruch erhebt, alle Bereiche abzudecken, handelt es sich um einen Monolithen, den Sie aber funktional erweitern wollen. Eine DXP-Infrastruktur ist niemals ein Monolith. Sie ist wie Stonehenge. Aber wenn Sie sich nur auf einen Felsen konzentrieren, werden Sie nie das große Ganze sehen.

Die meisten Unternehmen können es sich nicht leisten, ihren gesamten DX-Stack von Grund auf neu aufzubauen. Die Antwort auf die Frage "bauen oder kaufen" lautet "beides". Es geht darum, intelligent einzukaufen und dann die Integrationen zu erstellen. Leider hat dies seinen Preis, da Sie nicht bestimmen können, wie die von Ihnen gekauften Dienste tatsächlich aufgebaut werden. In vielen Fällen geht es nicht einmal darum, wie alle Dienste bereitgestellt werden - viele von ihnen sind Black Boxes, die Sie nicht einmal in Ihrer eigenen Infrastruktur betreiben.

Wenn ich also in diesem Zusammenhang von "Diensten" spreche, meine ich nicht die Microservices. Ich meine nicht einmal Makroservices (auch bekannt als "die Rache des Monolithen"). Hier geht es nicht wirklich um ein Dienstnetz, Messaging-Warteschlangen oder API-Gateways. Das soll nicht heißen, dass diese Dinge keine Rolle spielen - das tun sie sehr wohl, vor allem, wenn Sie umfangreiche Integrationen aufbauen.

Einige der grundlegendsten Probleme in Ihrer DX-Infrastruktur betreffen jedoch das, was ich als "funktionale Dienste" bezeichne. Oft überschneiden sich mehrere funktionale Dienste und konkurrieren um den gleichen Platz. Werden Sie beispielsweise Benutzeridentitäten in Ihrem DXP, DMP, CRM verwalten oder IAM verwenden? (Wahrscheinlich alle in irgendeiner Form.) Verwalten Sie Bilder in einem MAM, DAM, PIM oder CMS? (Das hängt oft davon ab, in welcher Art von Unternehmen Sie tätig sind.) Und so weiter.

Die einzige Möglichkeit, die Übersicht zu behalten, ist auf funktionaler Ebene. Ich habe oft Diagramme mit "Funktionsbereichen" erstellt, um die Konflikte zwischen funktionalen Diensten greifbarer zu machen. Dabei müssen Sie zunächst einige Hürden überwinden - die Techniker werden es als "Pseudoarchitektur" betrachten, und viele Leute auf der Geschäftsseite werden es für zu technisch halten. Aber so kann das Gespräch auf ein Kernthema gelenkt werden: Welche Funktionen gehören wohin? Von welchem System aus werden wir diesen Informationsfluss kontrollieren?

Wenn Sie ein gutes Verständnis der Funktionsbereiche im DX-Bereich haben, können Sie viel fruchtbarere Gespräche über Ihre Roadmap führen. Welche funktionalen Dienste müssen wir in den nächsten 6-12 Monaten ersetzen, um einen wichtigen Funktionsbereich in der DX-Infrastruktur zu überholen? Welche müssen wir hinzufügen? Wer werden im Wesentlichen Ihre DXP-Partner sein? Auf diese Weise lassen sich größere infrastrukturelle Veränderungen planen und durchführen, ohne dass es zu einer schmerzhaften "Revolution" in Form einer kompletten Neuplattformierung kommt. Stattdessen können Sie eine stetige Evolution erleben, bei der Sie funktionale Dienste ein- und auswechseln oder neue Back-Office- und Front-End-Dienste integrieren.

Achten Sie dabei auf die babylonische Verwirrung. Bei den klassischen Auseinandersetzungen zwischen Unternehmen und Technik kann das Unternehmen von "Microservices" sprechen, meint damit aber in der Regel "funktionale Dienste". Für die Technik können diese "funktionalen Dienste" aus vielen Microservices (oder Makroservices oder Monolithen) bestehen.

Eine architektonische Entscheidung, die in der Regel der Softwarearchitektur überlassen wird, ist die Frage, wo alles zusammengeführt wird. Man kann die Integration nicht den Frontends überlassen. In den meisten modernen Konfigurationen werden sie von den Back-End-Systemen entkoppelt (Headless). Das Web ist nur eine weitere App, neben iOS, Android und anderen Geräten, die Sie bedienen wollen. Diese Apps führen dann Hunderte von API-Aufrufen durch, um die Bildschirme zu erstellen:

Moderne Telefone sind nicht mehr die begrenzten Geräte, die sie einmal waren, und mein aktuelles Telefon hat einen schnelleren Prozessor als der Laptop, den ich vor fünf Jahren hatte. Aber die Latenzzeiten und der Overhead bei vielen verschiedenen Systemaufrufen machen das Erlebnis immer noch zunichte.

Eine gängige Lösung hierfür ist der Aufbau einer eigenen mittleren Schicht oder die Verwendung eines der Stacks zur Integration oder Vereinheitlichung der APIs. Eine andere Möglichkeit ist, etwas Ähnliches für das Front-End zu tun. Hier müssen Sie ein Softwareunternehmen werden. Sie müssen einen sehr wichtigen Teil der Infrastruktur aufbauen und pflegen, der über Erfolg oder Misserfolg Ihrer Anwendungen entscheiden kann. Wie ich bereits erwähnt habe - ja, Bereitstellung und Softwarearchitektur sind wichtig.

Das potenziell größere Problem ist jedoch die Frage, wie man es funktionell verwalten kann. Die technische Herausforderung lässt sich lösen, aber wie geht man dann damit um? Der Albtraum von Content- und Marketing-Ops ist es, in all die verschiedenen Backends zu gehen, um eine Kampagne einzurichten, sie zu verfolgen und zu überwachen. Und in der Regel ist es unmöglich, die Auswirkungen von Änderungen in einem System, die Interaktion mit etwas aus einem anderen System und das Endergebnis für einen bestimmten Benutzer noch zu sehen oder zu verstehen.

Mein Name ist Adriaan. Ich bin Niederländer, aber ich lebe in Dubai und Spanien und mag Pinguine und Porsches. Wofür wird Ihr Schieberegler bei mir werben?

Wenn möglich, müssen Sie also eine Backend-Schnittstelle auswählen, um die Backends zu koordinieren. Nutzen Sie diese als Dreh- und Angelpunkt für die Verwaltung der digitalen Erfahrung und integrieren Sie die anderen benötigten Quellen, damit die Redakteure die Inhalte im Kontext bearbeiten und überprüfen können. Das technische Problem wird dadurch nicht gelöst - Sie müssen immer noch die Kommunikation mit den Frontends vereinheitlichen und diese Anwendungen mit clientseitigen SDKs überfrachten. Aber zumindest werden die Teams wissen, wo sie die Knöpfe drücken müssen und was sie damit auslösen.

Die Art der Integration wird einen großen Einfluss darauf haben, wie Sie arbeiten; lassen Sie dies nicht allein eine technische Entscheidung sein.

Abschließend möchte ich noch einmal betonen, dass die funktionale Architektur viel mehr Aufmerksamkeit erfordert, was aber nicht bedeutet, dass Sie die Softwarearchitektur ignorieren sollten. Sie brauchen eine solide Softwarearchitektur und Praktiken, um Integrationen zu pflegen und weiterzuentwickeln. Allerdings sollte man sich über den Unterschied zwischen der funktionalen Architektur und der eigentlichen Softwarearchitektur im Klaren sein. Was mir an dem Begriff "digitale Erfahrung" gefällt, ist, dass er das Ziel (die digitale Erfahrung) vor die Tools stellt. Wenn das das Ziel ist, das Sie anstreben, dann sollten Sie bei der "Entwicklung für den Wandel" mit der Kategorisierung der Funktionsbereiche beginnen.

Ich habe Stonehenge jetzt zweimal erwähnt, und die wichtige Frage bleibt: Es ist ein beeindruckendes Bauwerk, aber was ist sein eigentlicher Zweck? Und darüber sollten Sie nachdenken, wenn Sie wollen, dass Ihr DX auch so lange hält.

Dieser Gastbeitrag ist der zweite einer Serie von fünf Artikeln, die Adriaan Bloem für Magnolia geschrieben hat.

Oh, und eine süße Überraschung für Sie: Adriaan schreibt nicht nur Blogartikel für Sie, er hat auch ein Buch geschrieben: