15 Years of Adobe Experience Manager - A History

As of today, it's been 15 years since Adobe finalized the purchase of Day Software, thus acquiring the product you all know now as "AEM".

For any of you out there who (like me) have been working with this platform for years, hopefully this post should be an entertaining (or painful) trip down memory lane for you as we revisit why Adobe would have purchased Day, and what has changed (and hasn't!) in the 15 years hence.

Day Communique - before the Adobe Takeover

Day Software was a Basel, Switzerland-based company which created their breakthrough Communique CMS on a custom filesystem-based platform, but then later morphing into the Java Content Repository-backed system we know today.

The first version of CQ was a collection of CGI scripts for Netscape Enterprise Server (hands up if you ever used that one!) in early 2000, and was rewritten as a Java application for CQ2 and then the HTTP server separated out of it for CQ3 (the genesis of CQSE).

Up until CQ4, content was still stored in files on the local file system, but in 2005 with the release of CQ 4.0, was switched from the older "Content Bus" filesystem storage to the "Content Repository eXtreme" (or CRX) repository version 1.0, an evolution of which still powers AEM today - 20 full years later.

CQ5 was a MASSIVE UPGRADE & the Foundation of Today's AEM

CQ5 represented an almost-complete rewrite of the product.

There are a number of features & approaches that might seem commonplace today that were huge and revolutionary parts of the CQ5 platform. A charming CMSwire article from 2008 noted "While some CMS vendors shy away from Web 2.0, thinking the Web 2.0 implosion is imminent; Day focuses on it big time". How many people of that day & age could even define web 2.0? But huge new features released with CQ5 essentially made it an entirely new platform, and most of us couldn't even imagine a CQ/AEM without it, such as:

• The Sidekick & Author UI: the GUI and WYSIWG authoring of CQ were a huge selling point at the time, and the fact that you could work with components in a graphic-rich environment was a massive step up over other CMS offerings at the time.

  

• Workflows: The workflow engine was added with this release which was also blowing people's minds, in that you could visualize a workflow RIGHT IN THE CMS, and develop business logic right into your content management system. I can imagine this feature alone sold a lot of enterprise clients on moving to the system

  

• CQ Tags: Can you imagine working in CQ without tags? Adding tag support finally brought full-featured taxonomy to CQ.

• The DAM: CQ5 got a digital asset manager with this release, located in the /content/dam path we all are so familiar with now. Even in this early era, it brought browser-based (not Flash!) image crop & rotate.

  

• Clustering: This is something that only lasted through the CQ5 release and did not make it to AEM6, for better or for worse. CQ5 had fairly advanced clustering which allowed a hot active-active or active-passive clustering setup for both Author and Publishers. I saw precisely one customer use Publisher clustering, it was a terrible idea and I have no idea why they did it. Author clustering WAS however a good "idea" allowing one to theoretically author on a cluster master and have those edits propagate over to a cluster slave (terminology that's been retired). Clustering, however, was always a MASSIVE reliability headache.

• CRX Development Environment: At the time, Day released an Eclipse-based devlopment environment for you to work in to have a thick, client-side view into the Java Content Repository. They also released a lightweight browser-based interface which could be used in lieu of Eclipse called "CRX Development Environment Lite" or crxde, which still survives to this day in almost the exact same form.

Not new to this version, but worth mentioning - the separate authoring & publishing tiers of CQ made it so performance constraints or instability on the authoring end did not take down your public-facing site, and vice versa. Having CQ sit on the foundation of OSGI and Sling meant a massively-flexible content engine, capable of both rich dynamic responses and page rendering, as well as the ability to plug in heavy-lifting in Java for all manner of applications that previously might have had to run in their own application server stack.

A Timeline of CQ Releases & Changes

Up to the Adobe acquisition, the CQ version history went like this:

• Day CQ 3.5 (2002)

• Day CQ 4.0 (2005)

• Day CQ 4.1 (2006)

• Day CQ 4.2 (2008)

• Day CQ 5.0 (2008) - only released to internal customers as a preview

• Day CQ 5.1 (2008) - first general-availability release of CQ5. First addition of Workflows, DAM, Tags, CRXDE, Clustering and the Sidekick

• Day CQ 5.2 (2009):

  • Enhanced Digital Asset Management (DAM) with improved metadata handling
  • Workflow engine improvements for content processing
  • Better integration with Adobe analytics
  • This is where Multi-Site Manager (MSM) was first released upon the world.

• Day CQ 5.3 (2010)

  • Introduction of Communities features for social collaboration (and as a note AEM 6.5 LTS only JUST finally deprecated and removed this functionality!)
  • "Site Optimizer" for A/B and multivariate testing (we'll be hearing THAT name again soon)
  • Enhanced translation workflows and internationalization support

The Adobe Acquisition of Day Software & CQ

Adobe announced in July 2010 that they were going to buy Day Software, and with it the CQ product. Adobe was already running their own website on CQ at this point, and given their brand-new focus on building out a marketing technology line of business, it made sense. Adobe had just acquired Omniture in September 2009 for $1.8 Billion, and Scene7 in 2007 - so it was clear that Adobe was starting to get serious about something more than just their creative software business.

The acquisition by Adobe was completed in September 2010 for $240 million dollars in an all-cash deal, 7X cheaper than what they paid for Omniture - which was quite a steal when looking in hindsight.

Not sure about you, but I remember exactly where I was when the deal was announced. I was midst running CQ 5.2 for AARP at the time (they had been on CQ since CQ 4.2). CQ at the time for me, was equal parts "massive headache" and "is this where CMS is going?" given that we were still trying to figure out what services should stay on JBoss and which could just as easily run inside CQ5 now that CQ had such a robust Java application server framework.

But PURCHASED BY ADOBE NOW?? This changed all the math for me on whether or not to keep investing time into learning CQ5, because obviously with Adobe behind it, it was likely to HAVE LEGS. And that it did!

"Day Software" branding inside the app was shortly changed to "Adobe CQ", though everything else remained the same, for the most part.

• Adobe CQ 5.4 (2011)

  • CRX2 repository for improved performance and scalability (this was my first major CQ project, a repository migration upgrading from CQ 5.3 to 5.4)
  • Enhanced social features and community management
  • Better mobile authoring capabilities

• Adobe CQ 5.5 (2012)

  • Connectors to Adobe Creative Suite, Scene7, and Search&Promote
  • Direct mobile app authoring
  • Partnership with Hybris for eCommerce integration
  • Undo/Redo functionality in editor
  • Content Fragments first made their appearance here as well as a custom development for a customer I was working with actually, and later released as a feature pack.

Re-Branding to "Adobe Experience Manager"

Adobe knew this wasn't going to be called "CQ" forever, so they tried a few aborted re-branding attempts, first calling it "Adobe WCM" and then "Web Experience Manager" for a bit before settling on calling it "Adobe Experience Manager". It was midst the 5.6 release that the login screen switched, and you now saw "Adobe Experience Manager" when you logged into CQ.

• AEM 5.6 (2013)

  • TouchUI is introduced for the Author environment (how many applications do YOU know that are STILL using ClassicUI?)
  • Mobile site and apps support
  • Improved personalization and targeting
  • Enhanced DAM with video profiles

• AEM 6.0 (2014)
  AEM 6 was a SIGNIFICANT rewrite of a lot of the underpinnings of AEM. For any of us in the business CQ5 -> AEM6 migrations took up the vast majority of our time as these were VERY labor intensive.

  • AEM 6 switched out the underlying repository from Apache Jackrabbit to Apache Oak, requiring a large-scale migration.
  • CQ's active-active clustering was no longer available, though Adobe did introduce the MongoMK storage backend for AEM which could theoretically (at this point in time VERY THEORETICALLY) provide horizontally-scaled AEM Authors. However, it was extremely buggy and our only implementation we did on this ended in disaster and a pivot to a TarMK single author
  • Larger footprint of TouchUI for most pages
  • Smart Tags for assets

• AEM 6.1 (2015)

  • Lots of bug fixes, but 6.1 was still not a particularly stable release.
  • Vanity URL support appeared in 6.1
  • ContextHub for personalization
  • Mobile App SDK
  • AEM Communities is introduced, and along with it, a host of infrastructure and storage options for user-generated content. Improvements would be made to this over time, but it unfortunately does not survive the move to Cloud Service.
  • AEM Desktop App was released for 6.1, I managed to 100% DDOS an author environment with this app :(

• AEM 6.2 (2016)

  • Many more bug fixes and stability improvements - still not a particularly stable release, but VASTLY better than 6.1 or 6.0.
  • Widespread content fragments introduction (it could be done via feature pack before, but is now part of the product)
  • SSL support inside of AEM
  • UI changes to how we're used to it now - with nav moved to the top from the side rail

• AEM 6.3 (2017)

  • Core Components is introduced as "production ready".
  • Large underlying storage improvements on 6.3 finally make this the first very-stable AEM 6 release. This was the introduction of the separated datastore and segmentstore and a reliable mechanism for online version management (tar compaction).
  • Experience fragments are introduced
  • The Single Page Editor (SPA) is introduce for single-page apps.
  • "Adobe Sensei" starts permeating AEM Assets as Adobe's AI branding, with what were (at the time) pretty ground-breaking pieces of AI functionality. Smart-cropping, smart-tagging, etc made their way into Assets.

• AEM 6.4 (2018)

  • 6.4 was the first round of "repository restructuring" designed to make upgrades easier, and eventually pave the way for a move to Cloud Service.
  • Workflows moved to TouchUI
  • A number of improvements to translation services
  • Video Smart Crop in Assets

• AEM 6.5 (2019)

  • Lots of repository restructuring
  • Connected Assets gave a potential option for connecting remote assets environments to a separate AEM Sites environment. Only works for images though.
  • Huge improvements to the SPA editor
  • GraphQL for commerce
  • And, since 6.5 has now been alive for 6 years (the longest of any AEM/CQ version to date!) there are a TON of new features that have been released via service pack. We're on Service Pack 23 at this point, and a rollup of all of the new features that have come out since 2019 deserves its own blog post.

• AEM as a Cloud Service (2020)
  First teased at adaptTo() 2019 (most of us didn't know what we were really looking at, at this time!) AEM as a Cloud Service was released to the world in January 2020, and would have taken center stage at Adobe Summit 2020...if there had been an in-person Adobe Summit in 2020. More's the pity. AEM as a Cloud Service was created to solve a number of AEM & CQ's long-time shortcomings and has had varying success in doing so, really resulting in the landscape of AEM offerings that we have today. What it offers is:

  • A full service-based AEM environment in the cloud
  • Auto-scaling on the author & publisher tier
  • Built-in CDN
  • Massively updated workflow & data-ingestion capabilities with microservice-based asset ingestion engine
  • New search capabilities, with AI-enhanced (RAG-based) search having just been released & talked about at adaptTo()

• AEM 6.5 LTS
  Variably-named as "AEM 6.6" or "AEM 6.5 LTS" depending on whether you're talking to engineering or marketing folks, 6.5 LTS is the long-term option for folks who are planning to continue to self-host or AMS-host their AEM 6.5 workloads after 2025. Java 11 is soon to be end-of-life, so running AEM on Java 17 or Java 21 is the only option.
  
  This is, for sure, the last remaining TRUE SUCCESSOR to the full product that came out back in 2009, as so many parts of it (i.e. /crx/packmgr and /crx/de and /etc/replication.html and so forth) are almost EXACTLY the same as they were back at the original CQ5 release.

• Edge Delivery Services & DA
  What's the future of AEM? Arguably, the functional as well as "spiritual" successor of AEM for the future is going to be Edge Delivery Services on the delivery tier, and Document Authoringon the content-management and author-enablement tier. This is absolutely up for debate, but DA makes a very strong case for the direction AEM will be taking in the coming years.

About the Author

Like what you heard? Have questions about what’s right for you? We’d love to talk! Contact Us

More AEM Articles You Might Like