Definizione dei ruoli professionali delle implementazioni AEM
In qualsiasi implementazione di una piattaforma di esperienza digitale di grandi dimensioni (e SOPRATTUTTO con AEM), abbiamo superato considerevolmente il punto in cui ci si poteva aspettare che un "webmaster" o un tuttofare coprisse tutti i ruoli richiesti in modo efficace. Quindi, trattati nel nostro episodio del podcast qui e poi dettagliati (e si spera regolarmente aggiornati) di seguito sono i ruoli principali di un progetto AEM e quali sono le loro responsabilità e punti di forza. Ma anche (e a volte in modo molto più critico), se si tratta di un ruolo che generalmente si manterrebbe all'interno dell'azienda o di un ruolo per cui si stipula un contratto con un'agenzia o un fornitore di soluzioni.
Disponibile anche su Apple Podcasts e come podcast audio o video su Spotify.
Un breve riassunto dei ruoli che assumiamo nel podcast:
Proprietario del prodotto / Proprietario del sito
Il proprietario del prodotto o del sito è il principale responsabile del contenuto e delle funzionalità di un'implementazione, in genere a livello di direttore o di vicepresidente di un'azienda. Per i siti AEM, in genere AEM esegue il ".com" di tale attività. Di tutti i ruoli qui, è l'unico che essenzialmente non viene mai esternalizzato a una parte esterna all'azienda.
Ripreso al minuto 7:11 del podcast
Architetto di soluzioni AEM (anche Architetto di più soluzioni)
[ripreso al minuto 9:45]
Un architetto di soluzioni, a differenza del proprietario del prodotto di cui sopra, proviene quasi sempre da un fornitore o da un'agenzia. Il loro compito è quello di comprendere a fondo l'insieme di problemi, i punti deboli, i requisiti, il personale, gli obiettivi, i budget, le capacità desiderate e gli indicatori di successo per una determinata azienda, e quindi progettare una soluzione che li soddisfi effettivamente e che possa essere eseguita. Un architetto di soluzioni per AEM è già in genere un architetto AEM che ha anche esperienza nello sviluppo, nelle operazioni e nelle competenze correlate necessarie per progettare un'intera soluzione che funzioni.
Un "architetto multi-soluzione" finisce per dover essere coinvolto quando il problema da risolvere si incrocia con più soluzioni discrete, come "AEM e Adobe Experience Platform" o "Sitecore + SAP Commerce" o "AEM Assets + AEM Forms".
Come nota, gli architetti delle soluzioni sono necessari per vendere una buona soluzione, ma le soluzioni tendono ad essere superficiali e mal ponderate quando l'architetto delle soluzioni finisce per essere un "venditore tecnico" invece di qualcuno che ha trascorso del tempo di qualità con le mani sporche e ha una serie di successi (e fallimenti) alle spalle.
Ho anche scoperto che il Solution Architect deve essere in grado di indossare il cappello di "Sales Buffer" (discusso al minuto 11:00) per essere in grado di assicurarsi che i prodotti giusti vengano acquistati al momento giusto, e non solo perché sembravano appariscenti o perché il team di vendita dell'azienda XYZ ha detto "AI" il numero corretto di volte in una presentazione di vendita convincente.
Architetto AEM
L'architetto AEM è probabilmente uno dei ruoli più difficili da definire in modo accurato e coerente, poiché le qualità di cui un progetto o un team ha bisogno in un "architetto AEM" sono molto variabili. [Vedi 15:48] Devono essere in grado di:
- Conosci AEM meglio di chiunque altro nel team
- Soprattutto, dovrebbero sapere tutto ciò di cui AEM è capace, e dovrebbero anche sapere dove tracciare la linea su ciò di cui AEM non è capace, o su ciò che non dovrebbe essere fatto per fare. L'unico modo per ottenere QUESTO è l'esperienza, e quell'esperienza probabilmente non dovrebbe essere tutta un'esperienza di "percorso felice". Avrebbero dovuto vedere AEM andare in fiamme un paio di volte.
- Dovrebbero avere competenze trasversali per la gestione dei progetti, la gestione del personale, il debug del personale ed essere anche bravi come "deflettore di vendite" e talvolta essere un "acceleratore di vendite" quando gli strumenti devono davvero essere acquisiti affinché un team abbia successo. [Vedi 21:29]
Sviluppatore front-end AEM e sviluppatore back-end AEM
Molto più facile da definire, anche se ci addentriamo nel capire se lo sviluppatore FE e quello BE possono essere la stessa persona o se ha senso dividere questi ruoli. [25:00]
Sviluppatore AEM Forms
"AEM Forms" non è la stessa cosa di "moduli eseguiti su AEM", per quanto possa essere assolutamente confuso. AEM Forms è un prodotto straordinario che è uno SKU separato da AEM Sites ed è fortemente sfruttato dalle aziende più grandi per eseguire una trasformazione digitale reale.
Ingegnere DevOps AEM / Amministratore di sistema
Il lavoro di amministrazione e operazioni di sistema su AEM, che si tratti di AEM on-premise, 6.5 gestito da Adobe o AEM as a Cloud service, è qualcosa che richiede SEMPRE qualcuno con esperienza AEM che ci lavori. Qualcuno deve sempre indossare i cappelli del monitoraggio, dell'affidabilità, della manutenzione, del CI/CD, dell'implementazione e delle prestazioni, altrimenti si verificano interruzioni e un sito Web con prestazioni scadenti.
Probabilmente abbiamo lavorato più del solito per discutere di questo particolare ruolo, dalle storie di guerra sull'amministrazione del sistema su AEM, alle discussioni sul fatto che l'AEM self-hosted sia ancora una cosa. Non si sottolineerà mai abbastanza che anche se un servizio dice che sono "completamente gestiti", a meno che non stiano gestendo specificamente il TUO SITO (il che generalmente non è il caso), è necessario assicurarsi che questo ruolo sia adeguatamente ricoperto.
Argomenti completi trattati in questa discussione sui ruoli AEM
- 0:00 - Introduzione e pubblico (reclutatori e proprietari di siti AEM)
- 2:36 - Gestione di un sito non AEM
- 3:24 - Discussione tra Monoliti e Composable
- 4:45 - Esiste un semplice "dovrei internalizzare o esternalizzare il personale AEM"?
- 7:11 - Ruolo: definizione del proprietario del sito AEM o del proprietario del prodotto
- 9:45 - Ruolo: definizione dell'architetto della soluzione o dell'architetto della soluzione AEM
- 11:00 - L'architetto della soluzione come "buffer di vendita"
- 15:00 - Separare la "pianificazione" dai "progetti di attuazione"
- 15:48 - Ruolo: definizione dell'architetto AEM
- 16:48 - Differenziazione di "sviluppatore principale" da "architetto"
- 18:10 - Le "soft skills" di un Architetto
- 21:29 - L'architetto indossa anche il cappello "Sales Deflector"
- 22:20 - Sulla consulenza agli architetti e la necessità etica di lavorare senza lavoro
- 23:47 - L'architetto come "acceleratore di vendite"
- 25:00 - Ruolo: definizione dello sviluppatore AEM (e front-end vs back-end)
- 29:05 - Ruolo: Sviluppatore AEM Forms (e trasformazione digitale reale)
- 32:09 - Ruoli: Sviluppatore AEM Assets e architetto delle informazioni
- 33:31 - Ruolo: Garanzia qualità AEM (QA)
- 36:28 - Ruolo: Autori AEM
- 39:45 - Ruolo: AEM DevOps / Amministratore di sistema AEM
- 44:20 - La massima del dashboarding del sito web
- 45:50 - Il ruolo di AEM devops per garantire l'acquisto e l'utilizzo degli strumenti corretti
- 46:45 - L'amministrazione del sistema AEM deve avere esperienza AEM
- 48:55 - È necessario disporre di AEM ops in-house?
- 51:44 - Ruoli: Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - Decidere se in-house o outsource?
Ascolta il nostro podcast e contattaci se desideri discutere di come nuovi modelli di infrastruttura come questo potrebbero funzionare per il tuo ambiente! Per favore, contattaci!
Relatori per podcast
Tad Reeves
Architetto principale presso Arbory Digital
Tad lavora con i prodotti Adobe dal 2010 e ha una vasta esperienza nell'infrastruttura dei siti web. A partire dal 1996, ha indossato quasi tutti i cappelli nella distribuzione di siti Web, dall'architettura delle soluzioni alla gestione dei prodotti, e ha oltre due decenni di esperienza. Ama il fatto che Arbory gli dia l'opportunità di fornire soluzioni oneste ed efficaci, anche se ciò significa sfidare le prospettive di vendita prevalenti. Quando Tad non lavora, gli piace andare in mountain bike ed esplorare la natura con sua moglie e i suoi 3 figli.
Hank Thobe
Direttore dell'esecuzione aziendale presso Arbory Digital
Hank ha conseguito la certificazione AEM Business Practitioner nel 2022, specializzandosi in interfaccia utente e flussi di lavoro. Poco dopo, ha assunto un ruolo come appaltatore con Zaxby's come project manager per il loro team DevOps. In passato, ha contribuito a lanciare una startup tecnologica chiamata InstantOrder, che serviva ristoranti a conduzione familiare con ordinazioni di cibo online e ha dato il via alla sua motivazione per l'innovazione. Attualmente, Hank ama andare in spiaggia, viaggiare, trascorrere del tempo nella natura e praticare sport intramurali.
Ti piace quello che hai sentito? Hai domande su cosa è giusto per te? Ci piacerebbe parlare! Contattaci
Altri episodi di podcast che potrebbero piacerti
I monoliti sono tutti cattivi? Qual è la differenza tra un CMS monolitico, componibile e basato su microservizi?
Come si risolve il problema costante dell'aggiornamento della cache e della latenza del sistema di back-end in qualsiasi CMS moderno (in particolare AEM o Edge Delivery?) In questo episodio parliamo con Michał Cukierman, CTO di Dynamic Solutions e co-fondatore di StreamX , un mesh di esperienze digitali per accelerare in modo drammatico e affidabile le richieste di contenuti dinamici complicati provenienti dai numerosi sistemi costituenti che compongono una moderna implementazione CMS.
Non è un'iperbole che se non hai fatto uno sforzo considerevole per ripensare il tuo stack di consegna completo del sito negli ultimi mesi, vorrai farlo. Quindi, per favore, smetti di leggere questo adesso, indossa delle cuffie e porta questo podcast a fare una passeggiata e considera come potrebbe influenzare il tuo ambiente!