Tips for Building an Effective and Efficient Enterprise Adobe Experience Manager Platform
Content Management System (CMS) platforms such as Adobe Experience Manager (AEM) are purchased by enterprise organizations looking to empower their brand and business unit marketers to create first-class digital experiences with reduced maintenance costs and dependence on IT. However, many organizations find themselves experiencing the opposite, with development and maintenance costs steadily increasing over time as their CMS becomes a Frankenstein of hundreds of components and IT once again becomes a bottleneck.
Building a clean, maintainable AEM platform in support of a single site is pretty straightforward. Without proper planning and business goals, however, enterprises consisting of multiple brands and business units often see what started as 40 components and 8-page templates multiply into 400 components and 80-page templates. Website updates become constrained by IT as simple fixes take days to regression test and new components and templates are loath to be added to an already complex system. The dreams of an enabled marketing team with limited dependence on IT are all but shattered and stakeholders are left with a simple question, "What happened?"
An enterprise AEM platform implementation can be likened to an apartment shared by roommates. The base amenities—kitchen, bathroom, sinks, and toilet come standard before the roommates even move in, and every roommate expects to use and share this base apartment "platform."
Beyond that, however, the roommates must decide how to share the costs and use of optional furnishings. It makes sense for each roommate to purchase their own bed to sleep in at night, but what about living room furniture? If one roommate prefers a recliner, and another prefers a couch, does it make sense to buy both, or would a couch with reclining end chairs satisfy both needs in a single piece? And just because there are four roommates with their own budgets, does it make sense to have four individual televisions? Or could the roommates split their budgets, one buying a TV while the others buy a table, chairs, and microwave to provide a lifestyle that no one of them could have afforded on their own?
Efficient and effective AEM platforms are rooted in sharing. Of course, it's easy to see the increased upfront dollars spent creating 400 unshared components versus 100 sharable components, but also consider the untold incremental dollars spent year after year supporting such an immense implementation. Sure eight brands with 50 components of their own get everything they want initially, but is it really worth 2-4x maintenance costs when aggregated across the enterprise? Perhaps even more sadly, all eight brands could have had 100 components if they were only willing to share.
Think this is all just pie in the sky, something that can't be accomplished at enterprises in the real world? Check out one of our recent AEM case studies, launching eight highly individualized brands with their own design teams and agencies of record (AORs) for a multi-billion dollar CPG enterprise.
At Bounteous we've helped numerous enterprise customers get the most out of their Adobe investment. Below are some of our tips on how to accomplish a thriving, maintainable AEM ecosystem.
Tip #1: Start With the End In Mind
I know it's a cliche these days to "start with the end in mind," but sharing components in AEM doesn't just happen automatically. Oftentimes brands and business units (BU) have their own thoughts on what a website should be like, and even their own design agencies of record (AORs). There need to be enterprise-wide goals of component reuse and platform maintainability, else designs will naturally result in components that cannot be rectified with each other for a shared set of components.
Tip #2: Think Core First
The road to a consolidated codebase appears to have two paths. One path requires deliberate planning and design discipline to work with and expand upon a common set of components to support brand and BU needs. The other path allows brands and BUs to build what they want in the short term, with the intention to find the commonalities and consolidate them down to the core later.
The problem with the second path is that it's a mirage. Once three or four separate carousels are built, each about 80-90 percent the same but still 10-20 percent different, and each in active use on their respective sites, it's a pipe dream to believe that anyone is going to spend the time and money to go back and consolidate those components. Starting from a single "core" carousel and layering on options for different brands and BUs is the only way to ensure consolidation is more than a conceptual goal.
Even with a mentality of core-first components, a common temptation is having only basic core components, extending those components with variations that live in BU and brand-specific code repositories. The ill-fated intention is to reap the benefits of code sharing with core components while still allowing unrestricted flexibility. The end result, however, is effectively the same (and sometimes even worse) than foregoing core components altogether, where code is largely duplicated across brands and BUs resulting in all the same problems that core-first components are meant to get away from.
Tip #3: Build Higher Budget Sites First
Oftentimes certain brands and BUs in an enterprise portfolio have higher marketing budgets than others. Requiring these sites to adhere to a set of common components could be viewed as an unacceptable constraint. Furthermore, updating simple components to support complex variations is inherently more risky than updating complex components with simple variations.
For all these reasons, having higher-budget brands and BUs built onto the platform first can be a way for the enterprise to get the best of both worlds. High dollar entities in the organization build out the initial library of highly stylized and flexible components to pixel perfection while allowing the more budget-conscious groups to migrate to the platform later at a fraction of the cost.
Tip #4: Leverage an AEM Living Style Guide for Designers
If you're going to expect designers to start from an existing set of components and variations, you need to also provide the tools to enable that approach. Most people are familiar with a design "living style guide" but we encourage you to take it one step further by ensuring your component guides are truly "living" by implementing them with your real components directly in AEM. This ensures your component guides are never hypothetical, never out of date, and always available to everyone involved in the design process.
For an example of what this can look like, check out the style guides enabled by Activate, our AEM accelerator with out of the box support for multiple brands:
Tip #5: Develop Code "the AEM Way"
Highly featured platforms such as AEM come with an inherent level of expertise required to implement well. Recent efforts in the industry (e.g., "quick sites") have been made to simplify the platform for less equipped implementation teams. However, whenever you stray from the path of full-on implementation "the AEM way" you naturally reduce your options for extensibility and reusability of code and/or components. You also set yourself up for increasing maintenance and upgrade costs as the platform evolves away from custom or over-simplified solutions.
No sponsor has ever won the Kentucky Derby by purchasing a thoroughbred and having a casual horse rider be the jockey—in fact, that would be scorned as a wasted investment. AEM is your thoroughbred, but if you want to realize the full value make sure your "jockey" is one of the best implementers in the world.
Tip #6: Own the Code
As a matter of course you'll want to leverage as much code and components as is freely available for your starting point implementing on AEM. However, beware of solutions where the initial implementation or MVP relies heavily on WCM Core components or an AEM accelerator library. This is a highly technical topic that warrants a discussion of its own, but suffice it to say that endearing yourself to a component library will greatly hinder your options to ladder into a library of complex, flexible, consistent, reusable components.
But wait, isn't Bounteous' Activate an accelerator, furthermore built on WCM Core components? Indeed it is, but Activate is not a "library" at the code level. The key difference when going with Activate is that you own the code—all of it, and that makes all the difference.
It's Never Too Late To Start
Now that we've established how to create a thriving and maintainable AEM ecosystem, remember that it's never too late to start. If your AEM journey got off on the wrong foot and you relate to the problems described at the top of this article, take the steps to clean up your existing ecosystem using our principles shared here. Otherwise, if you are new to AEM, utilize this guide as you begin your exciting journey!
