Dekoracyjna podwójna spirala

Definiowanie ról zawodowych we wdrożeniach AEM

W przypadku każdej dużej implementacji platformy Digital Experience (a w szczególności w przypadku AEM), znacznie przekroczyliśmy punkt, w którym można by oczekiwać, że "webmaster" lub "jack-of-all-trades" będzie w stanie skutecznie pełnić wszystkie wymagane role. Tak więc, omówione w naszym odcinku podcastu tutaj, a następnie wyszczególnione (i miejmy nadzieję regularnie aktualizowane) poniżej, są podstawowymi rolami projektu AEM oraz ich obowiązkami i mocnymi stronami. Ale także (a czasem o wiele ważniejsze), czy jest to rola, którą zazwyczaj pełni się wewnętrznie, czy też jest to rola, którą zazwyczaj zleca się agencji lub dostawcy rozwiązań.

Dostępny również w serwisie Apple Podcasts oraz jako podcast audio lub wideo w serwisie Spotify.

Krótkie podsumowanie ról, które podejmujemy w podcaście:

Właściciel produktu / właściciel witryny

Właściciel produktu lub właściciel witryny jest głównym punktem odpowiedzialności za treść i funkcjonalność wdrożenia, zazwyczaj na poziomie dyrektora lub wiceprezesa w firmie. W przypadku witryn AEM, zazwyczaj AEM obsługuje ".com" tej firmy. Spośród wszystkich ról jest to jedyna, która zasadniczo nigdy nie jest zlecana podmiotowi spoza firmy.

Więcej informacji na 7:11 w podcaście

AEM Solution Architect (również Multi-Solution Architect)

[podjęte na stronie 9:45].

Architekt rozwiązań, w przeciwieństwie do powyższego właściciela produktu, prawie zawsze pochodzi od dostawcy lub agencji. Ich zadaniem jest dogłębne zrozumienie zestawu problemów, bolączek, wymagań, personelu, celów, budżetów, pożądanych umiejętności i wskaźników sukcesu danej firmy, a następnie zaprojektowanie rozwiązania, które faktycznie je spełnia i które można zrealizować. Architekt rozwiązań dla AEM jest już zazwyczaj architektem AEM, który ma również doświadczenie w rozwoju, operacjach i powiązanych umiejętnościach potrzebnych do zaprojektowania całego działającego rozwiązania.

"Architekt wielu rozwiązań" staje się potrzebny, gdy rozwiązywany problem obejmuje wiele odrębnych rozwiązań, takich jak "AEM i Adobe Experience Platform" lub "Sitecore + SAP Commerce" lub "AEM Assets + AEM Forms".
Jako uwaga - architekci rozwiązań są niezbędni, aby dobre rozwiązanie zostało sprzedane, ale rozwiązania mają tendencję do bycia płytkimi i słabo przemyślanymi, gdy architekt rozwiązań kończy jako "techniczny sprzedawca" zamiast kogoś, kto spędził czas z brudnymi rękami i ma na swoim koncie wiele sukcesów (i porażek).

Odkryłem również, że architekt rozwiązań musi być w stanie nosić kapelusz "bufora sprzedaży" (omówiony na stronie 11:00), aby móc upewnić się, że właściwe produkty są kupowane we właściwym czasie, a nie tylko dlatego, że brzmiały krzykliwie lub dlatego, że zespół sprzedaży firmy XYZ powiedział "AI" odpowiednią liczbę razy w przekonującej prezentacji sprzedażowej.

Architekt AEM

Architekt AEM jest prawdopodobnie jedną z najtrudniejszych ról do dokładnego i spójnego zdefiniowania, ponieważ cechy, których projekt lub zespół potrzebuje w "Architekcie AEM" są bardzo zróżnicowane. [Zobacz 15:48] Muszą być w stanie:

AEM Front-End Developer & AEM Back-End Developer

Znacznie łatwiejsze do zdefiniowania, choć zastanawiamy się, czy programista FE i programista BE mogą być tą samą osobą, czy też sensowne jest rozdzielenie tych ról. [25:00].

AEM Forms Developer

"Formularze AEM" to nie to samo, co "formularze wykonane w AEM", choć jest to absolutnie mylące. AEM Forms to niesamowity produkt, który jest oddzielną jednostką SKU od AEM Sites i jest mocno wykorzystywany przez większe firmy do dokładnego wykonania real-deal digital transformation.

AEM Devops Engineer / Sysadmin

