It seems like we get asked the question “Can I use AEM for my content?” by companies that are evaluating whether Adobe Experience Manager is right for their organization, all the time. It’s funny the first few times you get that question, because it seems like a no-brainer if you understand what AEM is. And that is the problem—most people don’t really understand what AEM is or how it can drive the content for their organization. So we wanted to take a few conversations we have had, generalize them, and help dispel some myths or confusion about what Adobe Experience Manager can do for, with, or to, your organization’s content. Obviously this isn’t going to get into the specific nuts and bolts of your organization’s setup, but it should give you a feeling for what AEM can do.
First and foremost, we are not trying to sell AEM as a “silver bullet” with this blog post. We are an implementation partner. If AEM is not the right tool for your organization, we will tell you that. This is our first duty as your implementation partner: to tell you where AEM makes sense to use within your organization. But when AEM is the best fit and you just don’t understand how it is, or why it can make your content/Marketing author’s lives easier, then we want to help.
What is AEM?
Adobe Experience Manager (AEM) is an Enterprise Content Management System (also referred to as a WCM or Web Content Management system) that enables content publishers to easily create and assemble content, including integrated asset management, and publish with proper governance utilizing approval workflows. It is built on a stack of open-source solutions including Apache Felix (OSGi container), Apache Jackrabbit (Java Content Repository), and Apache Sling (RESTful web development framework). Experience Manager consists of a set of proprietary modules built on this open technology stack to address common enterprise content needs including management of users, sites, assets, campaigns, and tags; a workflow implementation and UI layer for designing them; and integration with other pieces of the Adobe Marketing Cloud.
When should we use it?
Experience Manager is built to address content management and content publishing. The open architecture of JCR and Sling are designed to enable building systems that create, store, and deliver content. The main criteria for assessing whether AEM is a good technology fit for a business initiative are if and how much the initiative involves content creation or manipulation.
Whereas AEM is a great tool for creating, storing, and delivering content, it is not necessarily an optimal tool in an application where this is not the case. One easy way to assess whether to use Experience Manager is determining to what extent the authoring interface will be utilized for the application and the frequency that content manipulation will occur. That brings us to our first example: the Traditional Model.
The Traditional Model
A prime example of the Traditional Model comes from one of our implementation partners: O.C. Tanner. Their site is what I would consider “content-rich.” They have a lot of content that needs to get displayed. For years, they had been using only PHP-based content management systems to handle all of their website content. But now, they are using the tools of AEM to deliver rich images, video, and other forms of content across multiple devices, all from one site—not to mention utilizing A/B testing and content targeting to help deliver a more optimal and personalized experience.
They utilize the user and group admin system to control permissions in conjunction with their content approval workflow. Their other sites will eventually end up in multiple languages and regions. For that, they plan on using the tools provided with Multi-Site Manager (Blueprints and Live Copy), once they have converted all of their other sites over to AEM. But for now, they use the page templates in combination with the drag-and-drop components to build their content as they need it. This is the bread and butter of Adobe Experience Manager. And so O.C. Tanner chose to use AEM for their content.
There is one thing to be aware of when doing the Traditional implementation that isn’t always so obvious to companies when they first purchase AEM. There is a perception, from Adobe’s marketing about AEM, that you can do all of this stuff straight “Out of the Box”. Unfortunately that is rarely the case. The OOB features are useful and can give you an idea of how the system can be used. But I have yet to meet any company that didn’t want/need to create their own components, or at the very least modify existing AEM components. That is actually the more typical route in the Traditional Model, building additional functionality on top of the set of base AEM components. Your implementation partner will be able to assist or steer you in the right direction so as to not end up with an over-bloated set of authoring tools. And in reality, that is the probably the most important thing to consider, how your marketing authors can use the AEM system to be able to communicate with their audience: customers.
The Hybrid Model
AEM will deliver the website containing the content authored in AEM, as well as data pulled in from web services not delivered through AEM.
The highlight of this example is that the majority of content will be authored in AEM, with some pieces from third-party systems where that data lives, and is rendered using AEM’s engine. A good example of this is the implementation we worked on with Stanford Health Care (SHC). They have a database of all their doctors that contain all the data about them (including publications, schooling, and location), called CAP (CAP stands for Community Academic Profile). SHC uses this as a centerpiece of their content and makes up close to 50 percent of the content on the site, yet it is not contained, nor is it managed, within AEM. A separate call is made to fetch the profile data and it is then rendered using AEM. The remaining content pages (clinics, hospitals, conditions, etc.) are authored through AEM and managed by their authoring teams. To ensure useful and relevant data, there is an system within AEM that links up the clinics to the doctors so that they when you search for one, then you get the other, and vice-versa. Otherwise the content would remain fragmented and useless to those trying to find medical assistance. Stanford Health Care chose to use AEM for their content.
There are a few ways that you can accomplish the Hybrid Model. These can include:
- Import content from another system using a scheduled job – The downside is that content is not “real time” but only updated when the scheduled job runs. But this option is completely cacheable. If you need it on demand, then this will not be the best option.
- Integrate the content on demand from an external system when the page is rendered – The upside is that the content is updated on a regular basis, and it is crawlable by search engines. The downside here is that the content is not cacheable. This presents a major problem for scaling performance as well as possible stability issues, as every request must filter down to the Publish instance to be rendered. Avoid this at all costs.
- Retrieve the content from an external system on the client side – There are complexities around how search engines might index your content, but this can be useful for things that a search engine shouldn’t crawl, such as personal data from your account. With this approach, all aspects of the page that are not dynamic are cached and only the necessary elements are retrieved using client-side code. This is a good compromise between performance/scaling and third-party content needs.
The Web Application Model
AEM will function as an authoring tool and content repository service that allows external systems to easily access the curated content using the RESTful interfaces of AEM. An external system acts as the rendering engine.
One particular customer of ours was trying to decide if they could use AEM in their scenario. They were already using AEM in other parts of their organization using the Traditional Model. For them, instead of having the traditional site, they were using a web application to deliver various pieces of content, from various sources, to a wide variety of users with different permissions. Leaving aside the authentication/authorization issue, this seemed like a no-brainer. They needed to generate content that went out to a web application. The difficulty is that AEM would only be responsible for delivering a portion of the content, and there would be other systems feeding other pieces of data. They had spent a long time creating their own rendering engine and so did not want to use AEM for that purpose. They just wanted a simple authoring tool that would allow their content authors to create content.
We explained that in this scenario AEM would be a good fit. AEM has the ability to create the simple authoring tools that they needed. They would be required to create an interface so that the authors would know how things would look/render in their web application. Conveniently for them, the authoring tools that they needed were very simple and most of the out-of-the-box AEM components were sufficient. So with the interface in place, the OOTB components used, and some minor enhanced components created, they had their POC completed in about 12 hours—compared to the two weeks that the in-house custom development solution took. Obviously your results may vary. They chose to use AEM for their content.
Just because AEM has everything in place to be the rendering engine for a website or a web application, does not mean that it absolutely is always the best fit to do the rendering. In this example, they didn’t want to start over or lose their current rendering engine that they had already spent years working with that was solving so many different problems in their company just to start using what AEM has.
AEM is a powerful engine that has many features and capabilities. But at its heart it is an engine that is focused around authoring and delivering content to the front end user. How your organization chooses to use it is up to you. Most implementations/organizations will fit within these three scenarios: the Traditional Model, the Hybrid Model, and the Web Application Model. Let us help you figure out how to use AEM to its best potential for your organization’s needs. Send us an email to [email protected].