AEM 구현의 작업 역할 정의하기

대규모 디지털 경험 플랫폼 구현(특히 AEM의 경우)에서 '웹 마스터' 또는 만능 재주꾼이 원격으로 필요한 모든 역할을 효과적으로 처리할 수 있는 시기는 이미 상당히 지났습니다. 따라서 여기 팟캐스트 에피소드에서 다룬 내용과 아래에 자세히(그리고 정기적으로 업데이트될 예정입니다) AEM 프로젝트의 주요 역할과 책임 및 장점에 대해 설명합니다. 또한 (때로는 훨씬 더 중요한) 이 역할이 일반적으로 사내에서 수행하는 역할인지, 아니면 대행사나 솔루션 제공업체와 계약하는 역할인지도 고려해야 합니다.

Apple 팟캐스트와 Spotify의 오디오 또는 비디오 팟캐스트로도 제공됩니다.

팟캐스트에서 맡은 역할에 대한 간략한 요약입니다:

제품 소유자 / 사이트 소유자

제품 소유자 또는 사이트 소유자는 구현의 콘텐츠와 기능에 대한 1차적인 책임을 지는 사람으로, 일반적으로 회사의 이사급 또는 부사장급에 해당합니다. AEM 사이트의 경우 일반적으로 AEM은 해당 비즈니스의 ".com"을 실행합니다. 모든 직무 중에서 회사 외부에 아웃소싱하지 않는 유일한 직무이기도 합니다.

팟캐스트 7:11 에서 들을 수 있습니다.

AEM 솔루션 아키텍트(멀티 솔루션 아키텍트)

[ 9:45 에서 가져옴 ]

솔루션 아키텍트는 위의 제품 소유자와는 대조적으로 거의 대부분 공급업체나 대행사 소속입니다. 이들의 임무는 특정 기업의 문제, 문제점, 요구사항, 인력, 목표, 예산, 원하는 능력, 성공 지표를 철저히 파악한 다음 이를 실제로 충족하고 실행할 수 있는 솔루션을 설계하는 것입니다. AEM의 솔루션 아키텍트는 일반적으로 개발, 운영 및 전체 솔루션을 설계하는 데 필요한 관련 기술을 보유한 사람입니다.

"멀티 솔루션 설계자"는 해결해야 하는 문제가 "AEM 및 Adobe Experience Platform", "Sitecore + SAP Commerce" 또는 "AEM Assets + AEM Forms"와 같이 여러 개별 솔루션에 걸쳐 있는 경우 참여하게 됩니다.
참고로, 좋은 솔루션이 판매되기 위해서는 솔루션 아키텍트가 필요하지만, 솔루션 아키텍트가 오랜 시간을 들여 수많은 성공(및 실패)을 경험한 사람이 아닌 '기술 세일즈맨'이 되면 솔루션은 얕고 신중하지 못한 솔루션이 되는 경향이 있습니다.

솔루션 아키텍트는 단순히 화려하게 들리거나 XYZ 회사의 영업팀이 설득력 있는 세일즈 피치에서 "AI"라고 정확한 횟수만큼 말했기 때문이 아니라 적절한 제품을 적시에 구매할 수 있도록 '세일즈 버퍼'( 11:00)라는 모자를 쓸 수 있어야 한다고 생각합니다.

AEM 아키텍트

프로젝트 또는 팀에 필요한 "AEM 아키텍트"의 자질은 매우 다양하기 때문에 AEM 아키텍트는 정확하고 일관되게 정의하기 가장 어려운 역할 중 하나라고 할 수 있습니다. [ 15:48 참조 ] 할 수 있어야 합니다:

• 팀원 누구보다 AEM에 대해 잘 알고 있습니다.
• 무엇보다도 AEM이 할 수 있는 모든 것을 알고 있어야 하며, AEM이 할 수 없는 일이나 하지 말아야 할 일에 대한 선을 그을 줄도 알아야 합니다. 이를 얻기 위한 유일한 방법은 경험이며, 그 경험이 모두 '행복한 길'의 경험이어서는 안 됩니다. 그들은 AEM이 불길에 휩싸이는 것을 몇 번이나 보았을 것입니다.
• 프로젝트 관리, 인사 관리, 인사 디버깅을 위한 소프트 스킬을 갖추고 있어야 하며, 팀의 성공을 위해 정말 필요한 도구가 필요할 때 '영업 디플렉터'로서의 역할뿐만 아니라 때로는 '영업 액셀러레이터'로서의 역할도 잘 수행해야 합니다. [ 21:29 참조 ]

