15 Jahre Adobe Experience Manager - Eine Geschichte

Bis heute ist es 15 Jahre her, dass Adobe den Kauf von Day Software abgeschlossen und damit das Produkt erworben hat, das Sie alle jetzt als "AEM" kennen.

Für alle unter Ihnen da draußen, die (wie ich) seit Jahren mit dieser Plattform arbeiten, sollte dieser Beitrag hoffentlich eine unterhaltsame (oder schmerzhafte) Reise in die Vergangenheit sein, während wir uns noch einmal ansehen, warum Adobe Day gekauft hat und was sich in den 15 Jahren danach geändert hat (und was nicht!).

Day Communiqué - vor der Übernahme von Adobe

Day Software war ein in Basel, Schweiz, ansässiges Unternehmen, das sein bahnbrechendes Communique CMS auf einer benutzerdefinierten Dateisystem-basierten Plattform entwickelte, sich dann aber später in das Java Content Repository-gestützte System verwandelte, das wir heute kennen.

Die erste Version von CQ war eine Sammlung von CGI-Skripten für Netscape Enterprise Server (Hände hoch, wenn Sie das jemals benutzt haben!) Anfang 2000 und wurde als Java-Anwendung für CQ2 umgeschrieben und dann der HTTP-Server für CQ3 (die Entstehung von CQSE) abgetrennt.

Bis zu CQ4 wurden Inhalte noch in Dateien auf dem lokalen Dateisystem gespeichert, aber im Jahr 2005 wurde mit der Veröffentlichung von CQ 4.0 vom älteren "Content Bus"-Dateisystemspeicher auf das "Content Repository eXtreme" (oder CRX) Repository Version 1.0 umgestellt, eine Weiterentwicklung, die AEM auch heute noch unterstützt - 20 volle Jahre später.

CQ5 war ein MASSIVES UPGRADE und die Grundlage des heutigen AEM

CQ5 stellte eine fast vollständige Neufassung des Produkts dar.

Es gibt eine Reihe von Funktionen und Ansätzen, die heute alltäglich erscheinen mögen, die jedoch große und revolutionäre Teile der CQ5-Plattform waren. In einem charmanten CMSwire-Artikel aus dem Jahr 2008 hieß es: "Während einige CMS-Anbieter vor dem Web 2.0 zurückschrecken, weil sie denken, dass die Implosion des Web 2.0 unmittelbar bevorsteht; Day konzentriert sich sehr darauf." Wie viele Menschen in der heutigen Zeit könnten das Web 2.0 überhaupt definieren ? Aber riesige neue Funktionen, die mit CQ5 veröffentlicht wurden, machten es im Wesentlichen zu einer völlig neuen Plattform, und die meisten von uns könnten sich ein CQ/AEM ohne sie nicht einmal vorstellen, wie zum Beispiel:

• Die Sidekick & Author UI: Die GUI und das WYSIWG-Authoring von CQ waren zu dieser Zeit ein großes Verkaufsargument, und die Tatsache, dass man mit Komponenten in einer grafikreichen Umgebung arbeiten konnte, war ein massiver Fortschritt gegenüber anderen CMS-Angeboten zu dieser Zeit.

  

• Workflows: Mit dieser Version wurde die Workflow-Engine hinzugefügt, die ebenfalls die Leute umgehauen hat, da Sie einen Workflow DIREKT IM CMS visualisieren und die Geschäftslogik direkt in Ihr Content-Management-System integrieren konnten. Ich kann mir vorstellen, dass allein diese Funktion viele Unternehmenskunden beim Wechsel zu dem System überzeugt hat

  

• CQ Tags: Können Sie sich vorstellen, ohne Tags in CQ zu arbeiten? Durch das Hinzufügen von Tag-Unterstützung wurde CQ endlich eine Taxonomie mit vollem Funktionsumfang zur Verfügung gestellt.

• Der DAM: CQ5 hat mit dieser Version einen Digital Asset Manager bekommen, der sich auf dem /content/dam Pfad befindet, mit dem wir jetzt alle so vertraut sind. Schon in dieser frühen Ära brachte es browserbasiertes (nicht Flash!) Bildzuschneiden und -drehen.

  

• Clustering: Dies ist etwas, das nur bis zur CQ5-Version Bestand hat und es nicht in AEM6 geschafft hat, weder im Guten noch im Schlechten. CQ5 verfügte über ein ziemlich erweitertes Clustering, das ein Hot-Aktiv-Clustering- oder Aktiv-Passiv-Clustering sowohl für den Autor als auch für den Verleger ermöglichte. Ich habe genau einen Kunden gesehen, der Publisher-Clustering verwendet hat, es war eine schreckliche Idee und ich habe keine Ahnung, warum sie es getan haben. Das Autoren-Clustering war jedoch eine gute "Idee", die es einem ermöglichte, theoretisch auf einem Cluster-Master zu erstellen und diese Änderungen auf einen Cluster-Slave zu übertragen (Terminologie, die zurückgezogen wurde). Clustering war jedoch immer ein MASSIVES Problem mit der Zuverlässigkeit.

