Définition des rôles de travail des implémentations AEM
Dans toute mise en œuvre d'une plateforme d'expérience numérique de grande envergure (et SURTOUT avec AEM), nous avons largement dépassé le point où l'on pourrait s'attendre à ce qu'un « webmaster » ou un touche-à-tout assume efficacement tous les rôles requis. Ainsi, dans notre épisode de podcast ici, puis détaillés (et, espérons-le, régulièrement mis à jour) ci-dessous, se trouvent les principaux rôles d'un projet AEM, ainsi que leurs responsabilités et leurs points forts. 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 sous-traite généralement à une agence ou à un fournisseur de solutions.
Également disponible sur Apple Podcasts et sous forme de podcast audio ou vidéo sur Spotify .
Un bref résumé des rôles que nous assumons dans le podcast :
Propriétaire du produit / Propriétaire du site
Le propriétaire du produit ou le propriétaire du site est le principal responsable du contenu et des fonctionnalités d'une implémentation, généralement au niveau de directeur ou de vice-président d'une entreprise. Pour les sites AEM, AEM gère généralement le « .com » de cette entreprise. De tous les rôles ici, c'est le seul qui n'est pratiquement jamais sous-traité à une partie extérieure à l'entreprise.
Repris à 7:11 dans le podcast
Architecte de solutions AEM (également architecte multi-solutions)
[reprise à 9h45 ]
Contrairement au propriétaire de produit ci-dessus, un 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 difficultés, 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 répond réellement à ces besoins et qui peut être exécutée. Un architecte de solutions pour AEM est généralement déjà un architecte AEM qui possède également de l'expérience en développement, en opérations et les compétences connexes nécessaires pour concevoir une solution complète qui fonctionne.
Il devient nécessaire de faire appel à un « architecte multi-solutions » lorsque le problème à résoudre concerne plusieurs solutions distinctes, comme « AEM et Adobe Experience Platform » ou « Sitecore + SAP Commerce » ou « AEM Assets + AEM Forms ».
Remarque : les architectes de solutions sont nécessaires pour qu'une bonne solution soit vendue, mais les solutions ont tendance à être superficielles et mal pensées lorsque cet architecte de solutions finit par être un « vendeur technique » au lieu de quelqu'un qui a passé du temps de qualité 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 le chapeau de « tampon de vente » (discuté à 11h00 ) pour pouvoir s'assurer que les bons produits sont achetés au bon moment, et pas seulement parce qu'ils semblaient tape-à-l'œil ou parce que l'équipe de vente de la société XYZ a dit « IA » le bon nombre de fois dans un argumentaire de vente convaincant.
Architecte AEM
L’architecte AEM est probablement l’un des rôles les plus difficiles à définir avec précision et cohérence, 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 :
- Connaître AEM mieux que la plupart des membres de l'équipe
- Surtout, ils devraient savoir tout ce dont AEM est capable, et ils devraient également savoir où tracer la ligne sur ce dont AEM n'est pas capable , ou ce qu'il ne devrait pas être amené à faire. La seule façon d'y parvenir est de vivre, et cette expérience ne devrait probablement pas être uniquement une expérience du « chemin heureux ». Ils auraient dû voir AEM partir en fumée plusieurs fois.
- Ils doivent avoir des compétences générales en matière de gestion de projet, de gestion du personnel, de débogage du personnel, et également être bons en tant que « déflecteur de ventes » ainsi que parfois en tant qu'« accélérateur de ventes » lorsque les outils DOIVENT vraiment être acquis pour qu'une équipe réussisse. [Voir 21:29 ]
Développeur Front-End AEM et Développeur Back-End AEM
Beaucoup plus facile à définir, même si nous examinons 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
« AEM Forms » n'est pas du tout la même chose que « formulaires créés sur AEM », même si cela peut être déroutant. AEM Forms est un produit incroyable qui est un SKU distinct d'AEM Sites et qui est largement utilisé par les grandes entreprises pour réaliser une véritable transformation numérique .
Ingénieur DevOps AEM / Administrateur système
L'administration et les opérations système sur AEM (qu'il s'agisse d'AEM sur site, d'AEM 6.5 géré par Adobe ou d'AEM en tant que service Cloud) nécessitent TOUJOURS la présence d'une personne expérimentée dans AEM. Quelqu'un doit toujours assumer les fonctions de surveillance, de fiabilité, de maintenance, de CI/CD, de déploiement et de performances, sinon vous vous retrouvez avec des pannes et un site Web peu performant.
Nous avons probablement consacré plus de temps que d'habitude à discuter de ce rôle particulier, des récits de guerre sur l'administration système sur AEM aux discussions sur la question de savoir si l'auto-hébergement d'AEM est toujours d'actualité . On ne saurait trop insister sur le fait que même si un service indique qu'il est « 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 correctement tenu.
Sujets complets abordés dans cette discussion sur les rôles AEM
- 0:00 - Présentation et publics (recruteurs et propriétaires de sites AEM)
- 2:36 - Gestion de projet d'un site non-AEM
- 3:24 - Discussion sur les monolithes et les composables
- 4:45 - Existe-t-il une solution simple : « Dois-je faire appel à moi-même ou sous-traiter le personnel d'AEM » ?
- 7:11 - Rôle : définition du propriétaire du site AEM ou du propriétaire du produit
- 9h45 - Rôle : définition de l'architecte de solutions ou de l'architecte de solutions AEM
- 11h00 - L'architecte de solutions comme « tampon de vente »
- 15h00 - Séparer la « planification » des « projets de mise en œuvre »
- 15:48 - Rôle : définir l'architecte AEM
- 16:48 - Différencier « développeur principal » et « architecte »
- 18h10 - Les « soft skills » d'un architecte
- 21:29 - L'architecte porte également le chapeau de « déflecteur de ventes »
- 22:20 - Sur les conseils aux architectes et la nécessité éthique de se retirer de son emploi
- 23:47 - L'architecte comme « accélérateur de ventes »
- 25h00 - Rôle : définition du développeur AEM (et front-end vs back-end)
- 29:05 - Rôle : Développeur de formulaires AEM (et véritable transformation numérique)
- 32:09 - Rôles : Développeur d'actifs AEM et architecte de l'information
- 33:31 - Rôle : Assurance qualité AEM (AQ)
- 36:28 - Rôle : Auteurs AEM
- 39:45 - Rôle : AEM Devops / Administrateur système AEM
- 44:20 - La maxime du tableau de bord d'un site Web
- 45:50 - Le rôle de DevOps d'AEM consiste à garantir que les bons outils sont achetés et utilisés
- 46:45 - L'administration du système AEM doit-elle être expérimentée avec AEM
- 48:55 - Devez-vous avoir des opérations AEM en interne ?
- 51:44 - Rôles : Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - Choisir entre l'interne ou l'externalisation ?
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 comme celui-ci pourraient fonctionner pour votre environnement ! N'hésitez pas à nous contacter !
Intervenants du podcast
Tad Reeves
Architecte principal chez Arbory Digital
Tad travaille avec les produits Adobe depuis 2010 et possède une vaste expérience dans l'infrastructure des sites Web. Depuis 1996, il a occupé presque tous les postes dans la conception de sites Web, de l'architecture de solutions à la gestion de produits, et possède plus de deux décennies d'expérience. Il apprécie le fait qu'Arbory lui donne l'opportunité de fournir des solutions honnêtes et efficaces, même si cela signifie remettre en question les perspectives de vente en vigueur. Lorsque Tad ne travaille pas, il aime faire du VTT et explorer la nature avec sa femme et ses trois enfants.
Hank Thobe
Directeur de l'exécution des activités chez Arbory Digital
Hank a obtenu sa certification de praticien commercial AEM en 2022, spécialisé dans l'interface utilisateur et les flux de travail. Peu de temps après, il a assumé un rôle de sous-traitant chez Zaxby's en tant que chef de projet pour leur équipe DevOps. Dans le passé, il a contribué au lancement d'une startup technologique appelée InstantOrder, qui proposait aux restaurants familiaux un service de commande de nourriture en ligne et a donné le coup de fouet à sa motivation pour l'innovation. Actuellement, Hank aime aller à la plage, voyager, passer du temps dans la nature et pratiquer des sports intra-muros.
Vous avez aimé ce que vous avez entendu ? Vous avez des questions sur ce qui vous convient ? Nous serions ravis d'en parler ! Contactez-nous
Autres épisodes de podcast que vous pourriez aimer
Les monolithes sont-ils tous mauvais ? Quelle est la différence entre un CMS monolithique, composable et basé sur des microservices ?
Comment résoudre le problème constant de la fraîcheur du cache et de la latence du système back-end dans tout CMS moderne (en particulier AEM ou Edge Delivery ?) Dans cet épisode, nous discutons avec Michał Cukierman, CTO de Dynamic Solutions et co-fondateur de StreamX - un maillage d'expérience numérique permettant d'accélérer de manière spectaculaire et fiable les demandes de contenu dynamique complexes provenant des nombreux systèmes constitutifs qui composent un déploiement CMS moderne.
Ce n'est pas une exagération de dire que si vous n'avez pas fait d'efforts considérables pour repenser l'ensemble de votre pile de diffusion de site au cours des derniers mois, vous allez vouloir le faire. Alors s'il vous plaît, arrêtez de lire ceci tout de suite, mettez des écouteurs et écoutez ce podcast et réfléchissez à la façon dont il pourrait affecter votre environnement !