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.
#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.
