What is CQ5?
CQ5 is Adobe’s flagship Content Management System and the leading CMS in the market. Like any CMS you can use it to build and maintain your web presence, but more importantly you can use it to capture your online visitor behaviour and convert customer interest into sales. It works on multiple platforms (so its totally compatible with browsers, ipads, smart phones etc) and it uses the latest HTML5 technology, so it looks great.
What’s so good about it?
It seems that Day Software, from whom Adobe bought the platform, just got it right. Developers report that its easy to use, it’s powerful, it’s scaleable, it integrates with 3rd party systems well, it deploys nicely, the list seems to go on and on. But I think from a market perspective it’s so popular because 1) it uses HTML5 (so visually it looks great) and 2) it does all the things that top ecommerce companies like Facebook do (under the guise of “community engagement” and “customer experience” etc); so most importantly its an easy sell to business heads and CEOs.
The technology:
CQ5 is a Java-based CMS, and by making it multi-platform it’s taken Java’s “Write Once Run Anywhere” philosophy and applied it in a modern setting. The stack is essentially JSPs and HTML5 but it also uses Sling and JackRabbit, and it sits on an OSGi service platform.
The Past:
CQ5 was written by Day Software in Basel, Switzerland, and was the application side of their Enterprise Content Management offering (the infrastructure side being called Day CRX). CQ die-hards will tell you that in the early days (until about 2005) the platform was written in server-side JavaScript, but the most interesting thing about the history of CQ is its identity complex:
The Many Names of CQ (in chronological order):
– Day Communiqué WCM
– Communiqué
– Day Software’s CQ
– Adobe CQ
– Adobe WEM
– Adobe WCM
– Adobe Experience Manager or AEM (now its current manifestation)
The Present:
CQ was bought by Adobe mid 2010 but the market for CQ (and so for CQ developers) really kicked off in 2011. It came into my sights last year when I noticed that big companies like IG Index and Nike were using it, since then it’s increasingly been picked up by global banks and wealth managers – obviously Adobe came along and its fortunes quadrupled.
The cost is one thing to note however, as the license is notoriously expensive and because many companies’ CQ experience starts out with specialist consultancies, that cost is multiplied even further. Interestingly there is an Open Source (read “free”) CMS by a renegade Day team called “Magnolia” but despite also being Java-based it remains a commercial nonentity.
The Future of CQ5 and “Will Adobe Kills its Golden Goose?”
Adobe is busy adding new functionality to their “AEM” – by integrating it with their already extensive software suite – in an attempt to maximise the commercial return on its current popularity. Which makes you wonder how long it will be before they start to close down its open source compatibility and lock subscriptors in to only using their branded products. It also makes you wonder how long it will be before so many Adobe products have been integrated into the platform that they start to kill it through “bloatware”.
Many developers tell me that they suspect Adobe’s constant name changing is a result of their failure to actually understand what CQ’s market is, and why it is a commercial success. The latest name is “AEM”, and if they aggressively push this and seek to push out the “CQ” brand they are going to damage their brand recognition and lose customer loyalty – which is going to make it much easier for the next competitor to push them out of the market.
Martin Jee's blog 
I approached an Adobe guy about a position outside the “mothership” and although he wasn’t interested, he did come back with the following comments on this post – which I thought were worth sharing:
“I read your blog post on CQ with interest, by the way. A few points worth commenting on:
– Adobe bought Day, not the platform. The platform was thrown in for free as part of the acquisition 😉
– “notoriously expensive” only works in the context of up-front costs; TCO will be significantly less than many other systems, and that’s before we factor in ROI…
– you say bloatware, we say leveraging the Adobe advantage! It’s definitely worth taking a closer look at the Marketing Cloud strategy. Breaking down silos and allowing people to seamlessly work with all the Adobe solutions is a winner – no more expensive integration efforts required in order to make use of the best tools.
– I couldn’t agree more about the name changes, but bear in mind AEM is a combined solution, from the products CQ + Scene7 + DAM. CQ is alive and kicking as a technical brand for the engineers.
Thanks,”
“you say bloatware, we say leveraging the Adobe advantage! It’s definitely worth taking a closer look at the Marketing Cloud strategy. Breaking down silos and allowing people to seamlessly work with all the Adobe solutions is a winner – no more expensive integration efforts required in order to make use of the best tools.” – That sums up a large enterprise’s attitude to developer tools; use everything we offer or use none… er, I think you’ll find we’ll use none if you’re locking us into one solution.
cq license is very very expensive.
setup is not so easy: easily proved by seeing even majors doing massive setup mistakes like letting debug flags enabled (try adding a GET parameter debug=layout to well-known CQ powered sites). Also miss configuring the dispatcher so more or less private parts of the java-content-repository (jcr) stay accessible for manipulations via their REST-API is very common – sorry, no more details about that 😉
the various “marketing-cloud” tools in fact do not integrate very well, that’s IMHO just marketing bogus form the adobe people – let’s see, if and how they change that in the future.
on the developer site, it’s a good collection of many things one should avoid: just one example: out of the box just plain jsp and no templating language. an other problem is the very complex node structure of the jcr: some times it’s names that matter, sometimes types, not very clearly thought through… but you’ll often lose you head while adding nodes over nodes with properties over properties and no clear debug…
adobe’s employes (ex-days) themselves admit having made bad design decisions – I agree.
the ui is currently not very well integrated: the tools look and feel like they do not really belong together, except for the repository’s tree on the left 😉 – might be, this is due to the fact, that Adobe is rewriting the whole UI at the moment (v5.6), making it more modern and compatible with touch devices. they even switch the ui-framework from extjs to something home brewed…(they call it “coral” or something).
on the other hand for an editor, generating and editing content is easy. the sidekick (component browser) usually works like a charm – dragging and dropping content elements is quite fun in CQ – developing them is not in particular. CQ editors don’t need to be brainiacs, training them is easy. But handling big content, live-copies, reference-masters and references, workflows and that kind of stuff, you’ll come to the brain-twisting part, and leave most of the normal minded-editors behind – that’s IMHO not because of their mental capabilities but because of the way CQ handles content in a repository with tons of nodes, paths and properties.
I could go on…
… for they money, you’ll have to invest just in a CQ license, you could deploy a minimum of 5 developers for a year… think what they could do with modern rapid development tools and frameworks… you’ll need these developers anyways regardless of using CQ or something else. You’ll need an agency and a support contract with Adobe… TCO of CQ is high in the clouds.
So much, best,
so what is the Conclusion??
Me being a developer worth knowing cq5 (AEM or what so ever) ??
rgds,
Sandeep.K
good overview of cq5, thanks
It is hard to describe just how inaccurate this article is. It appears to have been written by someone who is either marketing CQ or who has never actually implemented a project in it. CQ5 was notoriously complex to develop in. Everything is problematic due to levels of abstraction and the editing capabilities are so strikingly primitive for such an expensive solution, this is mainly due to the horrible CRXDE Lite. AEM 6 has significantly improved various areas of CQ5, most notably the templating is now based on HTML5 and JavaScript, a definite improvement for UI guys who previously had to struggle with the complexities of embedding markup into JSP. Either way, AEM 6 is far from a silver bullet solution. This will be realized by every stakeholder who wonders why their deadlines are being missed; why the end result looks no more remarkable than cheaper competing solutions and why the availability of developers to maintain the solution are always thin on the ground.
Excellent blog. Excellent overview. Thank you again Martin
Thank you for giving good information about Adobe cq5 technology.