• CRX-Entwicklungsumgebung: Zu dieser Zeit veröffentlichte Day eine Eclipse-basierte Entwicklungsumgebung, in der Sie arbeiten konnten, um einen dicken, clientseitigen Einblick in das Java Content Repository zu erhalten. Sie veröffentlichten auch eine leichtgewichtige browserbasierte Schnittstelle, die anstelle von Eclipse verwendet werden konnte, genannt "CRX Development Environment Lite" oder crxde, die bis heute in fast genau der gleichen Form überlebt hat.

Nicht neu in dieser Version, aber erwähnenswert - die getrennten Authoring- und Publishing-Ebenen von CQ sorgten dafür, dass Leistungseinschränkungen oder Instabilität auf der Authoring-Seite Ihre öffentlich zugängliche Website nicht zum Absturz brachten und umgekehrt. Die Tatsache, dass CQ auf der Grundlage von OSGi und Sling basiert, bedeutete eine äußerst flexible Content-Engine, die sowohl umfangreiche dynamische Antworten und Seitenrendering als auch die Möglichkeit bietet, umfangreiche Java-Lösungen für alle Arten von Anwendungen zu integrieren, die zuvor möglicherweise in einem eigenen Anwendungsserver-Stack ausgeführt werden mussten.

Eine Zeitleiste der CQ-Releases und -Änderungen

Bis zur Übernahme durch Adobe sah die CQ-Versionshistorie wie folgt aus:

• Tag CQ 3.5 (2002)

• Tag CQ 4.0 (2005)

• Tag CQ 4.1 (2006)

• Tag CQ 4.2 (2008)

• Day CQ 5.0 (2008) - nur für interne Kunden als Vorschau freigegeben

• Tag CQ 5.1 (2008) – erste Version von CQ5 mit allgemeiner Verfügbarkeit. Erste Hinzufügung von Workflows, DAM, Tags, CRXDE, Clustering und dem Sidekick

• Tag CQ 5.2 (2009):

  • Verbessertes Digital Asset Management (DAM) mit verbesserter Metadatenverarbeitung
  • Verbesserungen der Workflow-Engine für die Inhaltsverarbeitung
  • Bessere Integration mit Adobe Analytics
  • Hier wurde der Multi-Site Manager (MSM) zum ersten Mal auf der Welt veröffentlicht.

• Tag CQ 5.3 (2010)

  • Einführung von Communities-Funktionen für Social Collaboration (und als Hinweis: AEM 6.5 LTS hat diese Funktion GERADE endgültig eingestellt und entfernt!)
  • "Site Optimizer" für A/B- und multivariate Tests (DIESEN Namen hören wir bald wieder)
  • Verbesserte Übersetzungs-Workflows und Unterstützung bei der Internationalisierung

Die Übernahme von Day Software & CQ durch Adobe

Adobe kündigte im Juli 2010 an, dass sie Day Software und damit das CQ-Produkt kaufen würden. Adobe betrieb zu diesem Zeitpunkt bereits eine eigene Website auf CQ, und angesichts des brandneuen Fokus auf den Aufbau eines Geschäftsbereichs für Marketingtechnologie machte dies Sinn. Adobe hatte gerade im September 2009 Omniture für 1,8 Milliarden US-Dollar und 2007 Scene7 übernommen - es war also klar, dass Adobe begann, sich ernsthaft um mehr als nur sein kreatives Softwaregeschäft zu kümmern.

Die Übernahme durch Adobe wurde im September 2010 für 240 Millionen US-Dollar in einem All-Cash-Deal abgeschlossen, 7-mal billiger als das, was sie für Omniture bezahlt haben - was im Nachhinein ein ziemliches Schnäppchen war.

Ich bin mir nicht sicher, wie es Ihnen geht, aber ich erinnere mich genau, wo ich war, als der Deal bekannt gegeben wurde. Zu dieser Zeit war ich gerade dabei, CQ 5.2 für AARP auszuführen (sie waren seit CQ 4.2 auf CQ). CQ war für mich damals zu gleichen Teilen "massive Kopfschmerzen" und "ist das die Richtung, in die CMS geht?" Angesichts der Tatsache, dass wir immer noch versuchten herauszufinden, welche Dienste auf JBoss bleiben sollten und welche genauso gut in CQ5 ausgeführt werden konnten, da CQ über ein so robustes Java-Anwendungsserver-Framework verfügte.

