6 Best Practices für Website-Projekte mit Adobe Experience Manager

Doch wie bei den meisten Produkten dieser Größe kann man auch schnell die falsche Entscheidung treffen. AEM ist ausgesprochen flexibel und lässt sich vielfältig anpassen. Für jede Anforderung gibt es die unterschiedlichsten Implementierungen, angefangen bei benutzerspezifischen Optionen bis hin zu Lösungen, die sich eng am ursprünglichen Produkt orientieren.

Wir haben umfangreiche Erfahrung mit der Implementierung von AEM und anderen Web-Content-Managementsystemen für Unternehmen. Daher wissen wir genau, worauf Sie bei der Wahl der passenden Lösung achten müssen. Neben der Lösungsarchitektur und dem erforderlichen technischen Umfang spielen auch Wirtschaftlichkeit, Wartungskosten und die Möglichkeit eine Rolle, das System in Zukunft an Veränderungen anzupassen.

In diesem Beitrag werfen wir einen genaueren Blick auf die wichtigsten Faktoren, die Sie bei der Implementierung von AEM beachten sollten.

1. Design und Architektur

Für ein passendes Website-Design und eine entsprechende Architektur sollten Sie zunächst genau analysieren, was Sie tatsächlich brauchen. Finden Sie dann heraus, ob es für diesen Bedarf passende Standardlösungen gibt. Prototypen können helfen, Geschäftsanwendern alternative Lösungen vorzustellen und bestimmte sofort einsetzbare Funktionen zu demonstrieren. Oft reicht es schon, die ursprünglichen Anforderungen und Wünsche ein wenig anzupassen.

Einige Beispiele:

• Ein kontextsensitives Konfigurations-Framework lässt eine Website anders aussehen und reagieren
• Durch das Rendern von Dokumentlisten, die über das Sling Dynamic Include-Framework aus externen Systemen eingespielt werden, sind die Seiten, auf denen sie enthalten sind, immer noch pufferbar
• Mit dem Sling Resource Merger können Standardkomponenten dupliziert werden
• Anstelle von Responsive CSS können AEM-eigene Funktionen verwendet werden
• Bestimmte Anforderungen lassen sich außerhalb von AEM erfüllen, zum Beispiel durch die Integration externer (Micro-)Services; das verhindert den „Missbrauch“ von AEM als WCMS
• Wenn mindestens 95 Prozent der Anfragen pufferbar sind, steigert das die Performance

2. Kernkomponenten

Vor einigen Jahren startete Adobe die Initiative WCM Core Components. Die Idee dahinter: Anstelle der veralteten „Foundation-Komponenten“ sollte eine umfangreiche Komponentenbibliothek als Grundlage für jedes Projekt entstehen.

Diese Kernkomponentenbibliothek stellt Anwendern hochwertige Bausteine für den Aufbau komplexer Webseiten zur Verfügung. Basierend auf diesem Prinzip haben wir unsere eigenen (projektspezifischen) Komponenten entwickelt. Damit tragen wir selbst aktiv zu den Kernkomponenten bei und entwickeln diese weiter.

Durch die Verwendung dieser Komponenten und der zugrundeliegenden Ideen können wir extrem flexible Grundlagen-Codes entwickeln und Komponenten nacheinander aktualisieren, ohne die Rückwärtskompatibilität zu gefährden.

3. Editierbare Templates

Früher mussten Entwickler ihren Unternehmensanwendern unzählige Seiten-Templates zur Verfügung stellen. Bevor ein Content-Autor eine bestimmte Template verwenden konnte, musste der Entwickler diese Template zunächst implementieren und in AEM bereitstellen. Das verzögerte in vielen Fällen die Markteinführung.

Seit ein paar Jahren gibt es in AEM nun sogenannte „editierbare Templates“. Sie reduzieren die Abhängigkeit von der IT bei der Erstellung von Webseiten. Mit „editierbaren Templates“ können Content-Autoren über die AEM Touch-Benutzeroberfläche selbst Templates erstellen.

4. Responsive Grids und das Style System

Mit Responsive Grids können Geschäftsanwender das Verhalten von Seitenlayouts und Komponenten flexibel steuern. Zusammen mit dem AEM Style System können vordefinierte Styles ohne Konsistenzverlust auf verschiedenen Seiten verwendet werden.

