Adobe Experience Manager is a fully-featured enterprise web content management system, but its flexibility requires the right expertise to choose between various solution directions. Get your AEM 6.3 website on the path to success.
Subscribe to our blog
Adobe Experience Manager (AEM) is an enormous enterprise web content management system. It is packed with functionalities which enable content authors to create great digital experiences.
As is the case with every product of such large scale, it is also very easy to make the wrong decisions. AEM is a very flexible product that allows many customizations to be made and therefore any requirement can be translated into numerous implementations, ranging from a custom-built solution separated from the core of AEM, to a solution that is tightly integrated to the core of the product.
Adobe Experience Manager is not your average basic website platform
With our years of experience in enterprise web content management and AEM, we know all the pitfalls of choosing the various solution directions. We also know the idea behind the product very well, allowing us to pick the most cost-effective, maintainable, future-proof solutions.
In this article I will highlight the key factors for website development project success in AEM 6.3.
#1 Design & architecture
Thoroughly assess every requirement and verify them with the functionalities of the product. Sometimes you may need to adjust initial requirements so that AEM's capabilities fully match the desired result. 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 functionality inside AEM for it;
- Completely removing requirements because they don't follow the AEM-product;
- Make 95+% of the requests cacheable, ensuring high performance.
#2 Using the WCM Core Components
At the end of 2015, Adobe started an initiative called WCM Core Components. The idea was to move away from the old "foundation" components that were not up-to-date with all the best practices that have been developed and to provide a solid layer upon which every project could extend.
Leveraging these components without any customizations provides solid, single-responsibility building blocks for the content authors. Based on the principle behind these core components, we have developed our own (project-specific) core components as well. During our digital experience projects we actively contribute to the WCM Core Components, to make them even better.
By using these components and leveraging the idea behind them, we are able to setup a very flexible code-base and gain the possibility to upgrade the components one-by-one, without breaking functionality.
#3 Editable templates
Previously, it was the task of a developer to make templates available to content authors. A developer would create (code) a template, deploy it to AEM and then a content author could use that template to create a page based upon it.
In AEM 6.2, a new feature called "Editable Templates" was introduced. This feature allows content authors to assemble a template themselves, using the Touch UI. A developer is not needed anymore to perform what we call mainly a configuration task.
#4 AEM responsive grid and style system
Using the new AEM responsive grid in combination with the latest style system allows authors to specify, directly in the content, how they want their components to behave on different screen sizes.
The traditional workflow to make content responsive required the designer to create mockups of 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 the new responsive layout editing, the workflow is simplified: the author fills the content and can adapt the layout autonomously, without the need to consult with developers regarding responsiveness or wait for new deployments. This new AEM 6.3 feature gives the authors great flexibility, while at the same time not requiring developers to execute these tasks. Finally, no development (and deployment) effort is needed anymore to change a template.
#5 Web development best practices
There are also global 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 functionality;
- The use of feature branches;
- Merge requests need to be sent when a feature branch 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;
- The new resourceType-parameter must be used in the Sling Model;
- 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
We strive to fully automate everything. We are using Puppet (software configuration management tool) to automate the setup of the 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, to ensure that we also catch caching-pitfalls immediately.
Every time a code-change is checked in to the version control system, a build is executed on Jenkins (continuous integration tool), to immediately notify the developers if something goes wrong. Depending on which branch receives the new code, a deployment will be done to the applicable environment, so that the change is immediately present on that system.
Applying the Git Flow principle, we are very flexible in doing our releases, also, fully automated. Only a deployment to the production environment takes the push of a button (and that's it).
Knowing the latest best practices specific to website development in the WCMS you’re working with is key. But maybe more importantly, having someone who knows them and also enforces them within the project team is essential to the success of your digital experience project. These guidelines are most valuable when setting up new websites in AEM, but you can get started and apply them when planning upgrades or an expansion of your existing Adobe platform – it should be very easy to keep this solution stable and up-to-date.
About the author
Henry Kuijpers is a Digital Experience Technical Consultant at Amplexor based in The Netherlands. Henry is a certified AEM Architect, DevOps Engineer and Professional Scrum Master.