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.. :
- Connaître AEM mieux que la plupart des membres de l'équipe
- Avant tout, ils doivent savoir tout ce dont l'AEM est capable, et également savoir où se situe la limite de ce que l'AEM n' est pas capable de faire, ou de ce qu'il ne faut pas lui faire faire. La seule façon d'obtenir cela est l'expérience, et cette expérience ne devrait probablement pas être une expérience de "chemin heureux". Ils auraient dû voir AEM s'enflammer à plusieurs reprises.
- Ils doivent posséder des compétences non techniques en matière de gestion de projet, de gestion du personnel, de débogage du personnel et être capables de jouer le rôle de "déflecteur de ventes" et parfois d'"accélérateur de ventes" lorsque des outils doivent vraiment être acquis pour qu'une équipe réussisse. [Voir 21:29]
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
- 0:00 - Intro & Audiences (recruteurs & propriétaires de sites AEM)
- 2:36 - Gestion d'un projet sur un site non-AEM
- 3:24 - La discussion sur les monolithes et les composables
- 4:45 - Existe-t-il une solution simple "? Dois-je faire appel au personnel de l'AEM en interne ou en externe"?
- 7:11 - Rôle : définir le propriétaire du site AEM ou le propriétaire du produit
- 9:45 - Rôle : définir l'architecte de solutions ou l'architecte de solutions AEM
- 11:00 - L'architecte de solutions : "Sales Buffer"
- 15:00 - Séparer les projets de planification "" des projets de mise en œuvre "
- 15:48 - Rôle : définir l'architecte AEM
- 16:48 - Différencier "lead developer" de "architect"
- 18:10 - Les "soft skills" d'un architecte
- 21:29 - L'architecte porte également le chapeau "Sales Deflector"
- 22:20 - Sur les architectes-conseils & la nécessité éthique de se mettre au chômage
- 23:47 - L'architecte en tant que "Accélérateur de ventes"
- 25:00 - Rôle : définir le développeur AEM (et la distinction entre front-end et back-end)
- 29:05 - Rôle : Développeur de formulaires AEM (et véritable transformateur numérique)
- 32:09 - Rôles : Développeur d'actifs AEM & Architecte de l'information
- 33:31 - Rôle : Assurance qualité AEM (QA)
- 36:28 - Rôle : Auteurs de l'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 l'AEM devops qui consiste à s'assurer que les bons outils sont achetés & utilisés
- 46:45 - L'administration du système AEM doit-elle être expérimentée ?
- 48:55 - Est-il nécessaire d'avoir des opérations AEM en interne ?
- 51:44 - Rôles : Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - Décider de l'internalisation ou de 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 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.
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.
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
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 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.
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 !