AEM Digital Foundation Blueprint

Author Bio: Ken Woodward is a VP, Software Engineering, at Hoodoo Digital. He has 11 years developing, architecting, and implementing websites using the Adobe marketing technology stack, including Adobe Experience Manager (AEM). These projects have included small and large scale AEM implementations, custom AEM integrations, and Digital Foundation Blueprint AEM implementations. 

Creating a strong Adobe Experience Manager foundation starts with proper architecture.  Adobe has provided the tools to do this, however, it is often up to an AEM architect to decide how those tools should be realized. As an AEM architect, I’ve learned a few things about how to unlock the potential of AEM, even within the confines of Adobe’s Digital Foundation Blueprint.  It has been my responsibility to develop an implementation roadmap using a variety of methodologies that  provides content creators with a flexible, easy-to-use system.  With the benefit of hindsight, I want to share some things I have learned about successfully implementing these types of projects using the Adobe Digital Foundation Blueprint. 

Historically, Adobe Experience Manager (AEM) implementations could be difficult, long, and pricey, due to software limitations and complex client needs. Over the years, Adobe has gone through a process to simplify their software and provide standardized development methodologies to make implementations more efficient. Digital Foundation Blueprint is one of these methodologies, and it is used to streamline AEM implementations. The focus is to launch a site in 90 days (or less) by limiting customizations in development. With this strategy,  the main marketing goals can be achieved sooner, and more complex efforts can be completed and integrated later. The primary goal of AEM Digital Foundation Blueprint is to drastically improve time-to-market. 

Below I’ve outlined some effective methods to help create a flexible and easy-to-use system for content creators using the Digital Foundation Blueprint. We’ll start with two of the largest aspects of the implementation journey, component development and content creation. 

COMPONENT DEVELOPMENT

The majority of time spent implementing experiences in AEM is creating or extending components.  Historically, for any given experience, developers had to decide whether to create a net new component or extend an out-of-the-box (OOTB) component. That paradigm still exists, however, the Digital Foundation approach aims to leverage AEM Core Components as much as possible.  This means understanding AEM’s Core Component library is key in making a Blueprint project successful.  Architectural decisions should revolve around these components with an effort made to minimize extending them as much a possible.

The Core Component library provides a lot more flexibility than the legacy out of the box components.  They take advantage of the latest features AEM has to offer: editable templates, policies (specifically style systems), and the layout functionality.  Architects should always ask themselves if a piece of functionality can be used via an AEM Core Component before creating something new or custom. 

Fortunately, setting up your AEM project with the Core Components is simple as it is included in the AEM Project Archetype. The archetype adds an extended version of each Core Component under your defined project folder (e.g. ui.apps/{mysite}/components/content/text) so you are ready to start using them immediately.

EXTENDING COMPONENTS

Components should not be extended unless absolutely necessary.  One of the most important aspects of AEM Digital Foundation Blueprint is how quickly it can be delivered.  Extending components tends to  increase the amount of development time required.  Instead of modifying components’ HTML/HTL and Sling Models, use AEM Style Systems and CSS as much as possible for customizations.  This approach creates a faster development cycle because style changes are the only things that need to be created and tested.

STYLE SYSTEMS

Style systems are what allow the Digital Foundation Blueprint to really shine. Style systems allow template editors to assign HTML class attribute values to components so CSS styles can target and manipulate the look and feel of them.  The majority of component development time should be spent working with this system.

Style systems allow developers to take a single component and style it a number of different ways.  A common use case for this is the teaser component. The Core teaser component contains the following properties:

• Pre-title
• Title
• Description
• Call to Action (ability to add more than one)
• Image

Now consider some of the options that are available to display the teaser component just using CSS:

• Show/Hide any of the elements
• Position the text on top, underneath, or to the side of the image
• Display different Call to Action button styles
• Define the size of any of the text or image

The style system provides great flexibility, however it is important to not go too far with the amount of style options.  For example, granting control over margins, padding, borders, and font-size for every component can create a lot of work for content authors, in addition to creating design and layout inconsistencies on the site itself.  Too many options make it difficult to quickly and consistently author components.  It is important to find the right balance between complexity and usability. 

POLICIES

Policies are what allow template editors the ability to assign style systems and other configurations to components.  Policies can be managed two different ways; via code or within the AEM template UI.  To avoid these approaches conflicting with each other, it is important to define who manages the policies, template editors or developers. During initial development, I found it can be more effective to manage policies via the codebase so everything stays synced and consistent between the developers.  To do this, the filter.xml file needs to be updated (ui.content/src/main/content/META-INF/vault/filter.xml) to use “replace” instead of “merge” for everything under /conf. Once template editors begin managing policies, the filter should be reverted to “merge” so those changes are not lost.  Once policies are managed via the UI, developers will need to sync their local policies with the relevant AEM instance.

<workspaceFilter version="1.0">

   <filter root="/conf/myproject" mode="replace"/>

   ...

</workspaceFilter>

MODELS

From time to time, you may need to extend a Sling Model that is provided by the AEM Core Components.  These models are not exported, making them unavailable to extend.  Adobe has provided a way around this via the Delegation Pattern for Sling Models.  This allows developers to easily overwrite and extend those models.  This method is recommended over rewriting an AEM Core model as it will maintain compatibility with different versions of the models. It helps avoid redundant code and can save a lot of time in the development process. 

CONTENT AUTHORING

Looking back over the Digital Foundation Blueprint projects I have been a part of, the biggest “gotcha” was the amount of time content authoring can take. This can be a show-stopper for successfully executing a Digital Foundation Blueprint implementation on time. There are three things that primarily impact the amount of time content authoring takes: teaching the client how to author templates, pages, and components using AEM, the complexity of those components, and the ability to adapt the client’s existing designs to fit within the core components. 

Content and Template authors have more on their plate than ever before. They need to understand how editable templates (structure vs initial content) and layout mode work. They also need to know how to manage policies, apply styles, and use layout options with components. Historically, much of this was done by developers.  Putting this responsibility in the hands of content creators can be a tall task and can be especially challenging for those who have not worked with AEM before. 

AEM is very flexible.  Flexibility breeds options and options breed complexity.  Architects may not be involved with content authoring, but they lay the groundwork for the amount of complexity content authors will be required to sort through.  It is very important to look at the component implementation both holistically and individually to ensure the implementation incorporates the right balance.  Thoughtful architecture around this can drastically speed up content creation time.

To help alleviate the amount of responsibility laid on content creators, I dedicate time to educating and training content authors.  Oftentimes, content creators that are new to AEM do not understand how much time will be required to learn AEMs systems. I’ve found it essential to help authors understand how editable templates work and how that translates all the way to a finished page. 

SUMMARY

AEM Digital Foundation Blueprint is a great way to jump into the Adobe Marketing stack, and the short go-to-market timeline can be tremendously appealing to many businesses. However, as with any new methodology, architects and developers need to evolve their approach to implementation. Beyond that, there can be a lot to learn for content authors who are new to AEMs latest toolset.  Implementing proper architecture can make all the difference for successful project execution. Careful and thoughtful planning from an AEM architect will help enable future evolutions and growth for the project. When using Digital Foundation Blueprint, future evolutions are often a crucial component of the customer’s long-term plan, and as such, it is critical to ensure that any project developed using Digital Foundation Blueprint is built with future iterations in mind.