Unbequeme Wahrheiten über Ihr DXP

Nach etwas mehr als zwei Jahrzehnten, in denen ich Inhalte verwaltet, Websites erstellt und digitale Erlebnisse geschaffen habe, habe ich ein Buch voller Anekdoten und Narben, die zeigen, dass ich sie erlebt habe. Und während die Verwaltung digitaler Erlebnisse gereift ist, sind einige Probleme im Laufe der Zeit ärgerlicherweise gleich geblieben. Sie sind sogar so beständig, dass sie zu meinen lästigen Faustregeln geworden sind.

Das sind Dinge, die niemand sagen will und von denen wir alle hoffen, dass sie der Vergangenheit angehören, aber sie kommen immer wieder vor, wie ein digitales Murmeltiertag-Erlebnis. Natürlich gibt es immer Ausnahmen von den Regeln, aber es ist harte Arbeit, sie zu vermeiden, und man kann sie nicht ignorieren. Hier sind fünf von ihnen.

Ich habe mir jetzt dreimal ein eigenes System gebaut. Beim ersten Mal wusste ich es nicht besser - und in den späten 90er Jahren gab es nicht so viel Auswahl wie heute. Aber als wir anderthalb Jahre dabei waren und ich vorführen musste, was wir mit den meisten (zugegebenermaßen wichtigen) Backend-Diensten erreicht hatten, war es schmerzlich offensichtlich. "Wenn ich 'mooh' eingebe, gibt es 'splut' aus! Das bedeutet, dass die Berechtigungen und das Repository funktionieren", war kein gutes Argument. Wir wechselten zu einem gebrauchsfertigen System und passten es stattdessen an, und da wurde mir diese Wahrheit bewusst. Ich fand das System zwar nicht toll, aber es war auf jeden Fall besser, als wenn wir unser eigenes System hätten entwickeln müssen.

Bei den beiden darauffolgenden Malen dachte ich, die Dinge würden irgendwie anders laufen. Aber selbst mit einem Millionenbudget, großartigen Architekten, fantastischen Partnern und Dutzenden von Entwicklern stellte sich heraus, dass die Lektion dieselbe ist. Einige sehr große Technologieunternehmen haben das Memo immer noch nicht erhalten, und das Wichtigste, was sie davon abhält, zur Vernunft zu kommen, ist ein starkes "Hier wurde nichts erfunden"-Syndrom, möglicherweise in Verbindung mit einer Unterschätzung dessen, was kommerziell verfügbare Systeme besser machen würden.

Wenn Sie also nicht davon überzeugt sind, dass Sie das neue Facebook bauen, sollten Sie kein eigenes CMS entwickeln.

Ich habe bereits in der Vergangenheit darüber geschrieben, aber es ist immer noch etwas, das Projektmanager und Budgets durcheinander bringt. Auch wenn Sie glauben, dass die teure Lizenz für Ihr neues DXP-System viel kostet, so ist es doch nur ein Bruchteil der tatsächlichen Kosten für die Implementierung - und ich meine wirklich nur die anfängliche Neuplattformierung. Es ist vielleicht nicht genau das Siebenfache, aber wenn man Integratoren, interne Ressourcen usw. mit einbezieht, kommt man unweigerlich in die Nähe dieser Kosten. In der Praxis bedeutet das zweierlei: Ziehen Sie die Augenbrauen hoch, wenn Ihnen ein Vertriebsmitarbeiter sagt, dass es viel weniger sein wird, und bleiben Sie nicht zu sehr an den hohen Kosten des Systems hängen, für das Sie eine Lizenz erwerben - das ist vielleicht die geringste Ihrer Sorgen.

Ab und zu sagt mir ein Schlaumeier: "Aber wir verwenden Open Source, also ist die Lizenz kostenlos! Und sieben mal Null ist immer noch Null." Das ist bei einem Kaffee ganz witzig, aber weniger, wenn Ihnen auf halbem Weg zur Implementierung das Geld ausgeht. Die Implementierung von Open Source kann sogar noch teurer sein (sie kompensiert oft die eingesparten Gebühren), und sich auf die "kostenlose" Version von kommerziellem Open Source zu verlassen, ist fast immer "penny wise, pound foolish".

Unterschätzen Sie nicht die Gesamtkosten einer Implementierung, indem Sie die versteckten Kosten optimistisch ignorieren, denn Sie werden später dafür bezahlen.

