The following features are most valuable:
- OSGi bundles capability
- DAM (Digital Asset Management)
- E-commerce capabilities
- Campaign management
- Components re-usability for making pages
The following features are most valuable:
Creating new pages that have similar aesthetics to existing pages does not require any new development requests. An author/user has many flexible options for making new pages. In addition, by adding new pages to an existing website, the author/user saves time and money.
You do not need to create new pages for different kind of products; a single page works for all product kinds and types, by using the same product template page like on the sample site Geometrixx.
Integration with MongoMk for storage, in place of TarMK, is not efficient. But if it becomes efficient, this improvement would solve storage problems for many of AEM's big clients.
I have used this solution for three years.
AEM, when setup using Mongo, rapidly gains size. Hence it consumes a lot of storage space in a very short period of time.
The initial setup is pretty straightforward, as it requires running a single .jar and deploying code and content into it. For production, the combination of author and few publisher AEM .jars, the dispatcher, and few AEM configurations needs to be fulfilled.
The cost can be high. But for large websites with a lot of dyanmic data like e-commerce, or for clients looking for user-data based campaigning, the solution can be very efficient in the long-term.
This product has a lot of valuable features.
From the business perspective:
Pages were very related to each other when it comes to behind the scenes JavaScript dependencies and their internal structure design. Content managers were not able to understand why they had to publish some extra related pages to the one just they wanted to publish. It is a problem of transitive JavaScript dependencies. This approach generated a lot of frustration. Actually, in my opinion, the concept of JCR should be hidden from content managers.
Memory leaks - yes that really impacts overall stability. Actually, it is the problem of zombie OSGi services.
No - it is better than ATG, Magnolia, etc. It is a first-in-class product.
Very very poor.
Yes - Magnolia and Joomla, Liferay, etc. I switched my working places and it was just the main product used in the department.
Setup of localhost dev. environment. Very complex. Actually you cannot start development alone. Somebody must introduce to the concept of Sling and JCR etc. Very, very hard intro.
CQ is very expensive. The licensing model is not clear.
CQ is expensive but the worth money. If you are looking for a free or cheap equivalent use Magnolia CMS. Very similar in the general design idea.
In general, we work a lot with software requests by our customers, mainly enterprise companies. Typically, our clients are in supplies and they require a complex web portal. They are demanding in terms of quality and usually prefer to work with Adobe and not with Drupal or other platforms because here in Italy, Adobe has a lot of commercial support. We manage a software factory with over 150 employees. We are customers of Adobe and I'm a chief technology architect.
I'm quite happy with the platform. It requires particular skills, so it's not so easy to prepare or find resources to specialize in it but with the right resource system and the right competencies, it's easy to work with.
The programming model could be improved, it's a monolithic solution and that's what we don't like. Some features are badly defined in the solution. It's difficult integrating so we're forced to develop other APIs in order to simplify things. It's a weak feature of the product.
Adobe usually don't want to speak to the integrators, they want to speak with the client. That's the approach in Italy. I don't know if the commercial strategy is different in other countries, but in Italy we had lots of issues when we tried to talk directly with Adobe. It's not so easy. Typically, any issues are inherent to knowledge about the platform. If the issue is that something is not working as expected, we usually discover the problem is linked to the fact that we don't know the platform well. That's when we ask for support and usually with some configuration, or by using the platform in a different way, we are able to fix or bypass the issue.
The initial setup usually takes somewhere between five and nine months. Typically these portals require a lot of time and in my opinion, implementation depends more on the type of projects, rather than the type of web content management system. We prefer to manage directly on the AWS environment, which our clients typically already have.
Adobe is a more expensive solution than, say, Liferay. But we don't like the portal approach in Liferay, it's quite old. We've worked on our portal CMS since 2010, so it's been over 10 years. In Liferay, the core is still based on portal frameworks which is a disadvantage because we know that to develop something with that model is quite expensive. In general, our employees are more familiar with Adobe and have more confidence using that solution.
I would rate this solution an eight out of 10.
With the improvements made in Assets 6.3 for synchronization and accessibility of product data and content records, information can be utilized in a wide range of different channels, including catalogs and other designed documents.
Using this product data, they can be inserted semi-automatically into materials that can be printed, emailed, posted on websites, etc.
I've used it for the past three years.
We have found occasional issues with stability, but those were in general caused either by custom developed code or issues in the implemented architecture.
When the application is installed in servers without the necessary requirements in terms of hardware specs, users may experience slow page loads and perhaps even systems not responding.
No problems with scalability.
Support from Adobe is good and responds in a timely manner. Their ticketing system works and is useful for getting to the bottom of the problems.
One thing to have in mind is that Adobe provides support only for the base AEM application, and not for custom code development to extend and/or customize its functionalities.
Being in a consultant company solely dedicated to Adobe CQ/AEM, this is not applicable.
Initial setup is very easy and straightforward.
The application comes in the form of a JAR or WAR file for easy deployment with various tools and systems.
Using the JAR, you can have the application up and running in five minutes, just by double-clicking/executing the file (it requires users to have Java installed, but that is a pretty common requirement these days).
Keep solution architecture easy to avoid unnecessary license costs. Start with the basic licenses to solve your immediate needs, and only increase them if the project really requires it.
I have worked with other similar solutions that solve parts of the complete set of solutions AEM provides, but none of them have the ability to handle so many of those areas in an integral way.
For Web Site and Content Management in general, sample tools are Drupal,
Joomla, and Wordpress.
Start small and plan your first set of objectives clearly, leaving all the “nice-to- haves” for a later phase.
Starting this way will help companies get a sample of the benefits, and get familiar with the tool in general.
After the first phase, they may find things that they thought they wanted are not really required or can be achieved in a better, more efficient way in the AEM world.
Another useful piece of advice is to avoid trying to re-create your current solution using AEM, and rather, try to look for new and different ways to achieve the same results that take advantage of AEM’s features.
It is helpful for hybrid applications, generic templates, third-party data synchronization, and user-specific data restriction and analytics.
It helps us with analytics, application design for specific platforms, and enables us to easily create applications for iOS and Android.
Hybrid applications and Cordova support.
With the default template design, it is difficult to manage the different resolutions of images.
One to three years.
I believe that the primary feature of the product is the ability and extent to which it allows authors to modify, build and operate their website, page components, etc. that otherwise would require a lot more of developer work.
We provide consultancy services to the clients so that our clients can use the product to improve their organization's operations.
The integration of the product with other Adobe Marketing Cloud products could be improved.
I have used this solution for around four years.
Usually, when integrating with other Adobe Marketing Cloud products, we encountered some stability issues, but those are already being worked upon by Adobe.
We did not experience any scalability issues. There are many options for designing the solution, depending upon the expected load/stress.
The technical support is active in responding but may take a while, depending on the complexity of the issue.
Setup is pretty straightforward and well-documented by Adobe.
The product was originally developed by a company called Day Software that was taken over, and then further developed by Adobe, changing its name from CQ5 to Adobe Experience Manager (AEM). Currently, the latest version is AEM 6.3.
When using other Adobe Marketing Cloud products with AEM, I would advise keeping short-term goals instead of going straight ahead to build something massive/complex. Furthermore, selecting an experienced and competitive consulting partner for the development goes a long way.
I think DAM (Digital Asset Management) is most valuable to me.
The data is increasing, and in order to manage millions of assets which a large enterprise has, it provides lots of capabilities (searching, reporting, managing, workflows for automation, etc.).
The other thing, which I liked about the product, is its extension point -- name the solution and it can be integrated.
Some of the prominent ones being Salesforce, translation services, and analytics products. It has OOTB Omniture integration.
We are basically a service provider. It has helped a lot of clients.
The areas where it is helpful were creating and managing multiple sites, and managing assets.
An organization has different divisions, business, etc. and this product helps in managing all those under one roof.
I love DAM, but still think there are improvement areas.
I have been using this product for the past six years.
Yes, we faced issues in one of the projects where we had 50 million users and each user had a lot of personalized pages. (This issue was found when I was working in the CQ Version 5.5, after that, I didn't have any such requirements.)
No.
Adobe provides good support.
If a client faces any issue, through the care account (access once a license is purchased), they can raise the issue and set the priority.
Adobe has dedicated people per client to look into those issues and provides solutions/recommendations.
No.
It is straightforward.
Installation is straightforward, even if somebody is new and he has to create a website -- he is provided with tutorials/sample site, which are great references.
There are different levels of licenses: Evaluate your needs and take the license based on that. In the future, upgrade it per need.
No.
The way it's stored is different from the legacy system, where we used an RDBMS-based solution.
Here, we have a file-based system and all information is saved on nodes. Also, keep in mind David's principle.
Can't comment on Ektron, but if you are looking for .Net integration from your CMS you might want to take a look at SiteFinity. It's not open source or particularly cheap, but for large enterprises it may be a better bet than betting the farm on open source (although that depends on your attitude to that so YMMV).