Definieren der Jobrollen von AEM-Implementierungen
Bei jeder großen Implementierung einer Digital-Experience-Plattform (und BESONDERS bei AEM) sind wir weit über den Punkt hinaus, an dem von einem "Webmaster" oder Tausendsassa erwartet werden könnte, dass er alle erforderlichen Rollen effektiv abdeckt. In unserer Podcast-Episode hier und dann im Folgenden werden die Hauptrollen eines AEM-Projekts sowie ihre Verantwortlichkeiten und Stärken ausführlich beschrieben (und hoffentlich regelmäßig aktualisiert). Aber auch (und manchmal viel wichtiger), ob es sich um eine Rolle handelt, die man in der Regel intern behalten würde, oder ob es sich um eine Rolle handelt, für die man normalerweise einen Vertrag mit einer Agentur oder einem Lösungsanbieter abschließen würde.
Auch auf Apple Podcasts und als Audio- oder Video-Podcast auf Spotify verfügbar.
Eine kurze Zusammenfassung der Rollen, die wir im Podcast einnehmen:
Product Owner / Websitebesitzer
Der Product Owner oder Websitebesitzer ist der Hauptverantwortliche für den Inhalt und die Funktionalität einer Implementierung, in der Regel entweder auf Direktorenebene oder auf VP-Ebene in einem Unternehmen. Bei AEM-Sites führt AEM in der Regel die ".com" dieses Unternehmens aus. Von allen Rollen hier ist es die einzige, die im Wesentlichen nie an eine Partei außerhalb des Unternehmens ausgelagert wird.
Aufgegriffen um 7:11 Uhr im Podcast
AEM Solution Architect (auch Multi-Solution Architect)
[aufgenommen um 9:45]
Ein Solution Architect ist, im Gegensatz zum obigen Product Owner, fast immer von einem Anbieter oder einer Agentur. Ihre Aufgabe ist es, die Probleme, Pain Points, Anforderungen, Personal, Ziele, Budgets, gewünschten Fähigkeiten und Erfolgsindikatoren für ein bestimmtes Unternehmen gründlich zu verstehen und dann eine Lösung zu entwerfen, die diese tatsächlich erfüllt und die umgesetzt werden kann. Ein Lösungsarchitekt für AEM ist in der Regel bereits ein AEM-Architekt, der auch über Erfahrung in den Bereichen Entwicklung, Betrieb und die damit verbundenen Fähigkeiten verfügt, die zum Entwerfen einer funktionierenden Gesamtlösung erforderlich sind.
Ein "Multi-Solution Architect" muss am Ende engagiert werden, wenn sich das zu lösende Problem über mehrere separate Lösungen wie "AEM und Adobe Experience Platform" oder "Sitecore + SAP Commerce" oder "AEM Assets + AEM Forms" erstreckt.
Als Anmerkung - Lösungsarchitekten sind notwendig, damit eine gute Lösung verkauft wird, aber Lösungen neigen dazu, oberflächlich und schlecht durchdacht zu sein, wenn dieser Lösungsarchitekt am Ende ein "technischer Verkäufer" ist und nicht jemand, der seine Zeit mit schmutzigen Händen verbracht hat und eine Reihe von Erfolgen (und Misserfolgen) auf dem Buckel hat.
Ich habe auch festgestellt, dass der Solution Architect in der Lage sein muss, den Hut des "Sales Buffer" zu tragen (besprochen bei 11:00), um sicherzustellen, dass die richtigen Produkte zur richtigen Zeit gekauft werden, und nicht nur, weil sie auffällig klingen oder weil das Verkaufsteam der Firma XYZ in einem überzeugenden Verkaufsgespräch die richtige Anzahl von Malen "KI" gesagt hat.
AEM-Architekt
Der AEM-Architekt ist wahrscheinlich eine der am schwierigsten zu definierenden Rollen, da die Qualitäten, die ein Projekt oder Team an einen "AEM-Architekten" benötigt, sehr unterschiedlich sind. [Siehe 15:48] Sie müssen in der Lage sein:
- Kennen Sie AEM besser als die meisten anderen im Team
- Vor allem sollten sie alles wissen, wozu AEM in der Lage ist, und sie sollten auch wissen, wo sie die Grenze ziehen müssen, wozu AEM nicht in der Lage ist oder wozu es nicht gezwungen werden sollte. Der einzige Weg, DAS zu erlangen, ist Erfahrung, und diese Erfahrung sollte wahrscheinlich nicht alle eine Erfahrung des "glücklichen Weges" sein. Sie hätten sehen müssen, wie AEM ein paar Mal in Flammen aufging.
- Sie sollten über Soft Skills für Projektmanagement, Personalmanagement und Personaldebugging verfügen und auch gut als "Sales Deflector" sowie manchmal als "Sales Accelerator" sein, wenn Werkzeuge wirklich erworben werden müssen, damit ein Team erfolgreich ist. [Siehe 21:29]
AEM-Frontend-Entwickler und AEM-Backend-Entwickler
Viel einfacher zu definieren, obwohl wir uns damit befassen, ob der FE und der BE-Entwickler dieselbe Person sein können oder ob es sinnvoll ist, diese Rollen aufzuteilen. [25:00 Uhr]
AEM Forms-Entwickler
"AEM Forms" ist nicht dasselbe wie "Formulare, die in AEM erstellt wurden", so absolut verwirrend das auch ist. AEM Forms ist ein erstaunliches Produkt, das eine separate SKU von AEM Sites ist und von größeren Unternehmen stark genutzt wird, um eine echte digitale Transformation durchzuführen.
AEM DevOps Ingenieur / Systemadministrator
Die Systemadministration und der Systembetrieb in AEM - unabhängig davon, ob es sich um AEM On-Premise oder von Adobe verwaltetes 6.5 oder AEM as a Cloud-Service handelt - ist etwas, das IMMER jemanden erfordert, der AEM-Erfahrung hat, um daran zu arbeiten. Irgendjemand muss immer die Hüte der Überwachung, Zuverlässigkeit, Wartung, CI/CD, Bereitstellung und Leistung tragen - sonst kommt es zu Ausfällen und einer schlecht funktionierenden Website.
Wir haben wahrscheinlich mehr Arbeit als üblich in die Diskussion dieser speziellen Rolle gesteckt, von den Kriegsgeschichten über die Systemadministration in AEM bis hin zu den Diskussionen darüber, ob selbst gehostetes AEM immer noch eine Sache ist oder nicht. Es kann nicht genug betont werden, dass, selbst wenn ein Dienst sagt, dass er "vollständig verwaltet" ist, Sie sicherstellen müssen, dass diese Rolle angemessen wahrgenommen wird, es sei denn, er verwaltet speziell IHRE WEBSITE (was in der Regel nicht der Fall ist).
Vollständige Themen, die in dieser AEM-Rollendiskussion behandelt werden
- 0:00 Uhr - Intro & Zielgruppen (Personalvermittler und AEM-Site-Besitzer)
- 2:36 - Projektverwaltung einer Nicht-AEM-Site
- 3:24 - Die Monolithen vs. Composable Diskussion
- 4:45 - Gibt es eine einfache Frage "Soll ich AEM-Personal intern oder auslagern"?
- 7:11 - Rolle: Definieren des AEM-Site-Eigentümers oder Product Owners
- 9:45 Uhr - Rolle: Definieren des Solution Architect oder AEM Solution Architect
- 11:00 Uhr - Der Solution Architect als "Sales Buffer"
- 15:00 Uhr - Trennung von "Planung" und "Umsetzungsprojekten"
- 15:48 Uhr - Rolle: Definieren des AEM-Architekten
- 16:48 - Unterscheidung zwischen "Lead Developer" und "Architect"
- 18:10 - Die "Soft Skills" eines Architekten
- 21:29 - Der Architekt trägt auch den "Sales Deflector"-Hut
- 22:20 - Über die Konsultation von Architekten und die ethische Notwendigkeit, sich aus einem Job herauszuarbeiten
- 23:47 Uhr - Der Architekt als "Sales Accelerator"
- 25:00 Uhr - Rolle: Definieren des AEM-Entwicklers (und Frontend vs. Backend)
- 29:05 Uhr - Rolle: AEM Forms Developer (und reale digitale Transformation)
- 32:09 - Rollen: AEM Assets-Entwickler und Informationsarchitekt
- 33:31 Uhr - Rolle: AEM Qualitätssicherung (QA)
- 36:28 - Rolle: AEM-Autoren
- 39:45 Uhr - Rolle: AEM Devops / AEM-Systemadministrator
- 44:20 - Die Maxime des Website-Dashboardings
- 45:50 - Die Rolle von AEM DevOps, um sicherzustellen, dass die richtigen Tools gekauft und verwendet werden
- 46:45 - Muss die AEM-Systemadministration AEM-Erfahrung haben?
- 48:55 - Müssen Sie AEM Ops intern haben?
- 51:44 - Rollen: Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - Entscheidung für Inhouse oder Outsourcing?
Bitte hören Sie sich unseren Podcast an und kontaktieren Sie uns, wenn Sie darüber diskutieren möchten, wie neue Infrastrukturmodelle wie dieses für Ihre Umgebung funktionieren könnten! Bitte melden Sie sich!
Podcast-Sprecher
Tad Reeves
Leitender Architekt bei Arbory Digital
Tad arbeitet seit 2010 mit Adobe-Produkten und verfügt über umfangreiche Erfahrung in der Website-Infrastruktur. Seit 1996 hat er fast jeden Hut in der Website-Bereitstellung getragen, von der Lösungsarchitektur bis zum Produktmanagement, und verfügt über mehr als zwei Jahrzehnte Erfahrung. Er liebt es, dass Arbory ihm die Möglichkeit gibt, ehrliche und effektive Lösungen anzubieten, auch wenn dies bedeutet, die vorherrschenden Verkaufsperspektiven in Frage zu stellen. Wenn Tad nicht arbeitet, fährt er gerne Mountainbike und erkundet die Natur mit seiner Frau und seinen 3 Kindern.
Hank Thobe
Direktor für Business Execution bei Arbory Digital
Hank erwarb 2022 seine AEM-Zertifizierung als Business Practitioner und spezialisierte sich auf Benutzeroberfläche und Workflows. Bald darauf übernahm er eine Rolle als Auftragnehmer bei Zaxby's als Projektmanager für das DevOps-Team. In der Vergangenheit half er bei der Gründung eines Tech-Startups namens InstantOrder, das Tante-Emma-Restaurants mit Online-Essensbestellungen belieferte und seine Motivation für Innovation ankurbelte. Derzeit geht Hank gerne an den Strand, reist, verbringt Zeit in der Natur und treibt Sport in der Schule.
Gefällt Ihnen, was Sie gehört haben? Haben Sie Fragen dazu, was für Sie das Richtige ist? Wir würden uns freuen, mit Ihnen zu sprechen! Kontaktieren Sie uns
Weitere Podcast-Episoden, die Ihnen gefallen könnten
Sind Monolithen alle schlecht? Was ist der Unterschied zwischen einem monolithischen, Composable- und Microservice-basierten CMS?
Wie lösen Sie das ständige Problem der Cache-Aktualität und der Latenz des Backend-Systems in jedem modernen CMS (insbesondere AEM oder Edge Delivery?) In dieser Folge sprechen wir mit Michał Cukierman, CTO von Dynamic Solutions und Mitbegründer von StreamX - einem Digital Experience Mesh zur drastischen und zuverlässigen Beschleunigung komplizierter dynamischer Content-Anfragen aus den vielen Bestandteilen, aus denen eine moderne CMS-Implementierung besteht.
Es ist nicht übertrieben, dass Sie, wenn Sie in den letzten Monaten keine erheblichen Anstrengungen unternommen haben, um Ihren gesamten Website-Delivery-Stack zu überdenken, dies auch tun wollen. Also bitte - hören Sie jetzt auf zu lesen, setzen Sie Kopfhörer auf und machen Sie diesen Podcast spazieren und überlegen Sie, wie er sich auf Ihre Umwelt auswirken könnte!