Für responsiven Content mussten Designer früher Mockups für die verschiedenen Breakpoints erstellen, die dann von den Entwicklern für ein bestimmtes Template implementiert wurden. Die Autoren nutzten dann dieses Template und füllten es mit Content. Responsive Grids haben diesen Ablauf deutlich vereinfacht: Der Autor kann das Layout jetzt eigenständig anpassen, nachdem er den Content eingegeben hat. Er muss sich in Bezug auf die Responsiveness nicht mehr mit den Entwicklern absprechen oder auf neue Bereitstellungen warten. Diese Funktion wurde mit AEM 6.3 eingeführt. Geschäftsanwender sind jetzt maximal flexibel und für diese Aufgaben nicht mehr auf Entwickler angewiesen. Zum Ändern von Templates ist keine Entwicklung und Bereitstellung mehr erforderlich.

Doch diese Flexibilität hat auch ihren Preis: Geschäftsanwender müssen die Layout-Einstellungen der Komponenten auf den Seiten verwalten, und das kann aufwändig sein. Oft ist hier der Mittelweg die beste Wahl: Einige Layout-Einstellungen werden fixiert, andere bleiben flexibel. Wir können Ihnen helfen, diesen Mittelweg zu finden.

5. Best Practices in der Webentwicklung

Es gibt auch allgemeine Best Practices für die Entwicklung sowie spezifische technische AEM-Standards, die wir in allen AEM-Projekten nutzen. Hier nur einige Beispiele:

• Wer den Build zerstört, muss ihn auch reparieren
• Für jede neue Funktion müssen Einheiten- und Integrationstests durchgeführt werden
• Wenn eine Funktion abgeschlossen ist, muss ein Merge-Request gesendet werden
• Es sollte immer eine „Vier-Augen-Prüfung“ durch einen technischen Experten erfolgen
• Für die Komponentenentwicklung müssen Sling Models verwendet werden, selbst für sehr einfache Komponenten
• Das Proxy Component Pattern wird verwendet
• Benutzerdokumentation und technische Dokumentation müssen immer auf dem neuesten Stand sein
• Der Code muss auf AEM getestet werden, aber auch durch den Dispatcher laufen
• Code darf nicht dupliziert werden, es werden SonarQube-Regeln konfiguriert, jeder Build löst einen SonarQube-Scan aus usw.

6. Umfassende Automatisierung

Unser Ziel ist eine maximale Automatisierung. So erzielen Sie höchste Qualität. Bei On-Premise-Installationen von AEM 6.5 verwenden wir Infrastructure-as-Code, um das Setup von Servern und lokalen Umgebungen zu automatisieren. Auf diese Weise ist jeder Entwickler in nur wenigen Minuten einsatzfähig und arbeitet in einer lokalen Umgebung, die so produktionsnah wie möglich ist. Zu diesem Setup gehört auch ein lokaler Dispatcher, um Caching-Probleme sofort zu erkennen.

Beim AEM-as-a-Cloud-Service nutzen wir den Cloud Manager von Adobe, der die Automatisierung, Aktualisierung sowie die Erstellung von Security Fixes und Releases übernimmt. Hilfreich sind auch vordefinierte und benutzerdefinierte Qualitäts-Gates.

Jedes Mal, wenn eine Codeänderung in die Versionskontrolle eingecheckt wird, wird ein Build ausgeführt und Entwickler werden sofort informiert, wenn etwas falsch läuft. Je nach Branche erfolgt die Bereitstellung in der jeweiligen Umgebung. So sind die Änderungen sofort im richtigen System vorhanden.

Wenn wir uns an diese Prinzipien halten, können wir unsere Releases flexibel und vollautomatisch erstellen. Die Bereitstellung in der Produktion erfolgt quasi per Knopfdruck.

Fazit

Es ist wichtig, die aktuellen Best Practices für die Website-Entwicklung im WCMS zu kennen. Aber noch wichtiger ist es, einen Partner zu haben, der diese Best Practices kennt und dem Projektteam vorstellt, um Ihr Digital-Experience-Projekt zum Erfolg zu führen. Diese Best Practices sind nicht nur für die Erstellung neuer Websites wertvoll, sondern auch bei der Planung von Upgrades oder der Erweiterung einer bestehenden Adobe-Plattform.