15 ans d’Adobe Experience Manager - Une histoire

À ce jour, cela fait 15 ans qu’Adobe a finalisé l’achat de Day Software, acquérant ainsi le produit que vous connaissez tous maintenant sous le nom de « AEM ».

Pour tous ceux d’entre vous qui (comme moi) travaillent avec cette plate-forme depuis des années, j’espère que cet article devrait être un voyage divertissant (ou douloureux) dans le passé pour vous alors que nous revisitons pourquoi Adobe aurait acheté Day, et ce qui a changé (et n’a pas changé !) au cours des 15 années qui ont suivi.

Communiqué de la journée - avant le rachat d’Adobe

Day Software était une société basée à Bâle, en Suisse, qui a créé son CMS révolutionnaire Communique sur une plate-forme basée sur un système de fichiers personnalisé, mais qui s’est ensuite transformée en le système basé sur le référentiel de contenu Java que nous connaissons aujourd’hui.

La première version de CQ était une collection de scripts CGI pour Netscape Enterprise Server (levez la main si vous avez déjà utilisé celui-ci !) au début des années 2000, et a été réécrite en tant qu’application Java pour CQ2, puis le serveur HTTP s’en est séparé pour CQ3 (la genèse de CQSE).

Jusqu’à CQ4, le contenu était toujours stocké dans des fichiers sur le système de fichiers local, mais en 2005, avec la sortie de CQ 4.0, il a été remplacé par l’ancien stockage du système de fichiers « Content Bus » par le référentiel « Content Repository eXtreme » (ou CRX) version 1.0, dont une évolution alimente encore AEM aujourd’hui, 20 ans plus tard.

CQ5 était une MISE À NIVEAU MASSIVE et la base de l’AEM d’aujourd’hui

CQ5 représentait une réécriture presque complète du produit.

Il existe un certain nombre de fonctionnalités et d’approches qui pourraient sembler banales aujourd’hui et qui étaient des parties énormes et révolutionnaires de la plate-forme CQ5. Un charmant article de CMSwire de 2008 notait : « Alors que certains fournisseurs de CMS se détournent du Web 2.0, pensant que l’implosion du Web 2.0 est imminente; Day se concentre là-dessus. Combien de personnes de cette époque pourraient même définir le web 2.0 ? Mais les nouvelles fonctionnalités énormes publiées avec CQ5 en ont essentiellement fait une plate-forme entièrement nouvelle, et la plupart d’entre nous ne pourraient même pas imaginer un CQ/AEM sans elle, telles que :

• L’interface utilisateur Sidekick & Author: l’interface graphique et la création WYSIWG de CQ étaient un énorme argument de vente à l’époque, et le fait que vous puissiez travailler avec des composants dans un environnement riche en graphiques était un énorme pas en avant par rapport aux autres offres CMS de l’époque.

  

• Flux de travail: Le moteur de flux de travail a été ajouté avec cette version, qui a également époustouflé les gens, en ce sens que vous pouviez visualiser un flux de travail DIRECTEMENT DANS LE CMS et développer une logique commerciale directement dans votre système de gestion de contenu. Je peux imaginer que cette fonctionnalité à elle seule a vendu beaucoup d’entreprises clientes lors de la migration vers le système

  

• CQ Tags: Pouvez-vous imaginer travailler dans CQ sans tags ? L’ajout de la prise en charge des balises a finalement apporté une taxonomie complète à CQ.

• Le DAM: CQ5 s’est doté d’un gestionnaire d’actifs numériques avec cette version, situé dans le /content/dam chemin que nous connaissons tous si bien maintenant. Même à cette époque, il a apporté le recadrage et la rotation des images basés sur un navigateur (pas Flash !).

  

• Clustering: il s’agit d’un problème qui n’a duré que jusqu’à la version CQ5 et n’a pas été intégré à AEM6, pour le meilleur ou pour le pire. CQ5 disposait d’un clustering assez avancé, qui permettait une configuration de clustering actif-actif ou actif-passif à chaud pour l’auteur et les éditeurs. J’ai vu précisément un client utiliser le clustering Publisher, c’était une idée terrible et je n’ai aucune idée de pourquoi ils l’ont fait. Le clustering d’auteurs ÉTAIT cependant une bonne « idée » permettant à quelqu’un de créer théoriquement sur un maître de cluster et de faire en sorte que ces modifications se propagent à un esclave de cluster (terminologie qui a été retirée). Le regroupement, cependant, a toujours été un énorme casse-tête de fiabilité.

• Environnement de développement CRX: à l’époque, Day a publié un environnement de développement basé sur Eclipse dans lequel vous pouvez travailler pour avoir une vue épaisse côté client dans le référentiel de contenu Java. Ils ont également publié une interface légère basée sur un navigateur qui pourrait être utilisée à la place d’Eclipse appelée « CRX Development Environment Lite » ou crxde, qui survit encore à ce jour sous presque exactement la même forme.

Ce n’est pas nouveau dans cette version, mais cela vaut la peine d’être mentionné : les niveaux distincts de création et de publication de CQ ont fait en sorte que les contraintes de performance ou l’instabilité du côté de la création n’ont pas fait tomber votre site public, et vice versa. Le fait que CQ s’appuie sur OSGI et Sling signifiait un moteur de contenu extrêmement flexible, capable à la fois de réponses dynamiques riches et d’un rendu de pages, ainsi que la possibilité d’intégrer en Java toutes sortes d’applications qui, auparavant, auraient dû s’exécuter dans leur propre pile de serveurs d’applications.

Une chronologie des versions et des modifications de CQ

Jusqu’à l’acquisition d’Adobe, l’historique des versions de CQ se déroulait comme suit :

• Jour CQ 3.5 (2002)

• Jour CQ 4.0 (2005)

• Jour CQ 4.1 (2006)

• Jour CQ 4.2 (2008)

• Day CQ 5.0 (2008) - uniquement disponible pour les clients internes en tant qu’aperçu

• Day CQ 5.1 (2008) - première version générale de CQ5. Premier ajout des Workflows, DAM, Tags, CRXDE, Clustering et le Sidekick

• Jour CQ 5.2 (2009) :

  • Gestion améliorée des actifs numériques (DAM) avec une meilleure gestion des métadonnées
  • Améliorations du moteur de flux de travail pour le traitement de contenu
  • Meilleure intégration avec Adobe Analytics
  • C’est là que Multi-Site Manager (MSM) a été lancé pour la première fois dans le monde.

• Jour CQ 5.3 (2010)

  • Introduction des fonctionnalités de communautés pour la collaboration sociale (et à titre de remarque, AEM 6.5 LTS uniquement vient de déprécier et de supprimer cette fonctionnalité!)
  • « Site Optimizer » pour les tests A/B et multivariés (nous entendrons à nouveau CE nom bientôt)
  • Flux de traduction améliorés et prise en charge de l’internationalisation

L’acquisition par Adobe de Day Software et de CQ

Adobe a annoncé en juillet 2010 qu’il allait acheter Day Software, et avec lui le produit CQ. À ce moment-là, Adobe gérait déjà son propre site Web sur CQ, et compte tenu de son tout nouvel objectif sur la création d’un secteur d’activité de technologie marketing, cela avait du sens. Adobe venait d’acquérir Omniture en septembre 2009 pour 1,8 milliard de dollars, et Scene7 en 2007 - il était donc clair qu’Adobe commençait à prendre au sérieux quelque chose de plus que son activité de logiciels créatifs.

L’acquisition par Adobe a été finalisée en septembre 2010 pour 240 millions de dollars dans le cadre d’une transaction entièrement en espèces, soit 7 fois moins cher que ce qu’ils ont payé pour Omniture - ce qui était une sacrée aubaine avec le recul.

Je ne sais pas pour vous, mais je me souviens exactement où j’étais quand l’accord a été annoncé. J’étais en train d’exécuter CQ 5.2 pour AARP à l’époque (ils étaient sur CQ depuis CQ 4.2). À l’époque, pour moi, c’était à la fois un « énorme casse-tête » et « est-ce là où va CMS ? » étant donné que nous essayions toujours de déterminer quels services devaient rester sur JBoss et lesquels pouvaient tout aussi bien s’exécuter dans CQ5 maintenant que CQ disposait d’un cadre de serveur d’applications Java aussi robuste.

Mais ACHETÉ PAR ADOBE MAINTENANT ?? Cela a changé tous les calculs pour moi sur le fait de continuer à investir du temps dans l’apprentissage de CQ5, car évidemment avec Adobe derrière, il était probable qu’il ait des jambes. Et c’est ce qui s’est passé !

