Using Adobe Experience Manager(AEM) CMS as a Visualization Layer
Adobe Experience Manager (AEM) is sold as an Enterprise-grade CMS system ready to support Omnichannel infrastructure through its headless CMS. But is it really enterprise powerful, enterprise efficient and what do you do if it’s been procured for you?
Should AEM be Anyone’s First Choice?
Like most of Adobe’s MarTech offerings, AEM was a product that was purchased and has been integrated to some extent with its other offerings. Typically it will be provided to an enterprise as a package along with Target, Analytics, Audience manager and Marketo. And yes, these packages do work to some extent quite well together. This is very much true of Target and AEM that do have strong integration particularly for optimization testing and personalization.
That said, do the downsides of AEM, which we’ll get to, really compensate for some of these very slender upsides?
AEM is a Multifaceted System
In someways the strength of AEM is that it covers a lot of basics in a functional way. That’s to say, it can do a lot of things, just in my mind, it doesn't really do any of them well. It’s a poor to mediocre headless CMS, its presentation layer isn’t great and as a development platform, well it has particularities that mean you need to look for developers that know the system, and of course pay a premium for them.
If that “broad but inch deep” approach appeals, along with integration to other Adobe products appeals, AEM might make a great system, but it is very unlikely to win any prizes for being best in class.
Using AEM as a Presentation Layer
Best in class practice today with CMS is to split out the content from the presentation, which fundamentally means placing content into a headless CMS. Once that decision has been taken, the next step is to determine how that content will be presented? Which technology choices can be made? What are the impacts of these choices?
AEM, as mentioned previously, has headless capabilities and presentation layer capabilities. Out of the box it uses Content Fragments (an Adobe term for a content component) to store content in AEM’s Digital Asset Manager (DAM) and Experience Fragments to present them in different contexts.
Experience Fragments have been problematic in my experience. We hit scaling problems with them, that caused publishing cascades; that is to say when changes in content were published in embedded experience fragments, a large amount of system resource was required to update them.
The second major issue, and frankly the major issue from a product management standpoint, was that making changes to Experience Fragments wasn’t permuted across the many instances of its use.
When creating a website that can be published at scale, you need a select number of experiences that you’re able to update without having to go into every single page and make an update there. For example, if you find that adding arrows to a scroll section increases engagement by 15%, you want to add arrows to every single scroll section. Doing that manually across 3,000 published instances is not feasible, you need to be able to do that once and have the change manifest through a controlled rollout.
This was exceedingly challenging with AEM Experience Fragments, so we came up with a better method.
AEM Display Components
The above graphic explains the different aspects of a Display Component:
Displayed Experience: is the frontend HTML and JS that an experience visitor will see.
Configuration: are the aspects of the Displayed experience that can be controlled by publishers and the UI to be able to do this.
In Component Content: is content that’s stored in a published instance of the component rather than in a DAM. This is shown as a possibility rather than being desirable.
Logic Code: is any code that controls access to data based on configuration, API calls etc.
API connections: in order to bring in content from other systems or post information to other systems as the case may be.
Switches: allow the rollout of aspects of the configuration and displayed experience as per the strategy of the product manager!
DAM/Content Fragments: really wherever content is stored, in AEM or in another headless CMS, it needs to be brought into the component.
Leveraging the ability to create components, basically small bundles of code, we created display components that were:
Configurable: publishers could decide what elements would be displayed, certain visual aspects or the number of items shown where applicable.
Used elements: were built up of re-usable components, for example an image component allowing consistent functionality where-ever it was used and increasing coding efficiency.
Editor friendly: publishers could still drag and drop components in the way they were used to doing.
Programmatic: developers could integrate more functionality, for example to read APIs and integrate data, or work with switches such as Launch Darkly to aid in rollouts.
Consistent: with a high-level of re-use, they created a consistent user experience for customers.
Backwards compatible: could be used alongside Experience Fragments.
Moving to this concept resulted in increased of publishing efficiency of more that 50% due in large part to:
Easier to use, less configuration and creation was required.
Reduced conversations with stakeholders as stakeholders now had fewer options…
The Downsides of AEM Display Components
Of course, nothing is ever perfect, and the precedent bullet does touch upon one of the downsides of using AEM Display Components, and that’s flexibility.
In an organization with a high degree of standardization, they are a great way of building webpages and web experiences. If, on the other hand, the organization requires a high degree of customization and one-off development, then the concept frankly isn’t appropriate as the cost to build out an experience is higher than using Experience Fragments.
In addition, you do need engineers to be able to build and maintain them, especially as experiences become more complex, which means any given experience can take a long time to build and have a higher cost. This only works if the experience is going to scale over multiple different instances/pages/locales to make it worthwhile.
Conclusion:
AEM is unlikely to be anyone’s first choice of a CMS, yet there are better ways of using it in implementations that need to scale.