Adobe CQ and Digital Eco System - Deep Dive

Introduction

             This article is written as an analysis note/ whitepaper on Adobe tool capabilities in Digital Marketing landscape.

Opportunity

Ø  Unified Eco system orchestrated among most Adobe Digital marketing tools and cloud solutions

Ø  Adobe is building newer set of components suited to Digital Marketing for B2C ( i.e. granite) as most of the default and demo components are just scratching the surface for enterprise needs

Ø  By far the best UI component model in Java as its modular ( learning's from eclipse components) and standards based ( JCR and OSGI )

Challenges

v Many tools are not generic or time tested in terms of implementation volumes

v Understanding of scenarios and standardization ( from the domain and sub-domains) is needed for identifying and building the right set of components for the enterprise

v Building re-usable, extensible UI components needs expertise

Impact for Industry

Ø     Shorter cycles for Digital marketing roll-outs targeting niche trends/events in the market.

Ø    Clients and Vendors with a base and advanced set of components will have an edge over other product and enterprise teams.

Ø     As long as the components stick to JCR and OSGI standards, inter-operability against other JCR based vendors is guaranteed. This will serve the long term interest of avoiding vendor lock-in in larger engagements.

Standards Based Content Management Roadmap

Oracle View

“The Content Repository API for Java Technology (JCR) is poised to revolutionize the development of Java EE applications in the same way that the Web has revolutionized the development of network-based applications. JCR’s interface designers have followed the guiding principles of the Web to simplify the interactions between an application and its content repository, thus replacing many application-specific or storage-specific interfaces with a single, generic API for content repository manipulation. “

IBM View

“Most importantly, JSR-170 (Content Repository) has strong support from industry leaders, including SAP AG, Macromedia, and IBM, establishing its use and importance in the enterprise landscape. Just as object-relationship mapping frameworks transformed database programming, the JCR API has the potential to dramatically change the way we think about and develop content applications”

Adobe View

“CRX natively manages all content as defined in the Content Repository for Java Technology API Version 2.0 specification - also known as JCR 2.0. This programming interface - defined by the ECM industry - provides developers with a stable and well-defined, yet extensible content and query model that protects past and future investments.”

  

Adobe CQ - Whats in it?

Caching

•       Predominantly static page – e.g. Marketing Information which is authored. This is cached at the dispatcher level and any updates are pushed to the webserver on a need basis by the publish

•       Static set of variations in dynamism – e.g. a different type of menu system for various device groups namely tablets, features and touch phones. There is a querying parameter for the url but it’s a closed set which can be cached with the parameters. The dispatcher and publish has a protocol on which page is cached and how many variations. i.e if the selectors defined for the page and template are the only differences in the multiple URLs, dispatcher can cache these as individual files and serve them with the help of sling url resolution methodology.

•       Dynamic Business Logic - Predominantly dynamic but there are author-able configurations which change rarely (2 days to 6 months range).     For e.g. Login/Registration, Marketing widgets, Social feeds (periodic). In these cases a CQ component handles static configurations and brokerages with a service (J2EE or other) to serve the request. There might be internal caching strategies built at the service level also (Facebook feed updated every 15 min).

•       OLTP Modules - Explicit dynamic use cases which would place enormous processing load on the publish server are better run out of an application server or commerce server. This again depends on multitude of factors but for most B2C/corporate implementations where performance and scalability is a critical factor above rule applies de-facto.    For e.g. shopping cart, complex search widgets etc

•       Others -

§     Permission-sensitive caching enables you to cache secured pages. Dispatcher checks users' access permissions for a page before delivering the cached page. This is a rare usage today as CQ is sparingly used in B2B space. For e.g. in a B2B portal the entitlements of a user or a group is maintained (dispatcher is user aware) but individual pages are also cached for performance

§     Adobe is building/improving capabilities like Page personalization, Forms, Rules engine, shopping cart etc. Hence, in future versions, CQ might have application server capabilities with a robust servlet engine complemented by a layered caching strategy already in place. This makes the case strong for fronting Adobe CQ as a UI delivery engine and delegate specific advanced features to other systems in the interim.

Performance and Scalability

• Adobe suggests 90% caching of web pages whereas in real world most applications are only 60-70% cached. This is because most re-engineered applications are from other OLTP technology stacks (.NET and J2EE)
• By practice, it’s perceived that Adobe’s infrastructure sizing guidelines are 50% short when caching is 60-70% particularly during email campaigns.
• Clustered Authors has never been a practical solution unless the authors are atomic in terms of functional composition. May be we might need a global author for common content too. The content orchestration / federation has to be planned and governed for this to work. Simply put, it’s not advisable to suggest clustered author as of today unless there is a clear use-case
• Repository sizes of more than a TB needs Adobe’s ratification as of today from a practical standpoint  
• It is suggested to have twice the repository size as a disk free space for emergency backups. Adobe repository uses file system for storage and works like a large file system or SVN. Cold backups are the safest in this context.
• TAR-PM services (similar to versioning/rollback services) are not effective and they need large maintenance periods for large repositories. 
• Governance for content cleanup is a core issue for large repositories.
• CDN like Akamai is critical for campaigns
• Brainstorming cache-able use cases vs. others is critical for Project/Program Success
• Size of images, JavaScript is crucial for Tablets and Mobile
• Responsive design if chosen should be designed effectively as it might affect performance in the Mobile world
• User Specific sessions are not to be used unless its B2B/Intranet portals. Also, usage of CQ in B2B/Intranet is sparse

Security

• Author vs Publish mode is not out-of-box. This configuration is not fool-proof and needs meticulous planning and execution.
• Lots of security loop-holes in workflow management found in earlier versions. These have been closed in 5.5 but sufficient care must be taken in security architecture.
• Un-Moderated workflows for User generated content are not advised. 
• Session to be managed using customized encrypted session token over SSL
• Author is still a single point of failure in most topologies and hence should not be exposed without a VPN tunnel.
• Tripod firewall is not enough. DMZ between 2 independent firewalls is suited to host the webservers or another secure reverse proxy
• REST web services have become the order of the day. But the security considerations have to be brainstormed. For B2B usage within the same Hub (firewall), this is acceptable. In all other scenarios, the industry standard infrastructure security guidelines and legal compliance steps for partnerships should be enforced strongly. 

Conclusion

Adobe’s Digital Eco system is in its take-off stage.  A careful analysis of needs and strengths would help organizations to choose products and partner with right set of cloud vendors in this tricky landscape.

Note: The views expressed here are Author's personal views on product/tool  capabilities and are to be considered as neutral from any commercial standpoint. The reader is advised to consider this for informational purposes without assigning any commercial value to it.