Praca polegająca na administrowaniu systemem i operacjach na AEM - niezależnie od tego, czy jest to AEM on-premise, czy zarządzany przez Adobe 6.5, czy AEM jako usługa w chmurze - jest czymś, co ZAWSZE wymaga kogoś doświadczonego w AEM. Ktoś zawsze musi zajmować się monitorowaniem, niezawodnością, konserwacją, CI/CD, wdrażaniem i wydajnością - w przeciwnym razie dochodzi do przestojów i słabej wydajności witryny.

Prawdopodobnie włożyliśmy więcej pracy niż zwykle w omawianie tej konkretnej roli, od historii wojennych związanych z administrowaniem systemem w AEM, po dyskusje na temat tego , czy samoobsługowy AEM nadal istnieje. Nie można po prostu wystarczająco podkreślić, że nawet jeśli jakakolwiek usługa twierdzi, że jest "w pełni zarządzana", chyba że zarządza konkretnie TWOJĄ STRONĄ (co generalnie nie ma miejsca), musisz upewnić się, że ta rola jest odpowiednio utrzymywana.

Pełne tematy poruszone w tej dyskusji na temat ról AEM

Zachęcamy do wysłuchania naszego podcastu i skontaktowania się z nami, jeśli chcesz porozmawiać o tym, jak nowe modele infrastruktury mogą sprawdzić się w Twoim środowisku! Prosimy o kontakt!

Prelegenci podcastów

Tad Reeves

Główny architekt w Arbory Digital

Tad pracuje z produktami Adobe od 2010 roku i ma bogate doświadczenie w zakresie infrastruktury stron internetowych. Począwszy od 1996 roku, nosił prawie każdy kapelusz w dostarczaniu stron internetowych, od architektury rozwiązań po zarządzanie produktem, i ma ponad dwie dekady doświadczenia. Uwielbia to, że Arbory daje mu możliwość dostarczania uczciwych i skutecznych rozwiązań, nawet jeśli oznacza to kwestionowanie dominujących perspektyw sprzedaży. Kiedy Tad nie pracuje, lubi jeździć na rowerze górskim i odkrywać przyrodę ze swoją żoną & 3 dzieci.

Kontakt z Tadem na Linkedin

Hank Thobe

Dyrektor ds. realizacji biznesowej w Arbory Digital

Hank uzyskał certyfikat praktyka biznesowego AEM w 2022 roku, specjalizując się w interfejsie użytkownika i przepływach pracy. Wkrótce potem przyjął rolę wykonawcy w Zaxby's jako kierownik projektu w ich zespole DevOps. W przeszłości pomógł uruchomić startup technologiczny o nazwie InstantOrder, który obsługiwał restauracje typu mom-and-pop z zamawianiem jedzenia online i zapoczątkował jego motywację do innowacji. Obecnie Hank lubi chodzić na plażę, podróżować, spędzać czas na łonie natury i uprawiać sporty wewnętrzne.

Skontaktuj się z Hankiem na LinkedIn

Podoba ci się to, co usłyszałeś? Masz pytania dotyczące tego, co jest dla Ciebie odpowiednie? Chętnie porozmawiamy! Skontaktuj się z nami

Więcej odcinków podcastu, które mogą Ci się spodobać

Monolityczne vs Kompozytowe vs Mikroserwisowe CMS'y - Jakie jest właściwe narzędzie do tego zadania?
Czy monolity są złe? Jaka jest różnica między monolitycznym, kompozytowym i mikrousługowym systemem CMS?
Making AEM & Edge Delivery Go CRAZY FAST - Wywiad ze współzałożycielem StreamX
Jak rozwiązać stały problem świeżości pamięci podręcznej i opóźnień systemu zaplecza w każdym nowoczesnym systemie CMS (zwłaszcza AEM lub Edge Delivery)? W tym odcinku rozmawiamy z Michałem Cukiermanem, CTO Dynamic Solutions i współzałożycielem StreamX - cyfrowej siatki doświadczeń do radykalnego i niezawodnego przyspieszania skomplikowanych dynamicznych żądań treści z wielu systemów składowych, które składają się na nowoczesne wdrożenie CMS.
Adobe Summit 2024: AEM Architecture Disruption
To nie hiperbola, że jeśli nie włożyłeś znacznego wysiłku w ponowne przemyślenie całego stosu dostarczania witryny w ciągu ostatnich kilku miesięcy, będziesz chciał to zrobić. Więc proszę - przestań czytać to teraz, włóż słuchawki i weź ten podcast na spacer i zastanów się, jak może on wpłynąć na twoje środowisko!