How to get your Adobe Experience Manager (AEM) implementation back on track
Using Adobe Experience Manager (AEM) can be a transformative step to expand your digital presence with personalised content. However, implementing AEM can be a challenge.
The top obstacles? Not understanding the platform’s capabilities, lack of standardisation, and limited experience around headless implementation.
Over the years of working with Adobe and being a Platinum Partner, we’ve learned how to solve these problems and–more importantly–prevent them. Our hope is that these insights can help you avoid repetitive mistakes and ensure your AEM deployment is a success.
Reasons why AEM implementations get off-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 standardisation
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 behaviour 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 behaviour 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.
Bringing AEM implementation back on track with DEPT®’s expertise
We have a two-phase approach to tackle the challenges around AEM:
- We start with an audit of your system to analyse the structure of the front-end code and the process behind the component creation. After that, we define your mapping and content workflow.
This audit helps us understand whether the automation processes for content generation are built correctly. It also tells us whether the selected content blocks match the use case that has been given.
- Following the audit, we focus on reducing the number of templates and components you have. Then, we create development practices standards, standardising the content creation process and how it is shown to the end user.
This phase brings consistency to your current AEM implementation and significantly eases its future releases.
Our holistic approach has already helped several customers across the globe, including major banks, insurance companies, and automotive companies. With a dedicated AEM team, we have robust resources across design, development, and marketing.
Unlock the full potential of Adobe Experience Manager with DEPT®.
CTO – APAC & DEPT® Adobe Practice