Definindo as funções de trabalho das implementações do AEM
Em qualquer grande implementação de plataforma de experiência digital (especialmente com o AEM), já ultrapassamos consideravelmente o ponto em que se poderia esperar que um “webmaster” ou um pau para toda obra desempenhasse remotamente todas as funções necessárias de forma eficaz. Então, abordados em nosso episódio de podcast aqui e, em seguida, detalhados (e esperamos que sejam atualizados regularmente) abaixo estão as principais funções de um projeto de AEM e quais são suas responsabilidades e pontos fortes. Mas também (e às vezes de forma muito mais crítica), seja essa uma função que geralmente se manteria internamente ou uma que você normalmente contrataria com uma agência ou fornecedor de soluções.
Também disponível no Apple Podcasts e como podcast de áudio ou vídeo no Spotify.
Um rápido resumo das funções que assumimos no podcast:
Proprietário do produto/proprietário do site
O proprietário do produto ou do site é o principal ponto de responsabilidade sobre o conteúdo e a funcionalidade de uma implementação, geralmente no nível de diretor ou vice-presidente de uma empresa. Para sites do AEM, geralmente o AEM está executando o “.com” dessa empresa. De todas as funções aqui, é a única que essencialmente nunca é terceirizada para uma parte fora da empresa.
Retirado às 7:11 no podcast
Arquiteto de soluções AEM (também arquiteto de várias soluções)
[retomada às 9:45]
Um arquiteto de soluções é, ao contrário do proprietário do produto acima, quase sempre de um fornecedor ou agência. Seu trabalho é entender completamente o conjunto de problemas, pontos problemáticos, requisitos, pessoal, metas, orçamentos, habilidades desejadas e indicadores de sucesso para uma determinada empresa e, em seguida, projetar uma solução que realmente os atenda e que possa ser executada. Normalmente, um arquiteto de soluções do AEM já é um arquiteto do AEM que também tem experiência em desenvolvimento, operações e as habilidades relacionadas necessárias para projetar uma solução completa que funcione.
Um “arquiteto de várias soluções” acaba precisando se envolver quando o problema que está sendo resolvido passa por várias soluções distintas, como “AEM e Adobe Experience Platform” ou “Sitecore + SAP Commerce” ou “AEM Assets + AEM Forms”.
Como nota, arquitetos de soluções são necessários para que uma boa solução seja vendida, mas as soluções tendem a ser superficiais e mal pensadas quando esse arquiteto de soluções acaba sendo um “vendedor técnico” em vez de alguém que passa bons momentos com as mãos sujas e tem vários sucessos (e fracassos) em seu currículo.
Também descobri que o arquiteto de soluções precisa ser capaz de usar o chapéu de “Sales Buffer” (discutido às 11h) para garantir que os produtos certos sejam comprados na hora certa, e não apenas porque soaram chamativos ou porque a equipe de vendas da empresa XYZ disse “IA” o número correto de vezes em um discurso de vendas convincente.
Arquiteto do AEM
O AEM Architect é provavelmente uma das funções mais difíceis de definir com precisão e consistência, pois as qualidades que um projeto ou equipe precisa em um “Arquiteto AEM” são altamente variáveis. [Ver 15:48] Eles precisam ser capazes de:
- Conheça o AEM melhor do que a maioria das pessoas da equipe
- Acima de tudo, eles devem saber tudo de que o AEM é capaz e também saber onde definir o limite do que o AEM não é capaz ou do que não deve ser feito para fazer. A única maneira de obter ISSO é com a experiência, e essa experiência provavelmente não deveria ser toda uma experiência de “caminho feliz”. Eles deveriam ter visto o AEM pegar fogo algumas vezes.
- Eles devem ter habilidades sociais para gerenciamento de projetos, gerenciamento de pessoal, depuração de pessoal e também ser bons como “defletores de vendas”, além de, às vezes, serem “aceleradores de vendas” quando as ferramentas realmente PRECISAM ser adquiridas para que uma equipe tenha sucesso. [Ver 21:29]
Desenvolvedor de front-end do AEM & Desenvolvedor de back-end do AEM
Muito mais fácil de definir, mas investigamos se o desenvolvedor do FE e do BE podem ser a mesma pessoa ou se faz sentido dividir essas funções. [25:00]
Desenvolvedor de formulários do AEM
“Formulários do AEM” não é praticamente o mesmo que “formulários feitos no AEM”, por mais que isso seja absolutamente confuso. O AEM Forms é um produto incrível que é um SKU separado do AEM Sites e é altamente utilizado por empresas maiores para realizar uma transformação digital real de forma completa.
Engenheiro de DevOps do AEM//Administrador de sistemas
O trabalho de administrar e operar o sistema no AEM, seja o AEM local, o 6.5 gerenciado pela Adobe ou o AEM como um serviço em nuvem, é algo que SEMPRE exige que alguém com experiência em AEM trabalhe nele. Alguém sempre precisa usar os chapéus de monitoramento, confiabilidade, manutenção, CI/CD, implantação e desempenho. Caso contrário, você terá interrupções e um site com baixo desempenho.
Provavelmente, nos esforçamos mais do que o normal para discutir essa função específica, desde as histórias de guerra da administração do sistema no AEM até as discussões sobre se o AEM auto-hospedado ainda existe. Nunca é demais enfatizar que, mesmo que algum serviço diga que é “totalmente gerenciado”, a menos que esteja gerenciando especificamente SEU SITE (o que geralmente não é o caso), você precisa garantir que essa função seja desempenhada adequadamente.
Tópicos completos abordados nesta discussão sobre funções do AEM
- 0:00 - Introdução & Audiences (recrutadores & proprietários de sites do AEM)
- 2:36 - Gerenciamento de projetos em um site que não seja do AEM
- 3:24 - A discussão entre monólitos e compostos
- 4:45 - Existe um " simples: devo internamente ou terceirizar o pessoal " do AEM?
- 7:11 - Função: definir o proprietário do site ou o proprietário do produto do AEM
- 9:45 - Função: definir o arquiteto de soluções ou o arquiteto de soluções do AEM
- 11:00 - O arquiteto de soluções como " Sales Buffer "
- 15:00 - Separando o planejamento " " dos projetos de implementação "
- 15:48 - Função: definir o arquiteto do AEM
- 16:48 - Diferenciando o desenvolvedor líder " " do " architect "
- 18:10 - As habilidades sociais " " de um arquiteto
- 21:29 - O arquiteto também usa o chapéu " Sales Deflector "
- 22:20 - Sobre a consultoria de arquitetos &, a necessidade ética de se livrar do emprego
- 23:47 - O arquiteto como acelerador de vendas " "
- 25:00 - Função: definir o desenvolvedor do AEM (e front-end versus back-end)
- 29:05 - Função: Desenvolvedor de formulários do AEM (e transformação digital real)
- 32:09 - Funções: Arquiteto de informações do AEM Assets Developer &
- 33:31 - Função: AEM Quality Assurance (QA)
- 36:28 - Função: Autores do AEM
- 39:45 - Função: AEM Devops/administrador do sistema AEM
- 44:20 - A máxima do painel de controle de sites
- 45:50 - O papel do AEM DevOps de garantir que as ferramentas certas sejam adquiridas & used
- 46:45 - A administração do sistema AEM precisa ter experiência com o AEM?
- 48:55 - Você precisa ter operações do AEM internamente?
- 51:44 - Funções: Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - Decidindo internamente ou terceirizando?
Ouça nosso podcast e entre em contato se quiser discutir como novos modelos de infraestrutura como esse podem funcionar em seu ambiente! Por favor, entre em contato!
Palestrantes de podcast
Tad Reeves
Arquiteto principal da Arbory Digital
Tad trabalha com produtos da Adobe desde 2010 e tem uma vasta experiência em infraestrutura de sites. A partir de 1996, ele usou quase todos os chapéus na entrega de sites, desde a arquitetura da solução até o gerenciamento de produtos, e tem mais de duas décadas de experiência. Ele adora que a Arbory lhe dê a oportunidade de fornecer soluções honestas e eficazes, mesmo que isso signifique desafiar as perspectivas de vendas vigentes. Quando Tad não está trabalhando, ele gosta de andar de mountain bike e explorar a natureza com sua esposa & 3 filhos.
Hank Thobe
Diretor de Execução de Negócios da Arbory Digital
Hank obteve sua certificação de profissional de negócios da AEM em 2022, com especialização em UI e fluxos de trabalho. Logo depois, ele assumiu o cargo de prestador de serviços na Zaxby's como gerente de projetos da equipe de DevOps. No passado, ele ajudou a lançar uma startup de tecnologia chamada InstantOrder, que servia restaurantes familiares com pedidos de comida on-line e deu início à sua motivação para a inovação. Atualmente, Hank gosta de ir à praia, viajar, passar tempo na natureza e praticar esportes internos.
Gostou do que você ouviu? Tem dúvidas sobre o que é certo para você? Adoraríamos conversar! Entre em contato conosco
Mais episódios de podcast que você talvez goste
Todos os monólitos são ruins? Qual é a diferença entre um CMS monolítico, componível e baseado em microsserviços?
Como você resolve o problema constante de atualização do cache e latência do sistema de back-end em qualquer CMS moderno (especialmente AEM ou Edge Delivery?) Neste episódio, conversamos com Michał Cukierman, CTO da Dynamic Solutions e cofundador da StreamX — uma malha de experiência digital para acelerar de forma dramática e confiável solicitações complicadas de conteúdo dinâmico dos muitos sistemas constituintes que compõem uma implantação moderna de CMS.
Não é exagero que, se você não se esforçou consideravelmente para repensar sua pilha completa de entrega de sites nos últimos meses, queira fazê-lo. Então, por favor, pare de ler isso agora mesmo, coloque alguns fones de ouvido e leve este podcast para passear e considere como isso pode afetar seu ambiente!