How to get your Adobe Experience Manager (AEM) implementation back on track

Problem: Understanding Adobe platform capabilities

Developers often don’t consider the full range of Adobe’s features before they build a new digital experience. This leads to over-customization, making it difficult to upgrade or maintain in the long run. Adding new features into a finished build is time-consuming and difficult. 

Solution: To integrate Adobe features seamlessly, we recommend moving from a design-first approach to a design-plus-enablement approach. It’s smart to invest time in understanding the nuances of the AEM platform to ensure you design and implement solutions that best use its capabilities. 

At DEPT®, we often get into a north-star approach to ensure we can seamlessly map platform capabilities to content operations. We train the customer teams on the platform before we start the development process rather than doing it after the implementation.

Problem: Lack of standardization

When working with Adobe, it can be challenging to determine when to use content fragments versus experience fragments or when to extend a core component versus build a new one.

With this lack of clear standards for component development, you risk creating numerous variations of components, which can lead to management difficulties in the long run. 

Solution: To address this issue, it is crucial to define and enforce standards to reduce component variations and component authoring complications. You can handle it with:

• A conscious effort to ensure that additional components are created only when required. A simple variation will not suffice.
• Converting interactive components to experience fragments for greater reusability across channels. For example, using an interest calculator for a personal loan could have variations enabling component reuse on microsites and campaign landing pages.
• Using content fragments for component configuration instead of traditional dialogues for complex authoring components.

This approach will help you streamline development and ensure a more manageable and scalable implementation over time.

Problem: Headless implementation 

The discussion around headless vs. head-full implementation is another layer of complexity. What is often forgotten is that the decision to go headless depends on the nature of the content and the required functionality. 

For instance, AEM provides headless server-side rendering (SSR) capabilities by default. They are suitable only for content pages. But if you are looking to build functional pages with calculators, product configurators, etc., it can make more sense to consume something else in the front end, like React or Pacvue.

Solution: To prevent your implementation from failing, you must adequately identify use cases for headless implementation. The appropriate division into headless and head-full will ensure success and save you money and time. 

It’s not a bad idea to consider a hybrid implementation of native AEM pages, React SSR, and standard React components. They will allow the selection of the best approach relevant to the requirement.

Problem: Clarity in content source and usability

A significant but often overlooked problem is the lack of clarity regarding the content source. When a piece of content is shown on the page, you usually don’t know whether it was created by an author, generated by an API, or sourced from a batch file. 

This leads to surprises at the end of implementation, causing a mismatch between expected and actual component behavior on the pages. As a result, it negatively affects the integrity and reusability of the content strategy.

Solution: The best way to bring this clarity is by involving business teams early to map out the component behavior expectations. Also, the VBRD process, specifically developed by DEPT® for AEM implementation, will help you identify the content source, missing APIs, and practical aspects of content before the first line of code is written.