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

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