Definición de las funciones de trabajo de las implementaciones de AEM
En cualquier implementación de plataforma de experiencia digital de gran tamaño (y ESPECIALMENTE con AEM), hemos superado considerablemente el punto en el que se podría esperar de forma remota que un "webmaster" o un experto en todos los oficios cubra todas las funciones requeridas de manera efectiva. Por lo tanto, se tratan en nuestro episodio de podcast aquí y luego se detallan (y, con suerte, se actualizan periódicamente) a continuación se encuentran las funciones principales de un proyecto de AEM y cuáles son sus responsabilidades y fortalezas. Pero también (y a veces de manera mucho más crítica), ya sea que este sea un rol que generalmente se mantendría en la empresa, o si es uno que normalmente se contrataría con una agencia o proveedor de soluciones.
También disponible en Apple Podcasts y como podcast de audio o video en Spotify.
Un breve resumen de los roles que asumimos en el podcast:
Propietario del producto / Propietario del sitio
El propietario del producto o del sitio es el principal punto de responsabilidad sobre el contenido y la funcionalidad de una implementación, generalmente a nivel de director o de vicepresidente en una empresa. En el caso de los sitios de AEM, por lo general, AEM ejecuta el ".com" de ese negocio. De todas las funciones aquí, es la única que esencialmente nunca se subcontrata a una parte fuera de la empresa.
Tomado en el minuto 7:11 del podcast
AEM Solution Architect (también Multi-Solution Architect)
[Tomado a las 9:45]
Un arquitecto de soluciones es, a diferencia del propietario del producto anterior, casi siempre de un proveedor o agencia. Su trabajo consiste en comprender a fondo el conjunto de problemas, los puntos débiles, los requisitos, el personal, los objetivos, los presupuestos, las habilidades deseadas y los indicadores de éxito de una empresa determinada, y luego diseñar una solución que realmente los cumpla y que pueda ejecutarse. Un arquitecto de soluciones para AEM ya suele ser un arquitecto de AEM que también tiene experiencia en desarrollo, operaciones y las habilidades relacionadas necesarias para diseñar una solución completa que funcione.
Un "arquitecto de soluciones múltiples" termina necesitando ser contratado cuando el problema que se está resolviendo se cruza con varias soluciones discretas, como "AEM y Adobe Experience Platform" o "Sitecore + SAP Commerce" o "AEM Assets + AEM Forms".
Como nota, los arquitectos de soluciones son necesarios para que una buena solución se venda, pero las soluciones tienden a ser superficiales y mal pensadas cuando ese arquitecto de soluciones termina siendo un "vendedor técnico" en lugar de alguien que pasó tiempo de calidad con las manos sucias y tiene una serie de éxitos (y fracasos) en su haber.
También he descubierto que el arquitecto de soluciones debe ser capaz de usar el sombrero de "Búfer de ventas" (discutido en el minuto 11:00) para poder asegurarse de que se compren los productos correctos en el momento adecuado, y no solo porque sonaban llamativos o porque el equipo de ventas de la empresa XYZ dijo "IA" el número correcto de veces en un discurso de venta convincente.
AEM Arquitecto
El AEM Architect es probablemente una de las funciones más difíciles de definir de forma precisa y coherente, ya que las cualidades que un proyecto o equipo necesita en un "AEM Architect" son muy variables. [Ver 15:48] Deben ser capaces de:
- Conozca AEM mejor que la mayoría de los miembros del equipo
- Sobre todo, deben saber todo lo que AEM es capaz de hacer, y también deben saber dónde trazar la línea sobre lo que AEM no es capaz de hacer, o lo que no se debe hacer que haga. La única manera de obtener ESO es la experiencia, y esa experiencia probablemente no debería ser toda una experiencia de "camino feliz". Deberían haber visto a AEM arder en llamas un par de veces.
- Deben tener habilidades blandas para la gestión de proyectos, la gestión de personal, la depuración de personal, y también ser buenos como un "Deflector de Ventas", así como a veces ser un "Acelerador de Ventas" cuando realmente SE NECESITAN adquirir herramientas para que un equipo tenga éxito. [Véase 21:29]
Desarrollador de front-end de AEM y desarrollador de back-end de AEM
Es mucho más fácil de definir, aunque profundizamos en si el desarrollador de FE y BE pueden ser la misma persona, o si tiene sentido dividir estos roles. [25:00]
Desarrollador de AEM Forms
"AEM Forms" no es lo mismo que "formularios realizados en AEM", por muy confuso que sea. AEM Forms es un producto increíble que es una SKU independiente de AEM Sites, y es muy aprovechado por las empresas más grandes para realizar una transformación digital real.
Ingeniero de DevOps de AEM/Administrador de sistemas
El trabajo de realizar la administración y las operaciones del sistema en AEM, ya sea AEM local, Adobe 6.5 o AEM as a Cloud service, es algo que SIEMPRE requiere que alguien con experiencia en AEM trabaje en él. Alguien siempre tiene que encargarse de la supervisión, la fiabilidad, el mantenimiento, la CI/CD, la implementación y el rendimiento, de lo contrario, se producen interrupciones y un sitio web de bajo rendimiento.
Probablemente hemos dedicado más trabajo de lo habitual a discutir este rol en particular, desde las historias de guerra de la administración del sistema en AEM, hasta las discusiones sobre si AEM autohospedado sigue existiendo o no. Simplemente no se puede enfatizar lo suficiente que incluso si cualquier servicio dice que están "completamente administrados", a menos que estén administrando específicamente SU SITIO (lo que generalmente no es el caso), debe asegurarse de que este papel se mantenga adecuadamente.
Temas completos tratados en esta discusión de AEM Roles
- 0:00 - Introducción y audiencias (reclutadores y propietarios de sitios AEM)
- 2:36 - Gestión de proyectos de un sitio que no es de AEM
- 3:24 - Discusión entre los monolitos y los componibles.
- 4:45 - ¿Existe un simple "debo internamente o subcontratar personal de AEM"?
- 7:11 - Función: definir el propietario del sitio o el propietario del producto de AEM
- 9:45 - Función: definición del arquitecto de soluciones o el arquitecto de soluciones de AEM
- 11:00 - El Arquitecto de Soluciones como "Búfer de Ventas"
- 15:00 - Separar los proyectos de "planificación" de "ejecución"
- 15:48 - Función: definición del arquitecto de AEM
- 16:48 - Diferenciando "desarrollador principal" de "arquitecto"
- 18:10 - Las "habilidades blandas" de un arquitecto
- 21:29 - El arquitecto también lleva el sombrero "Deflector de ventas"
- 22:20 - Sobre la consulta a los arquitectos y la necesidad ética de quedarse sin trabajo
- 23:47 - El arquitecto como "Acelerador de Ventas"
- 25:00 - Función: definición del desarrollador de AEM (y front-end frente a back-end)
- 29:05 - Función: Desarrollador de AEM Forms (y transformación digital real)
- 32:09 - Funciones: Desarrollador de AEM Assets y arquitecto de información
- 33:31 - Función: AEM Quality Assurance (QA)
- 36:28 - Rol: AEM Autores
- 39:45 - Rol: AEM Devops / Administrador del sistema AEM
- 44:20 - La máxima del panel de control del sitio web
- 45:50 - La función de DevOps de AEM de garantizar que se adquieran y utilicen las herramientas correctas
- 46:45 - ¿La administración del sistema AEM tiene que ser con experiencia en AEM?
- 48:55 - ¿Tiene que tener operaciones de AEM internas?
- 51:44 - Funciones: Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - ¿Decide si es interno o externo?
Escuche nuestro podcast y póngase en contacto con nosotros si desea analizar cómo los nuevos modelos de infraestructura como este podrían funcionar para su entorno. ¡Por favor, comunícate!
Ponentes de podcast
Tad Reeves
Arquitecto Principal en Arbory Digital
Tad ha estado trabajando con productos de Adobe desde 2010 y tiene una amplia experiencia en infraestructura de sitios web. Desde 1996, ha desempeñado casi todos los roles en la entrega de sitios web, desde la arquitectura de soluciones hasta la gestión de productos, y tiene más de dos décadas de experiencia. Le encanta que Arbory le brinde la oportunidad de brindar soluciones honestas y efectivas, incluso si eso significa desafiar las perspectivas de ventas prevalecientes. Cuando Tad no está trabajando, disfruta del ciclismo de montaña y explorar la naturaleza con su esposa y sus 3 hijos.
Hank Thobe
Director de Ejecución de Negocios en Arbory Digital
Hank obtuvo su certificación de profesional empresarial de AEM en 2022, especializado en interfaz de usuario y flujos de trabajo. Poco después, asumió un papel como contratista en Zaxby's como gerente de proyectos para su equipo de DevOps. En el pasado, ayudó a lanzar una startup tecnológica llamada InstantOrder, que servía a restaurantes familiares con pedidos de comida en línea y puso en marcha su motivación por la innovación. Actualmente, a Hank le gusta ir a la playa, viajar, pasar tiempo en la naturaleza y practicar deportes intramuros.
¿Te gustó lo que escuchaste? ¿Tiene preguntas sobre lo que es adecuado para usted? ¡Nos encantaría hablar! Contáctenos
Más episodios de podcast que te pueden gustar
¿Son todos malos los monolitos? ¿Cuál es la diferencia entre un CMS monolítico, componible y basado en microservicios?
¿Cómo se resuelve el problema constante de la actualización de la caché y la latencia del sistema de back-end en cualquier CMS moderno (especialmente AEM o Edge Delivery?) En este episodio, hablamos con Michał Cukierman, CTO de Dynamic Solutions y cofundador de StreamX , una malla de experiencia digital para acelerar de forma drástica y fiable las complicadas solicitudes de contenido dinámico de los numerosos sistemas constituyentes que componen una implementación moderna de CMS.
No es una hipérbole que si no has hecho un esfuerzo considerable para replantearte la pila de entrega completa de tu sitio en los últimos meses, vas a querer hacerlo. Así que, por favor, deja de leer esto ahora mismo, ponte unos auriculares y saca a pasear este podcast y considera cómo podría afectar a tu entorno.