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

Ti piace quello che hai sentito? Hai domande su cosa è giusto per te? Ci piacerebbe parlare! Contattaci

Altri episodi di podcast che potrebbero piacerti