Never.

Now that AEM integration is no longer part of my daily job responsibilities, I feel unburdened to let rip on my true feelings. Just to be clear, my opinions on this blog don’t reflect the views of any of my employers past, present or future. I should also qualify that for all my complaining, I’ve done a lot of successful AEM integrations so it’s not a completely useless product. Just one that I’d never recommend.

AEM, for anyone unfamiliar, is the Adobe Experience Manager. An enterprise CMS product offered by Adobe as part of their Marketing Cloud suite of products. It began life as a product called Day CQ which was a Swiss software company co-founded by Roy Fielding, the guy who coined the term REST and devised the principles of RESTful API design. It was designed alongside the Java Content Repository specification as a new standard for building CMS backends. It also latched on to OSGi which promised to be a new standard for deployment and scaling. None of that ever really worked out. JCR and OSGi faded away pretty quickly, so the dream of interoperability just died. While the platform is ostensibly leveraging some open source frameworks like Apache Sling, you’ll be forgiven for never having heard of them because AEM is the only time you’ll even see them in the wild.

While the Computer Science bona fides may seem appealing to the techie crowd, the product is marketed most heavily at marketers. It makes for a super slick demo with its drag and drop authoring UI and neat integrations with the rest of the marketing cloud like analytics and targeting.

So, here’s the reality:

For one, Adobe will never be upfront about how much of a lift it is to get from a paid license to a working web site. A typical timeline is 6 months and frequently more. For all its sophistication, AEM is also monstrously complicated. And complicated in a way that requires quite a lot of product knowledge to overcome your fear of the rats nest of XML configuration, the funky template language and endless piles of javadocs and egregious abuse of the adapter pattern. Aside from the aforementioned license fee, which is considerable, you’ll immediately be saddled with the need to hire AEM Developers to show you some “best practice”. While I have known some fine folks to fill this role and (it was my lot for a while as well) anyone who bills themself as a Insert Enterprise Product Name Developer is automatically two notches below a savvy generalist. Having knowledge of enterprise software arcana becomes a valuable resource that can paper over ignorance of programming fundamentals and general reasoning skills. Personally, I’ve had much more success training generalists on how to use AEM but it’s major tax on their productivity. Everyone who I’ve coached to sufficient competence don’t include it on their resume because they never want to see it again.

Once you’ve paid the fee and hired the team, you’re now very thoroughly invested. Time for step two, figuring out what you want to do and who is going to do it. Wait. Maybe that should have been step one. Shit, we’ve just committed a few years budget, so no time to second guess. We’ve got a product built for 2007-era vertical scaling, a page-oriented model for authoring that doesn’t match modern design principles, doesn’t integrate in any meaningful way with the rest of the marketing cloud, encourages complex workflows when we only want one-click publishing, and is subject to data corruption and latency. Hmmm.

So, step two. What do you need? For one, every business should know that customer experience trumps everything else. Know what you want your product(s) to do. At least in roadmap form. One site? Multiple sites? Apps? Messaging? Localization? Then think about governance and operations. How much content is product copy and how much goes to marketing channels? Who is writing content, who is editing or approving? What’s the business process? Who is going to actually log in to your CMS and who is just looking at emails and copy decks? Who actually has their hands on the CMS?

I’ve seen a lot of orgs whos eyes are bigger than their mouths when it comes to their digital marketing. Not just in terms of volume, but how much adoption of their CMS they can realistically drive internally. People whose job is product management or digital marketing don’t really want to waste brain cycles understanding a CMS. The drag and drop UI may seem really simple, but it’s masking a ton of governance complexity that can’t easily be communicated in a web form. If you’re trying to maintain a visual language and controlled vocabulary, it’s going to instantly frustrate anyone who isn’t immersed in it. And anyone who is immersed in it, doesn’t actually need the training wheels of paint-by-numbers or character limits on a form field. In reality, you’ll probably have a really tight funnel with a small handful of site managers with their hands on the keyboards. I’ve seen it enough times where we put together a dev team bigger than the editorial team. Sorry, but they asked a company whose job is to sell licenses and a company whose job is to sell billable hours and didn’t do enough of their own diligence. I personally try to be brutally honest with clients, but once they’ve sunk the cost it’s hard to pivot.

So, what’s actually a better option? WordPress? Well, maybe. But probably not. Headless CMS products like Contentful, Prismic or Amplience fit most workflows with a much smaller investment. Typically these products let you build out a content model that translates to simple form-based content entry and exposes an API. Some are a little more polished than others in terms of look and feel or value adds like DAM or intelligence around A/B testable content. This model is not only simpler, but it’s better aligned with how modern architectures are done. Aside from fitting nicely into a microservices architecture, it makes content federation to different channels that much easier and use any desired framework for building the all-important customer experiences.

And really, headless may not be far enough. You could even consider going bodyless. A static site generator like Gatsby lets you model your content on the fly in structured text file and manage them in a code repo. Let your content governance flow be managed over existing channels (email or JIRA or whatever) and just flow the actual site edits through a couple of junior devs or even power users. It’s 2020 and anyone can edit a JSON file and commit it. Think about the cost of retaining a few junior employees versus the cost of a CMS replatform. The license fees, the custom dev work, the operations, the onboarding and training. Especially if you end up (as I have seen at least a few times) where an enterprise goes though a CMS platforming project and still leaves all the content edits in the hands of a tech team. This should probably be the MVP approach for most organizations. Do this until you understand what you actually need to operate your products before you invest in something bigger.

That brings us to the apotheosis of the CMS maturity model which is to create something customized for your domain from the ground up. Most orgs may never reach this level, but if you really, truly have such a grand and broad content management vision and a business model that’s complex enough to justify it, then you should really go ahead and build something to fit like a glove. The cost of this approach is likely to be only marginally higher than trying to adopt a one-size-fits-all product like AEM and will deliver much better results. It will certainly require an experienced team of expensive developers, but if your business is valuable enough, then it will be a worthwhile investment.

Type of CMS Speed to Market Cost to operate Room to Grow
Static Fastest Lowest Low
Headless (ie Contentful) Fast Low High
Open source (ie WordPress) Moderate Low Moderate
Enterprise (ie AEM) Slow Highest Moderate
Fully custom Slowest Moderate Highest