Eine der Utopien bei der Verwaltung von Inhalten besteht darin, sie semantisch zu strukturieren, und zwar so atomar wie möglich. Sie sollten über gute Metadaten, einschließlich Deskriptoren, verfügen und völlig frei von Formatierung oder Design sein. Das Problem ist, dass dies im Gegensatz zu HTML steht, das seit langem Inhalte mit Design vermischt. Ihre Inhalte werden daher mit Sicherheit viele Elemente enthalten, die für die jeweilige Version Ihrer Website oder Ihres CMS spezifisch sind. Und wenn Ihr Inhalt fett und kursiv ist, Links, Aufzählungen, Tabellen und Bilder enthält, ist er ein unstrukturierter Klumpen, der auf eine Seite zugeschnitten ist. Selbst die besten Bemühungen, ihn sauber zu halten, werden einige Ecken und Kanten haben.

Wenn Sie also Ihre digitale Präsenz neu gestalten wollen, wird sie an vielen Stellen kaputtgehen. Und wenn Sie eine automatisierte Migration von einem System zu einem anderen (oder von einer Version zu einer anderen) durchführen wollen, müssen Sie fast zwangsläufig eine größere Bereinigung vornehmen oder die Skripte ständig anpassen.

Von der Bereinigung des eigentlichen Inhalts ganz zu schweigen. Sie müssen herausfinden, welche Inhalte Sie streichen, welche Sie aktualisieren und welche Sie hinzufügen wollen. Es gibt Tools, die Ihnen dabei helfen, aber es ist eine große Aufgabe, und ich habe an einem Projekt mitgearbeitet, das mehrere Jahre gedauert hat (zugegeben, es waren fast eine Million Seiten). Wenn jemand sagt, "wir machen eine automatische Migration", seien Sie sehr skeptisch - und erwarten Sie nicht, dass es über Nacht geht.

Ignorieren Sie nicht, wie komplex eine Inhaltsmigration ist, auch wenn Sie sie gerne automatisieren würden, und planen Sie entsprechend.

Bei der Implementierung eines DXP handelt es sich nicht nur um eine Anwendung auf Ihrem MacBook, die über Nacht automatisch aktualisiert wird. Es handelt sich in der Regel um eine hochkomplexe Infrastruktur, die mehrere Server und Dienste umfasst. Selbst bei einfachen Systemen ist es also wahrscheinlich, dass Sie auf Probleme stoßen. Je individueller Ihre Umgebung ist, desto schwieriger werden die Upgrade-Skripte sein. Wenn Sie sich genau ansehen, was kaputt gehen könnte und was auf jeden Fall kaputt gehen wird, sollten Sie sich Gedanken machen, vor allem, wenn es sich um eine neue Hauptversion handelt.

MACH (insbesondere die "API-first"- und "headless"-Teile davon) kann Sie vor dem größten Teil davon bewahren, aber seien Sie vorsichtig. Ich bin sogar schon auf das Problem mit einem SaaS-Content-Management-Dienst ohne Kopfhörer gestoßen. Ich kannte die internen Versionen nicht und hatte auch keinen Einblick in den Veröffentlichungszeitplan. Ein größeres Update brachte unsere Anwendungen trotzdem zum Einsturz, und zwar wegen einiger winziger, aber katastrophaler Änderungen an den APIs.

Unterschätzen Sie nie, wie viel ein Upgrade kaputt machen kann, vor allem, wenn Sie nicht genau wissen, was es ändern wird.

Ich habe dies bereits in meinem früheren Beitrag "Die Zukunft Ihres DXP" erwähnt, aber es lohnt sich, es zu wiederholen. Wenn Sie die Dinge nicht wirklich anders angehen als zuvor, wird Ihr Re-Platforming und Ihr glänzender neuer DXP etwa 3 Jahre halten, mehr oder weniger. Es ist schwer, aus diesem Kreislauf auszubrechen, und deshalb ist dies auch eines der Hauptthemen des Buches: Wie kommt man von einer wiederholten "Revolution" zu einer stetigen "Evolution"? Wenn Sie die Zeit haben, verspreche ich Ihnen, dass es sich lohnt, es zu lesen. Holen Sie sich also Ihr kostenloses Exemplar!

Dieser Gast-Blogbeitrag ist der vierte 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: