Double hélice décorative

Définir les fonctions des implémentations AEM

Dans toute mise en œuvre d'une grande plateforme d'expérience numérique (et particulièrement avec AEM), nous avons largement dépassé le stade où l'on pouvait s'attendre à ce qu'un "webmaster" ou un "touche-à-tout" couvre efficacement tous les rôles requis. Les principaux rôles d'un projet AEM, ainsi que leurs responsabilités et leurs points forts, ont été abordés dans notre épisode de podcast ici, puis détaillés (et, nous l'espérons, régulièrement mis à jour) ci-dessous. Mais aussi (et parfois de manière beaucoup plus critique), s'il s'agit d'un rôle que l'on garde généralement en interne ou que l'on confie généralement à une agence ou à un fournisseur de solutions.

Également disponible sur Apple Podcasts et en podcast audio ou vidéo sur Spotify.

Un résumé rapide des rôles que nous assumons dans le podcast :

Product Owner / Site Owner

Le propriétaire du produit ou du site est le principal responsable du contenu et des fonctionnalités d'une mise en œuvre. Il se situe généralement au niveau du directeur ou du vice-président de l'entreprise. Pour les sites AEM, c'est généralement l'AEM qui gère le ".com" de l'entreprise. De toutes les fonctions, c'est la seule qui n' est pratiquement jamais confiée à un tiers extérieur à l'entreprise.

Repris à l'adresse 7:11 dans le podcast

Architecte de solutions AEM (également architecte multi-solutions)

[repris sur 9:45]

Contrairement au propriétaire du produit, l'architecte de solutions est presque toujours issu d'un fournisseur ou d'une agence. Son travail consiste à comprendre en profondeur l'ensemble des problèmes, des points douloureux, des exigences, du personnel, des objectifs, des budgets, des capacités souhaitées et des indicateurs de réussite d'une entreprise donnée, puis à concevoir une solution qui y réponde réellement et qui puisse être mise en œuvre. Un architecte de solutions AEM est généralement un architecte AEM qui possède également de l'expérience en matière de développement et d'exploitation, ainsi que les compétences connexes nécessaires à la conception d'une solution complète qui fonctionne.

Un "architecte multi-solutions" doit être engagé lorsque le problème à résoudre recoupe plusieurs solutions distinctes, comme "AEM et Adobe Experience Platform" ou "Sitecore + SAP Commerce" ou "AEM Assets + AEM Forms".
Pour mémoire, les architectes de solutions sont nécessaires pour vendre une bonne solution, mais les solutions ont tendance à être superficielles et mal pensées lorsque l'architecte de solutions devient un "vendeur technique" au lieu d'une personne qui a passé du temps avec les mains sales et qui a un certain nombre de succès (et d'échecs) à son actif.

J'ai également constaté que l'architecte de solutions doit être capable de porter la casquette de "Sales Buffer" (voir 11:00) pour s'assurer que les bons produits sont achetés au bon moment, et pas seulement parce qu'ils ont l'air tape-à-l'œil ou parce que l'équipe de vente de la société XYZ a dit "AI" le bon nombre de fois dans un argumentaire convaincant.

Architecte AEM

L'architecte AEM est probablement l'un des rôles les plus difficiles à définir de manière précise et cohérente, car les qualités dont un projet ou une équipe a besoin chez un "architecte AEM" sont très variables. [Voir 15:48] Ils doivent être capables de.. :

Développeur AEM Front-End & Développeur AEM Back-End

Il est beaucoup plus facile à définir, même si nous nous demandons si le développeur FE et le développeur BE peuvent être la même personne ou s'il est judicieux de séparer ces rôles. [25:00]

Développeur de formulaires AEM

Les "formulaires AEM" ne sont pas du tout la même chose que les "formulaires réalisés sur AEM", aussi déroutant que cela puisse être. AEM Forms est un produit extraordinaire qui est un SKU séparé d'AEM Sites, et qui est fortement utilisé par les grandes entreprises pour faire real-deal digital transformation.

AEM Devops Engineer / Sysadmin

L'administration et l'exploitation du système AEM - qu'il s'agisse d'AEM sur site, d'Adobe-managed 6.5 ou d'AEM en tant que service Cloud - nécessitent TOUJOURS l'intervention d'une personne expérimentée dans le domaine de l'AEM. Quelqu'un doit toujours porter les chapeaux de la surveillance, de la fiabilité, de la maintenance, du CI/CD, du déploiement et de la performance - sans quoi vous obtenez des pannes et un site web peu performant.

Nous avons probablement consacré plus d'efforts que d'habitude à la discussion de ce rôle particulier, qu'il s'agisse des récits de guerre sur l'administration du système AEM ou des discussions sur la question de savoir si l'AEM auto-hébergé existe toujours. On ne saurait trop insister sur le fait que, même si un service dit être "entièrement géré", à moins qu'il ne gère spécifiquement VOTRE SITE (ce qui n'est généralement pas le cas), vous devez vous assurer que ce rôle est assumé de manière adéquate.

Tous les sujets abordés dans cette discussion sur les rôles de l'AEM

N'hésitez pas à écouter notre podcast et à nous contacter si vous souhaitez discuter de la manière dont de nouveaux modèles d'infrastructure tels que celui-ci pourraient s'appliquer à votre environnement ! N'hésitez pas à nous contacter !

Intervenants en podcast

Tad Reeves

Architecte principal chez Arbory Digital

Tad travaille avec les produits Adobe depuis 2010 et possède une grande expérience dans l'infrastructure des sites web. Depuis 1996, il a porté presque toutes les casquettes de la fourniture de sites web, de l'architecture des solutions à la gestion des produits, et possède plus de vingt ans d'expérience. Il aime le fait qu'Arbory lui donne la possibilité de fournir des solutions honnêtes et efficaces, même si cela implique de remettre en question les perspectives commerciales dominantes. Quand Tad ne travaille pas, il aime faire du VTT et explorer la nature avec sa femme & et ses trois enfants.

Contacter Tad sur Linkedin

Hank Thobe

Directeur de l'exécution commerciale chez Arbory Digital

Hank a obtenu sa certification de praticien d'affaires AEM en 2022, se spécialisant dans l'interface utilisateur et les flux de travail. Peu après, il a accepté un rôle d'entrepreneur chez Zaxby's en tant que chef de projet pour leur équipe DevOps. Dans le passé, il a participé au lancement d'une startup technologique appelée InstantOrder, qui a permis à des restaurants familiaux de commander des repas en ligne et qui a donné le coup d'envoi à sa motivation pour l'innovation. Actuellement, Hank aime aller à la plage, voyager, passer du temps dans la nature et pratiquer des sports intra-muros.

Contacter Hank sur LinkedIn

Vous avez aimé ce que vous avez entendu ? Vous avez des questions sur ce qui vous convient le mieux ? Nous aimerions en parler ! Contact avec nous

Plus d'épisodes de podcast que vous pourriez aimer

CMS monolithiques vs composables vs microservices - Quel est le bon outil pour le travail ?
Les monolithes sont-ils tous mauvais ? Quelle est la différence entre un CMS monolithique, composable et basé sur des microservices ?
Faire en sorte qu'AEM & Edge Delivery devienne CRAZY FAST - Entretien avec le co-fondateur de StreamX
Comment résoudre le problème constant de la fraîcheur du cache et de la latence du système backend dans n'importe quel CMS moderne (en particulier AEM ou Edge Delivery) ? Dans cet épisode, nous nous entretenons avec Michał Cukierman, directeur technique de Dynamic Solutions et cofondateur de StreamX - un maillage de l'expérience numérique permettant d'accélérer de manière spectaculaire et fiable les demandes de contenu dynamique compliquées provenant des nombreux systèmes constitutifs d'un déploiement CMS moderne.
Sommet Adobe 2024 : Perturbation de l'architecture AEM
Il n'est pas exagéré de dire que si vous n'avez pas déployé des efforts considérables pour repenser l'ensemble de la pile de diffusion de votre site au cours des derniers mois, vous allez vouloir le faire. Alors, s'il vous plaît, arrêtez de lire ceci maintenant, mettez des écouteurs, promenez-vous avec ce podcast et réfléchissez à l'impact qu'il pourrait avoir sur votre environnement !