Blog
6 best practices for Adobe Experience Manager website projects
Adobe Experience Manager (AEM) is a comprehensive enterprise web content management system. Packed with a broad range of capabilities, it supports content and marketing teams in building great digital experiences.
But as is the case with every product of such a large scale, it’s also very easy to make the wrong decisions. AEM is a very flexible product that allows many customizations. This means that any requirement can be translated into different kinds of implementations, ranging from a custom-built solution to a solution that is tightly aligned with the core principles of the product.
Having a broad experience implementing AEM and enterprise web content management systems in general, we know the pitfalls of choosing one of the various solution directions. Besides solution architecture and potential technical depth, it’s important to also think in terms of cost-effectiveness, maintainability and ensuring your system is future-proof.
In this post, we will highlight a few of the key factors which should be top of mind when implementing AEM.
#1 Design & architecture
When it comes to design and website architecture, your first step should be thoroughly assessing every requirement and aligning with off-the-shelf capabilities as early as possible. Prototyping can be used to communicate alternative solutions with business users and to demonstrate certain out-of-the-box capabilities. In most cases, a substantial amount of efficiency can be gained by slightly adapting the initial requirements.
Some examples:
Leveraging the Context-Aware Configuration framework to make sub-parts of the website look & behave differently;
Rendering document lists that come from external systems through the Sling Dynamic Include framework to make the pages that contain them still cacheable;
Using the Sling Resource Merger to avoid duplicating out-of-the-box components;
Removing responsive CSS and leveraging functionalities inside AEM for it;
Implement certain requirements outside of AEM, for example by integrating with external (micro)services. This is key to preventing “misuse” of AEM as a WCMS;
Make 95+% of the requests cacheable, ensuring high performance.
#2 Core Components
A few years ago, Adobe started an initiative called WCM Core Components. The idea was to move away from the old “Foundation Components” that had become outdated and instead provide a solid library of components upon which every project could extend.
This library of Core Components provides business users with a set of high-quality building blocks to create advanced web pages. Based on the same principles, we have developed our own set of (project-specific) components as well. This also means, we actively contribute to Core Components to help them improve over time.
By using these components and leveraging the ideas behind them, we are able to setup extremely flexible code-bases and gain the possibility to upgrade components one-by-one, without breaking backwards-compatibility.
#3 Editable Templates
Before, it was a developer’s task to make a set of page templates available to business users: before a content author could use a specific template, a developer would first need to implement that template and deploy it to AEM. This often resulted in an increased time-to-market.
For the past few years however, a feature called “Editable Templates” was made available in AEM to reduce reliance on IT during page building. “Editable Templates” allows content authors to assemble templates themselves, using the AEM Touch UI interface.
#4 Responsive Grid & Style System
Using Responsive Grids, business users can deal with page layouts and component behavior in a flexible manner. Combined with the AEM Style System, predefined styling can be applied without sacrificing consistency across pages.
The traditional workflow to make content responsive required a designer to create mockups for the different breakpoints, the developer to implement them for a specific template and the author to pick that template and fill in the content. With Responsive Grids, this workflow was dramatically simplified: the author fills the content and can adapt the layout autonomously, without the need to consult with a developer regarding responsiveness or wait for new deployments. This feature , introduced in AEM 6.3, provides business users with flexibility, while at the same time not requiring developers to execute these tasks. Finally, no development (and deployment) effort is needed to change a template.
However, this flexibility comes at a price: the business users now have to manage the layout settings of components on pages, and this can take a lot of effort. It’s often better to find a middle ground where some layout settings are fixed and others are left flexible. We can help you find the right balance.
#5 Web development best practices
There are also general development best practices as well as specific technical AEM standards that we enforce throughout all AEM projects. To sum up a few:
- Who breaks the build, fixes the build;
- Unit tests and integration tests are required for every new feature;
- Merge requests need to be sent when a feature is finished;
- A peer-review needs to be done by a technical lead;
- Sling Models must be used for component development, even if the component is very simple;
- Use the Proxy Component Pattern;
- User & technical documentation must always be up-to-date;
- Code must be tested on AEM, as well as through the Dispatcher;
- Code duplication disallowed, SonarQube rules configured, every build triggers a SonarQube scan, etc.
#6 Full automation
To increase the quality of our work, we strive to maximize automation. For on-premises installations of AEM 6.5, we use infrastructure-as-code to automate the setup of servers, as well as our local environments. This means that any developer can be up and running in a few minutes, working on a local environment that is as close to production as possible. This setup even includes a local Dispatcher instance, to ensure that we also catch caching-pitfalls immediately.
For AEM-as-a-Cloud-Service installations, we get a lot of help from Adobe’s Cloud Manager, which fully automates, upgrades, security fixes and releases, combined with predefined and custom quality gates.
Every time a code-change is checked into version control, a build is executed and developers are notified instantly when something goes wrong. Depending on the specific branch, a deployment will be done to the applicable environment, so that changes are immediately present on the right system.
Following these principles, we are flexible in doing our releases in a fully automated way. A deployment to production is just a push of a button.
Conclusion
Knowing the latest best practices specific to website development in the WCMS you’re working with is key. But maybe more importantly, having a partner who knows them and also enforces them within the project team is essential to the success of your digital experience project. These guidelines are not only valuable when setting up new websites, but also when planning upgrades or an expansion of your existing Adobe platform.