La marque « Day Software » à l’intérieur de l’application a été rapidement remplacée par « Adobe CQ », bien que tout le reste soit resté le même, pour la plupart.

• Adobe CQ 5.4 (2011)

  • Référentiel CRX2 pour des performances et une évolutivité améliorées (c’était mon premier grand projet CQ, une migration de référentiel de mise à niveau de CQ 5.3 vers 5.4)
  • Fonctionnalités sociales et gestion de communauté améliorées
  • Meilleures capacités de création mobile

• Adobe CQ 5.5 (2012)

  • Connecteurs vers Adobe Creative Suite, Scene7 et Search&Promote
  • Création directe d’applications mobiles
  • Partenariat avec Hybris pour l’intégration du commerce électronique
  • Fonctionnalité d’annulation/rétablissement dans l’éditeur
  • Les fragments de contenu ont fait leur apparition pour la première fois ici, ainsi qu’un développement personnalisé pour un client avec lequel je travaillais en fait, et plus tard publié sous forme de pack de fonctionnalités.

Changement de marque en « Adobe Experience Manager »

Adobe savait que cela n’allait pas s’appeler « CQ » pour toujours, alors ils ont essayé quelques tentatives avortées de changement de marque, d’abord en l’appelant « Adobe WCM », puis « Web Experience Manager » pendant un certain temps avant de se décider à l’appeler « Adobe Experience Manager ». C’est au milieu de la version 5.6 que l’écran de connexion a basculé, et vous voyiez désormais « Adobe Experience Manager » lorsque vous vous connectiez à CQ.

• AEM 5.6 (2013)

  • TouchUI est introduit pour l’environnement d’auteur (combien d’applications connaissez-vous qui utilisent TOUJOURS ClassicUI ?)
  • Prise en charge des sites et des applications mobiles
  • Amélioration de la personnalisation et du ciblage
  • DAM amélioré avec profils vidéo

• AEM 6.0 (2014)
  AEM 6 était une réécriture SIGNIFICATIVE d’un grand nombre des fondements d’AEM. Pour tous ceux d’entre nous dans le secteur CQ5 -> les migrations AEM6 ont pris la grande majorité de notre temps car elles étaient TRÈS gourmandes en main-d’œuvre.

  • AEM 6 a remplacé le référentiel sous-jacent d’Apache Jackrabbit par Apache Oak, ce qui a nécessité une migration à grande échelle.
  • Le clustering actif-actif de CQ n’était plus disponible, bien qu’Adobe ait introduit le backend de stockage MongoMK pour AEM qui pourrait théoriquement (à ce stade, TRÈS THÉORIQUEMENT) fournir des auteurs AEM mis à l’échelle horizontalement. Cependant, c’était extrêmement bogué et notre seule implémentation que nous avons faite s’est soldée par un désastre et un pivot vers un TarMK à auteur unique
  • Encombrement plus important de TouchUI pour la plupart des pages
  • Balises intelligentes pour les ressources

