The Essential Elements of Architecting for AEM Sites Pt 1

On almost all of the AEM implementation projects where we start from scratch (and some of the ones where we pick it up from other development companies), we like to have a set of documents that defines several things about the project. These include: Project Structure & Build Strategy, Environments & Networking, Development Process & Supporting Tools, OSGi Module Definitions, Component & Content Architecture, Authorization & Authentication, Workflows Design, and a Migration Plan. Depending on the project, some are used more heavily than others, or not at all. We wanted to share with you what we do for the Component & Content Architecture, and outline the essential elements of architecting a site for Adobe Experience Manager. This will be a multi-part article series about our AEM Sites architecting process. These articles won’t represent all that we do, but it will focus on the major considerations of the component and content architecture.

When we begin the process of architecture for components and content, two key things are needed: designs (or a pre-existing site) and functional requirements. The architecture is not to be considered the requirements doc or the customer user stories. Those are separate and should be provided by the business with the help of a business analyst. The architecture tells a developer what needs to be created, in order to meet the requirements or user stories. This tells the developer what components and templates need to exist in order to make the site function.

Component Types
Annoyingly, components is an overused term in AEM development. Everything is a component and it gets confusing for everyone involved because there are multiple ways to define it. Most of the time when people hear the word component they think of the thing that content authors pull from the sidekick/sidebar when they are authoring a page. As a way of organization, we break components down in three different ways: Page Component, Embedded Component, and Droppable Components.

  • Page Component consists of components that are the resource type used by content page (cq:Page). It is the initial component that loads the page. That page will then have embedded components. As an example, the paragraph system (or parsys) is a component embedded on the page. Page Components also house the Page Properties.
  • Embedded Components consist of components that are embedded within other components but aren’t usually available from the Component Browser or the Sidekick. This does NOT mean that droppable components cannot also be embedded when necessary. It’s just that embedded components typically are not part of a component group and so they are not available from the Component Browser or Sidekick.
  • Droppable Components consist of components that are available for use from the Component Browser or Sidekick. These components may be embedded in a page but may also be pulled from the Component Browser or Sidekick in appropriate contexts. They define the component group property that controls which category it shows up under the component sidekick.

The second part of this architecting process that we talk about is the Content Architecture. The main components that an author will use need to go on to a page of some sort. And while these pages are themselves made up of components, it is necessary to plan for what page types or templates will need to be available for the authors to use. The Components do not drive the “New Page” option within the Authoring system, those are templates. On those templates, you define what components can be used, where the parsys is located, and what page properties need to be set up. Always with the Author in mind. And with the advent of AEM 6.2, making use of the Template Editor would be a very good idea.

I’m a broken record on this subject, I know, yet when doing your component and content architecture, we highly recommend that part of your process be a discussion or review of how an author will actually use the component. We have talked about this before in a previous blog post discussing taking the author into consideration ( when doing an AEM implementation by providing some suggestions for how developers can do that, as well as presented at Adobe Summit 2014 on the subject ( Making use of an Authoring Advocate, a person specially dedicated to the needs of the author, will potentially help prevent your development team from creating something that is unusable by the authors, thus causing your devs to refactor or completely redo component work.

Part 2 will focus on some of the fundamental steps that we take when we begin the architecting process, by organizing/grouping each of the three types of components.

Special thanks to Kem Elbrader for assisting in writing this series.