Aber JETZT VON ADOBE GEKAUFT?? Dadurch änderte sich für mich die ganze Mathematik, ob ich weiterhin Zeit in das Erlernen von CQ5 investieren sollte oder nicht, denn mit Adobe dahinter würde es wahrscheinlich BEINE haben. Und das tat es!

Das "Day Software"-Branding in der App wurde kurz darauf in "Adobe CQ" geändert, obwohl alles andere größtenteils gleich blieb.

• Adobe CQ 5.4 (2011)

  • CRX2-Repository für verbesserte Leistung und Skalierbarkeit (dies war mein erstes großes CQ-Projekt, ein Upgrade der Repository-Migration von CQ 5.3 auf 5.4)
  • Verbesserte Social-Media-Funktionen und Community-Management
  • Bessere mobile Authoring-Funktionen

• Adobe CQ 5.5 (2012)

  • Konnektoren zu Adobe Creative Suite, Scene7 und Search&Promote
  • Direktes Authoring mobiler Apps
  • Partnerschaft mit Hybris für die E-Commerce-Integration
  • Undo/Redo-Funktionalität im Editor
  • Content Fragments tauchten hier zum ersten Mal auf, ebenso wie eine benutzerdefinierte Entwicklung für einen Kunden, mit dem ich tatsächlich zusammenarbeitete, und später als Feature Pack veröffentlicht.

Umbenennung in "Adobe Experience Manager"

Adobe wusste, dass dies nicht für immer "CQ" heißen würde, also versuchten sie einige abgebrochene Rebranding-Versuche, nannten es zuerst "Adobe WCM" und dann eine Weile "Web Experience Manager", bevor sie sich für den Namen "Adobe Experience Manager" entschieden. In der Mitte der Version 5.6 wurde der Anmeldebildschirm umgeschaltet, und Sie sahen jetzt "Adobe Experience Manager", wenn Sie sich bei CQ anmeldeten.

• AEM 5.6 (2013)

  • TouchUI wird für die Autorenumgebung eingeführt (wie viele Anwendungen kennen SIE, die ClassicUI noch verwenden?)
  • Unterstützung mobiler Websites und Apps
  • Verbesserte Personalisierung und Zielgruppenansprache
  • Erweitertes DAM mit Videoprofilen

• AEM 6.0 (2014)
  AEM 6 war eine SIGNIFIKANTE Neufassung vieler Grundlagen von AEM. Für jeden von uns in der Branche nahmen CQ5-> AEM6-Migrationen den größten Teil unserer Zeit in Anspruch, da diese SEHR arbeitsintensiv waren.

  • AEM 6 hat das zugrunde liegende Repository von Apache Jackrabbit auf Apache Oak umgestellt, was eine groß angelegte Migration erforderte.
  • Das Aktiv-Aktiv-Clustering von CQ war nicht mehr verfügbar, obwohl Adobe das MongoMK-Speicher-Backend für AEM eingeführt hat, das theoretisch (zu diesem Zeitpunkt SEHR THEORETISCH) horizontal skalierte AEM-Autoren bereitstellen könnte. Es war jedoch extrem fehlerhaft und unsere einzige Implementierung, die wir dazu gemacht haben, endete in einer Katastrophe und einem Wechsel zu einem TarMK-Einzelautor
  • Größerer Platzbedarf von TouchUI für die meisten Seiten
  • Smart-Tags für Assets

