Setting the Record Straight on the Total Cost of Adobe AEM vs Acquia
As Acquia begins to compete more often with Adobe Experience Manager (AEM) in enterprise web content management selections, I'm coming across a set of common objections coming from prospects after they speak with Adobe. We’ve been told by multiple customers that Adobe had an “unbiased partner” create a total-cost-of-ownership (TCO) document to compare Adobe AEM vs. Acquia.
The TCO document claims a typical Drupal project costs nearly 70% more than Adobe AEM, with example three years' costs of approximately $2.4m for Adobe AEM and $4m for Drupal. I’ve read the document, and the total cost of ownership calculation makes hugely incorrect assumptions about Drupal in the areas of hardware cost and infrastructure, implementation cost, and support. For TL;DR people, here’s my takeaway:
Adobe’s sales team is feeling the impact of Drupal more than ever and is resorting to desperate and reckless tactics that undermine the credibility of everything they tell prospects about Drupal and Acquia.
If you'd like to learn more, read on!
This section of the Adobe TCO document lists out the hardware components needed to run Drupal and Adobe sites e.g. front-end servers and databases. The main argument is that Drupal requires additional database servers, software licenses, and support, while Adobe doesn't.
Adobe AEM is built on the CRX repository, a standards-based Java Content Repository that came to Adobe via its Day Software acquisition. The CRX repository comes with the AEM application and doesn't require a separate license. It's a slick architecture, and it’s one of the reasons that Adobe does well against legacy proprietary web content management companies like Oracle and SDL Tridion that require expensive database licenses and hardware.
But Adobe seems to think the same is true of Drupal — that Drupal requires over $100,000 of database software licenses and support to achieve what Adobe provides for free with CRX. But Drupal runs on the LAMP stack, which, like CRX, is also free. And when companies work with Acquia, we provide support for all application components, including the database, so there's no need for separate database support.
Not surprisingly, the TCO document completely ignores the cloud, because this is an obvious weakness for Adobe. Ironic, given Adobe AEM lives under the “Marketing Cloud” Adobe brand. While Adobe AEM can certainly be deployed in the cloud in places like Rackspace and Amazon, and Adobe does offer some management tools for deploying sites, the company doesn’t support the site itself. For example, what happens when your AEM site breaks because of a bad code deploy? Acquia provides total application assurance in the form of supporting the entire digital lifecycle of the project from development through testing and production.
When you consider the total cost to provide complete assurance of your Adobe AEM site, the costs skyrocket compared to what you get with an Acquia Platform subscription.
This section of the TCO document compares the total implementation cost of AEM vs. Drupal across different implementation roles including project management, development, and QA. According to the TCO document, building a “typical” Drupal site costs more than twice as much as Adobe AEM. Of course, there’s no such thing as a typical implementation of Drupal, Adobe AEM, or any web content management product. The scope of each project varies wildly based on the complexity of the requirements.
The additional costs of a Drupal implementation supposedly come from Drupal’s lack of base product features, which require lots of custom development, including multi-site management, mobile support, personalization, and dynamic content. Check the links for case studies that hit on each of those supposed limitations in Drupal. And of course there's no mention of the 20,000+ Drupal modules and distributions freely available from the Drupal community, which greatly help companies speed time-to-web and lower custom development costs.
Generally, I think Adobe AEM projects tend to be significantly more expensive, because Adobe targets the largest companies with the biggest budgets. In fact, according to this video from Adobe’s partner day (which I found on their YouTube page but has since been taken down), the average implementation cost for AEM is three times the size of the license, which means the total cost for an AEM implementation usually approaches more than $2,000,000 because their average license cost is around $450,000.
While it’s dangerous to make broad statements about “average implementations,” because no such thing exists and every project is unique, certainly the total implementation cost for most Drupal sites is far less than AEM. Why? Customers who evaluate Drupal versus Adobe AEM head-to-head quickly see that Adobe’s complex page-based architecture drives complexity, which is poorly-suited to the needs of modern, content-centric sites. With Adobe, every feature must be implemented from scratch. Adobe AEM is a complex Java stack, including JCR, Apache Sling, Felix, Maven, and the AEM framework itself.
There’s just no way Adobe can make a broad statement about the so-called “typical” implementation costs of AEM vs. Drupal. Every web project is unique, and I suspect in most cases Drupal costs far less to implement due to the availability of more than 20,000 Drupal modules and Drupal distributions, the availability and cost of Drupal developers, and the relative simplicity of the Drupal architecture versus AEM. But, really, the only way to know for sure is to work with the vendor or your implementation partner on a specific statement-of-work for your project.
In the TCO document, Adobe claims that Drupal support costs are high, mainly due to upgrades, product quality, and resources required to support Drupal once the site goes live. In fairness to Adobe, this was the section where Drupal costs were only ~10% higher. The primary difference in support costs comes from upgradability.
Upgrades in any content management system can be easy or hard depending on the amount of customization and underlying changes to the platform. This problem isn't unique to Drupal. In fact, Day Software had this same challenge moving customers from Day Communique 4 to CQ5 not so long ago.
But, to be fair, the upgrade process for Drupal between major releases always involves work: APIs change, platform architecture advances, features move from contrib to Drupal core. Drupal will never break your content, but its commitment to a modern architecture means that Drupal is willing to break some components to ensure the platform is modern and relevant and to eliminate unnecessary bloatware associated with rote adherence to backwards compatibility. But upgrades are about to get a whole lot easier in Drupal 8, which now includes a migration path from both Drupal 6 and 7 to Drupal 8, due for release later in the year. This is a huge milestone for Drupal and will smooth the upgrade process for customers going forward. Thanks to my Acquia colleagues and others in the Drupal community who contributed to this improvement in Drupal 8!
Adobe seems unwilling to do the hard work it takes to articulate their competitive advantages over Acquia, instead taking the lazy approach of letting a partner produce a wildly inaccurate TCO comparison based on the perception that it was unbiased when it was clearly engineered by Adobe to tell a story that simply isn’t true.
Truthfully, both Acquia and Adobe AEM are great platforms, but each has strengths and weaknesses that require proper consideration before making a selection. You’ll live with your new web content management system for many years, so selecting the wrong one for the wrong reasons could set your digital strategy back for many years. I’d hate for companies to eliminate Acquia because of the wild inaccuracies found in this TCO document. Our approach when competing against Adobe AEM is to encourage customers to directly evaluate each product against their use cases.
If you’d like to take a closer look at what the Acquia Platform can do for you, I’d suggest starting with a product demonstration.