AEM 프런트엔드 개발자 & AEM 백엔드 개발자

FE와 BE 개발자가 같은 사람이 될 수 있는지, 아니면 이러한 역할을 분리하는 것이 합당한지에 대해 자세히 살펴보면 훨씬 더 쉽게 정의할 수 있습니다. [25:00]

AEM Forms 개발자

"AEM 양식"은 "AEM에서 수행된 양식"과는 매우 다르며, 이는 매우 혼란스러울 수 있습니다. AEM Forms는 AEM Sites와는 별도의 SKU인 놀라운 제품으로, 대기업에서 real-deal digital transformation 을 철저하게 활용하고 있습니다.

AEM Devops 엔지니어 / 시스템 관리자

온프레미스 AEM이든, Adobe 관리형 6.5이든, 클라우드 서비스로서의 AEM이든, AEM에서 시스템 관리 및 운영을 수행하는 작업에는 항상 AEM 경험이 있는 사람이 작업해야 합니다. 누군가는 항상 모니터링, 안정성, 유지 관리, CI/CD, 배포, 성능을 모두 담당해야 합니다. 그렇지 않으면 중단과 성능 저하가 발생하는 웹사이트가 될 수 있습니다.

AEM에서 시스템 관리를 수행하면서 겪은 전쟁 이야기부터 자체 호스팅 AEM이 여전히 필요한지 여부에 대한 논의에 이르기까지 이 특정 역할에 대해 평소보다 더 많은 노력을 기울였을 것입니다. 어떤 서비스가 '완전 관리형'이라고 말하더라도 회원님의 사이트를 특별히 관리하지 않는 한(일반적으로는 그렇지 않습니다), 이 역할을 적절히 수행하고 있는지 확인해야 한다는 점은 아무리 강조해도 지나치지 않습니다.

이 AEM 역할 토론에서 다루는 전체 주제

• 0:00 - 소개 & 대상(모집자 & AEM 사이트 소유자)
• 2:36 - 비 AEM 사이트 관리 프로젝트
• 3:24 - 모놀리스 대 컴포저블 토론
• 4:45 - 간단한 "AEM 인력을 인하우스 또는 아웃소싱해야 하나요"?
• 7:11 - 역할: AEM 사이트 소유자 또는 제품 소유자 정의
• 9:45 - 역할: 솔루션 아키텍트 또는 AEM 솔루션 아키텍트 정의
• 11:00 - 솔루션 아키텍트 "판매 버퍼"
• 15:00 - "구현 프로젝트에서 "계획" 분리
• 15:48 - 역할: AEM 아키텍트 정의
• 16:48 - "리드 개발자" 와 "아키텍트 구분하기"
• 18:10 - 아키텍트의 "소프트 스킬"
• 21:29 - 또한 "Sales Deflector" 모자를 쓰고 있습니다.
• 22:20 - 건축가 컨설팅 & 윤리적 필요성을 스스로 해결해야 할 필요성
• 23:47 - "세일즈 액셀러레이터로서의 아키텍트"
• 25:00 - 역할: AEM 개발자 정의(및 프론트엔드 대 백엔드)
• 29:05 - 역할 역할: AEM Forms 개발자(및 실제 디지털 혁신)
• 32:09 - 역할 역할: AEM 자산 개발자 & 정보 설계자
• 33:31 - 역할 역할: AEM 품질 보증(QA)
• 36:28 - 역할 역할: AEM 작성자
• 39:45 - 역할 역할: AEM Devops/AEM 시스템 관리자
• 44:20 - 웹사이트 대시보드의 격언
• 45:50 - 올바른 툴링 구매를 보장하는 AEM 개발자의 역할 & 사용
• 46:45 - AEM 시스템 관리자는 AEM 경험이 있어야 합니까?
• 48:55 - 사내에 AEM 운영팀이 있어야 하나요?
• 51:44 - 역할 역할: 어도비 커머스, Hybris, 어도비 경험 플랫폼, SEO
• 53:50 - 인하우스 또는 아웃소싱을 결정하시나요?

팟캐스트를 들어보시고, 이와 같은 새로운 인프라 모델이 여러분의 환경에 어떻게 적용될 수 있는지 논의하고 싶으시면 연락주세요! 연락주세요!

팟캐스트 스피커

들으신 내용이 마음에 드시나요? 어떤 것이 적합한지 궁금한 점이 있으신가요? 상담하고 싶어요! 문의하기

더 많은 팟캐스트 에피소드 보기