• AEM 6.1 (2015)

  • Viele Fehlerbehebungen, aber 6.1 war immer noch keine besonders stabile Version.
  • Vanity-URL-Unterstützung erschien in 6.1
  • ContextHub für die Personalisierung
  • SDK für mobile Apps
  • AEM Communities wird eingeführt und mit ihm eine Vielzahl von Infrastruktur- und Speicheroptionen für benutzergenerierte Inhalte. Dies würde im Laufe der Zeit verbessert werden, aber es überlebt leider nicht den Wechsel zu Cloud Service.
  • Die AEM Desktop App wurde für 6.1 veröffentlicht, ich habe es geschafft, eine Autorenumgebung mit dieser App zu 100% zu DD:(

• AEM 6.2 (2016)

  • Viele weitere Fehlerbehebungen und Stabilitätsverbesserungen - immer noch keine besonders stabile Version, aber ERHEBLICH besser als 6.1 oder 6.0.
  • Einführung von weit verbreiteten Inhaltsfragmenten (dies konnte früher über das Feature Pack erfolgen, ist aber jetzt Teil des Produkts)
  • SSL-Unterstützung innerhalb von AEM
  • Die Benutzeroberfläche hat sich so verändert, wie wir es jetzt gewohnt sind - die Navigation wurde von der Seitenleiste nach oben verschoben

• AEM 6.3 (2017)

  • Core Components wird als "production ready" eingeführt.
  • Große zugrunde liegende Speicherverbesserungen in Version 6.3 machen dies schließlich zur ersten sehr stabilen AEM 6-Version. Dabei handelte es sich um die Einführung der getrennten datastore und segmentstore und einen zuverlässigen Mechanismus für die Online-Versionsverwaltung (tar compaction).
  • Experience Fragments werden eingeführt
  • Der Single Page Editor (SPA) wird für Single-Page-Apps eingeführt.
  • "Adobe Sensei" beginnt AEM Assets als KI-Branding von Adobe zu durchdringen, mit (damals) ziemlich bahnbrechenden KI-Funktionen. Smart-Cropping, Smart-Tagging usw. fanden ihren Weg in Assets.

• AEM 6.4 (2018)

  • 6.4 war die erste Runde der "Repository-Umstrukturierung", die Upgrades erleichtern und schließlich den Weg für den Wechsel zu Cloud Service ebnen sollte.
  • Workflows wurden auf TouchUI verschoben
  • Eine Reihe von Verbesserungen bei den Übersetzungsdiensten
  • Intelligentes Zuschneiden von Videos in Assets

• AEM 6.5 (2019)

  • Viele Umstrukturierungen von Repositorien
  • Verbundene Assets boten eine potenzielle Option zum Verbinden von Remote-Asset-Umgebungen mit einer separaten AEM Sites-Umgebung. Funktioniert aber nur für Bilder.
  • Enorme Verbesserungen am SPA-Editor
  • GraphQL für den Handel
  • Und da 6.5 nun schon seit 6 Jahren am Leben ist (die längste aller AEM/CQ-Versionen bisher!), gibt es eine Menge neuer Funktionen, die per Service Pack veröffentlicht wurden. Zu diesem Zeitpunkt befindet sich das Service Pack 23, und eine Zusammenfassung aller neuen Funktionen, die seit 2019 veröffentlicht wurden, verdient einen eigenen Blogbeitrag.

• AEM als Cloud-Dienst (2020)
  Erstmals angeteasert auf adaptTo() 2019 (die meisten von uns wussten zu diesem Zeitpunkt noch nicht, was wir wirklich sahen!) AEM as a Cloud Service wurde im Januar 2020 weltweit veröffentlicht und hätte beim Adobe Summit 2020 im Mittelpunkt gestanden... wenn es 2020 einen persönlichen Adobe Summit gegeben hätte. Schade eigentlich. AEM as a Cloud Service wurde entwickelt, um eine Reihe von langjährigen Mängeln von AEM und CQ zu beheben, und hatte dabei unterschiedlichen Erfolg, was wirklich zu der Landschaft der AEM-Angebote führte, die wir heute haben. Was es bietet, ist:

  • Eine vollständig servicebasierte AEM-Umgebung in der Cloud
  • Automatische Skalierung auf Autoren- und Herausgeberebene
  • Eingebautes CDN
  • Massiv aktualisierte Workflow- und Datenerfassungsfunktionen mit Microservice-basierter Asset-Erfassungs-Engine
  • Neue Suchfunktionen, wobei die KI-gestützte (RAG-basierte) Suche gerade veröffentlicht wurde und über die bei adaptTo() gesprochen wird.

• AEM 6.5 LTS
  6.5 LTS wird unterschiedlich als "AEM 6.6" oder "AEM 6.5 LTS" bezeichnet, je nachdem, ob Sie mit Ingenieuren oder Marketingmitarbeitern sprechen, und ist die langfristige Option für Personen, die planen, ihre AEM 6.5-Workloads auch nach 2025 selbst oder AMS-gehostet zu hosten. Java 11 steht kurz vor dem Ende seiner Lebensdauer, daher ist die Ausführung von AEM unter Java 17 oder Java 21 die einzige Option.
  
  Dies ist mit Sicherheit der letzte verbliebene TRUE SUCCESSOR des Vollprodukts, das 2009 auf den Markt kam, da so viele Teile davon (z. /crx/packmgr und /crx/de und /etc/replication.html und so weiter) sind fast GENAU die gleichen wie bei der ursprünglichen CQ5-Version.

• Edge Delivery Services und DA
  Wie sieht die Zukunft von AEM aus? Der funktionale und "spirituelle" Nachfolger von AEM für die Zukunft werden wohl Edge Delivery Services auf der Bereitstellungsebene und Document Authoringauf der Content-Management- und Author-Enablement-Ebene sein. Dies steht absolut zur Debatte, aber DA liefert ein sehr starkes Argument für die Richtung, die AEM in den kommenden Jahren einschlagen wird.

Über den Autor

Gefällt Ihnen, was Sie gehört haben? Haben Sie Fragen dazu, was für Sie das Richtige ist? Wir würden uns freuen, mit Ihnen zu sprechen! Kontaktieren Sie uns

Weitere AEM-Artikel, die Ihnen gefallen könnten