• AEM 6.1 (2015)

  • Beaucoup de corrections de bugs, mais la version 6.1 n’était toujours pas une version particulièrement stable.
  • La prise en charge des URL personnalisées est apparue dans la version 6.1
  • ContextHub pour la personnalisation
  • SDK d’application mobile
  • AEM Communities est introduit, ainsi qu’une multitude d’options d’infrastructure et de stockage pour le contenu généré par l’utilisateur. Des améliorations seront apportées au fil du temps, mais il ne survit malheureusement pas au passage au service cloud.
  • L’application de bureau AEM a été publiée pour la version 6.1, j’ai réussi à DDoS à 100 % un environnement de création avec cette application :(

• AEM 6.2 (2016)

  • Beaucoup plus de corrections de bugs et d’améliorations de la stabilité - toujours pas une version particulièrement stable, mais BEAUCOUP mieux que 6.1 ou 6.0.
  • Introduction de fragments de contenu répandus (cela pouvait être fait via le pack de fonctionnalités auparavant, mais fait maintenant partie du produit)
  • Prise en charge de SSL dans AEM
  • L’interface utilisateur change pour s’y habituer maintenant - avec la navigation déplacée vers le haut à partir du rail latéral

• AEM 6.3 (2017)

  • Les composants de base sont présentés comme « prêts pour la production ».
  • D’importantes améliorations du stockage sous-jacent sur la version 6.3 en font enfin la première version d’AEM 6 très stable. Il s’agissait de l’introduction de la datastore et de la segmentstore séparées et d’un mécanisme fiable pour la gestion des versions en ligne (compactage tar).
  • Des fragments d’expérience sont introduits
  • L’éditeur de page unique (SPA) est introduit pour les applications à page unique.
  • « Adobe Sensei » commence à imprégner AEM Assets en tant que marque d’IA d’Adobe, avec ce qui était (à l’époque) des fonctionnalités d’IA assez révolutionnaires. Le recadrage intelligent, le balisage intelligent, etc. ont fait leur chemin dans Assets.

• AEM 6.4 (2018)

  • La version 6.4 a été la première série de « restructuration des dépôts » conçue pour faciliter les mises à niveau et finalement ouvrir la voie à une migration vers le service cloud.
  • Flux de travail déplacés vers TouchUI
  • Un certain nombre d’améliorations apportées aux services de traduction
  • Recadrage intelligent vidéo dans les ressources

• AEM 6.5 (2019)

  • Beaucoup de restructuration des dépôts
  • Les ressources connectées offraient une option potentielle pour connecter des environnements de ressources distantes à un environnement AEM Sites distinct. Ne fonctionne que pour les images.
  • D’énormes améliorations de l’éditeur SPA
  • GraphQL pour le commerce
  • De plus, comme la version 6.5 existe depuis 6 ans (la plus longue version d’AEM/CQ à ce jour !), une tonne de nouvelles fonctionnalités ont été publiées via le Service Pack. Nous en sommes au Service Pack 23 à ce stade, et un récapitulatif de toutes les nouvelles fonctionnalités qui sont sorties depuis 2019 mérite son propre article de blog.

• AEM as a Cloud Service (2020)
  Présenté pour la première fois à adaptTo() 2019 (la plupart d’entre nous ne savaient pas vraiment ce que nous regardions, à ce moment-là !) AEM as a Cloud Service a été lancé en janvier 2020 et aurait occupé le devant de la scène lors de l’Adobe Summit 2020... s’il y avait eu un Adobe Summit en personne en 2020. C’est dommage. AEM as a Cloud Service a été créé pour résoudre un certain nombre de lacunes de longue date d’AEM & CQ et a connu un succès variable à cet égard, ce qui a vraiment abouti au paysage des offres AEM que nous avons aujourd’hui. Ce qu’il offre, c’est :

  • Un environnement AEM basé sur un service complet dans le cloud
  • Mise à l’échelle automatique au niveau de l’auteur et de l’éditeur
  • CDN intégré
  • Capacités de flux de travail et d’ingestion de données massivement mises à jour avec un moteur d’ingestion d’actifs basé sur des microservices
  • De nouvelles capacités de recherche, avec une recherche améliorée par l’IA (basée sur RAG) qui vient d’être publiée et dont on a parlé à adaptTo()

• AEM 6.5 LTS
  Nommée « AEM 6.6 » ou « AEM 6.5 LTS » selon qu’il s’agit d’ingénieurs ou de marketing, la version 6.5 LTS est l’option à long terme pour les personnes qui prévoient de continuer à héberger elles-mêmes ou AMS leurs charges de travail AEM 6.5 après 2025. Java 11 est bientôt en fin de vie, c’est pourquoi l’exécution d’AEM sur Java 17 ou Java 21 est la seule option.
  
  C’est, bien sûr, le dernier VRAI SUCCESSEUR du produit complet sorti en 2009, car de nombreuses parties de celui-ci (i.e. /crx/packmgr et /crx/de et /etc/replication.html et ainsi de suite) sont presque EXACTEMENT les mêmes qu’ils étaient à l’époque de la version originale de CQ5.

• Services de livraison en périphérie et DA
  Quel est l’avenir d’AEM ? On peut dire que le successeur fonctionnel et « spirituel » d’AEM pour l’avenir sera Edge Delivery Services au niveau de la livraison, et Document Authoring au niveau de la gestion du contenu et de l’habilitation de l’auteur. C’est absolument sujet à débat, mais DA présente des arguments très solides pour la direction que prendra AEM sill dans les années à venir.

À propos de l’auteur

Vous aimez ce que vous avez entendu ? Vous avez des questions sur ce qui vous convient le mieux ? Nous serions ravis de discuter ! Contactez-nous

Plus d’articles AEM qui pourraient vous intéresser