Tag Archives: CQ5

The Experience Architecture

In my #AdobeMAX session today, I presented a set of experience architecture principles with my colleague Marcel Boucher as follows:

I’ve gone into greater detail about these principles in a technical white paper that is available from the Adobe Enterprise Developer Center as a PDF download.

During our session, Marcel presented two demonstrations:

  1. The first demonstration featured an overall vision for customer experience in the retail banking domain. If you weren’t able to catch this demo live, you can see it presented here during the FinovateSpring 2011 event.
  2. Marcel’s second demonstration provided more of the how behind the vision in terms of Adobe’s integration across its Web Experience Management (WEM) solution, SiteCatalyst and Test&Target. A video similar to Marcel’s demonstration of this integration is available here.

MAX is always a great event, and the enterprise team at Adobe is looking forward to sharing more with you about Digital Marketing at our upcoming summit in March 2012.

Cloud first, mobile first, social first

The Adobe® Digital Enterprise Platform (ADEP) Experience Server supports WAN clustering (important in high latency situations and given distributed infrastructure), hot cluster join (allowing you to expand infrastructure on the fly), and runs in a very small memory and CPU footprint. This makes the Experience Server suitable for deployment in the cloud, whether actual deployments are done there or on premise.[1]

Explosion of mobile devices

In pursuing interaction patterns, ADEP starts its approach with mobile devices (particularly tablets) and then expands to consider other environments. ADEP can detect over 17,000 devices,[2] enabling content contributors to understand exactly what experience will be delivered to segmented content consumers via device emulation support. ADEP presents the concept of device groups to reduce the complexity and managing the diverse range of never-ending devices and device types.

Direct service of one may indicate subsequent service to others

Today’s customer increasingly leverages social activities to gain validation of their decisions and to share them with others. ADEP supports a range of social capabilities including support for local communities and the ability to glean information from public communities (Facebook, Twitter, etc.) and use that information to tailor the customer experience. Social capabilities in the platform are much like the public social environment: they surround everything we do and are available for use at any time for any purpose.

With ADEP:

  • You build applications for the cloud with on premise in mind,
  • You build applications for mobile with desktop in mind, and
  • You understand that every user is a contributor and has a social graph.

This post wraps up the current series on ADEP architecture principles. Now that we have a shared frame of reference, we’ll return to ADEP Developer Center as a PDF download. Please feel free to provide me with your feedback on that work here. Thanks in advance!

[1] i.e. ADEP Experience Server is “cloud ready”
[2] Adobe’s Customer Experience Solution for Web Experience Management (previously known as CQ5), leverages the WURFL device description repository.

Context is king

Given the previous principle, you may be surprised to read that context, not content, is king in the Adobe® Digital Enterprise Platform. Actually it’s more like a king and his kingdom. Great content is critical to customer experience, and customers experience content in context.

At the center of Adobe’s technology for customizing and optimizing user experience is something called the Context Cloud.[1]

Adobe’s approach to building CEM solutions aims to empower and delight customers by (among other means) giving Web visitors exactly the information they need, in the right form, at the right time. Doing this reliably and in real-time can be a challenge. It requires software that can aggregate relevant user information from a variety of sources so as to drive intelligent provisioning of content on a page according to predetermined strategies.

Adobe’s Customer Experience Solution for Web Experience Management rises to this challenge with a patent-pending technology called the Context Cloud. The Context Cloud represents a dynamically assembled collection of user data that can be used to determine exactly what content should be shown, for example, on a given Web page in a given situation.

Envisioning Context Cloud extension for social

Several things make Adobe’s implementation of the Context Cloud unique:

  1. Much of the information (such as info about the user’s viewing environment) is derived on the fly in real-time; it is not persisted anywhere.
  2. Marketers can experiment with different user-data values to see changes to a page in real-time (e.g. to try different campaign strategies before going live).
  3. The Context Cloud is extensible. You can add a new (custom) session-store object whose contents can fully participate in campaign “what if” scenarios.[2]
  4. Non-volatile information shown in the Context Cloud viewer is persisted on the client side (in a cookie), relieving the server of having to maintain (and then transport back and forth) large amounts of user data.

Because user info is persisted on the client, concerns over privacy and control of potentially sensitive user data are easily allayed: The user has ultimate control over the data.

Credit: Thanks to Kas Thomas for his work in describing Context Cloud.

Next: cloud first, mobile first, social first

Update 9/6/2011: The larger technical white paper from which this post was drawn is now available from the ADEP Developer Center as a PDF download. Please feel free to provide me with your feedback on that work here. Thanks in advance!

[1] Previously in Day Software, Context Cloud was referred to as Clickstream Cloud.
[2] When Adobe CQ5.4 released in February 2011, it demonstrated this extensibility via its integration with Omniture. CQ5 is now known as the Customer Experience Solution for Web Experience Management.

Everything is content

In the Adobe® Digital Enterprise Platform (ADEP), everything is content, and content resides in a repository. There are no loose files somewhere else to manage. Source code, dynamic modules, configuration and even the state of an application reside side by side with marketing collateral, digital assets such as images, audio and video, etc. The content repository recognizes that “meta” is in the eye of the beholder.[1] Consequently, there is no justification to treat content (i.e. the file stream) and metadata differently.

Resource-first request processing in the ADEP Experience Server

Since the content repository consistently manages this diversity, the rich set of content services above the repository is uniformly available. For example, the resource-first request processing of the ADEP Experience Server[2] is equally available to traditional content such as Web pages and to applications such as a product configurator. By managing to a wide definition of content, ADEP can reduce the amount of code and effort required to deliver a solution.

Since ADEP provides a virtual content repository that easily connects with existing content silos in an enterprise, “everything is content” also means that any existing content is free to participate in serving customer experience (e.g. via marketing campaigns, customer communication, etc.).

Next: context is king.

Update 9/6/2011: The larger technical white paper from which this post was drawn is now available from the ADEP Developer Center as a PDF download. Please feel free to provide me with your feedback on that work here. Thanks in advance!

[1] Content management systems that treat files in a differentiated, somehow more valuable, manner miss the reality that often the metadata around the file has the real business value.
[2] At the core of the ADEP Experience Server is CRX technology that Adobe acquired from Day Software. More on the ADEP Experience Server in a future post.

Modularity is critical to industrialize differentiated experience

Modularity is perhaps the most essential architecture principle applied across the Adobe® Digital Enterprise Platform (ADEP). Modularization in ADEP enables you to manage the complexity of your CEM solutions by separating them into independent components and other concerns that can be worked on by different development teams and tested in isolation. When deployed, these solutions consume minimal footprint that is associated with specific workload requirements (i.e. resource usage is kept to what is essential for delivering business value).


The very nature of differentiated customer experience is modular–my experience today should differ from my experience tomorrow, from my experience yesterday and from what another customer may experience. ADEP anticipates, is tuned for and can accelerate composition and reuse. In an enterprise context, supporting such modularity means that you can draw upon the breadth of assets (content, applications, documents, processes, services) available, including those from Adobe, Adobe’s partners, systems integrators, agencies and other teams within your enterprise. These assets can be brought to bear on business problems in a manner that can be partitioned and rolled out incrementally with minimal disruption (e.g. hot deployment[1]).

Modularity in ADEP is a form of separation of concerns that provides both logical and physical encapsulation of classes. Modularity is desirable because it allows you to break applications into logically independent pieces that can be independently changed and reasoned about. Modularity enables division of labor across a solution, and it promotes abstraction, reuse and ease of maintenance and repair.

As a consequence of embracing modularity as a core architecture principle, software modules in ADEP are self-contained (local wholes), highly cohesive (fulfill single purposes) and loosely coupled (well-isolated from other modules).

To support all three properties, it is vital for modules to have a well-defined interface for interaction with other modules. A stable interface enforces logical boundaries between modules and prevents access to internal implementation details. Ideally, the interface should be defined in terms of what each module offers to other modules, and what each module requires from other modules.

Modularity is driven across the ADEP architecture via the following principles:

  • Interface-based programming[2]
  • Externalization of cross-cutting concerns (aspect-oriented programming[3])
  • Late binding of implementation instances to interfaces (dependency injection;[4] extensibility)

Next: everything is content.

Update 9/6/2011: The larger technical white paper from which this post was drawn is now available from the ADEP Developer Center as a PDF download. Please feel free to provide me with your feedback on that work here. Thanks in advance!

[1] i.e. a provision of dynamic modularity in an OSGi-based system like ADEP
[2] Please consider Interface Oriented Design for a more detailed discussion of interface-based programming.
[3] Please consider AspectJ in Action: Enterprise AOP with Spring Applications, Second Edition for a more detailed discussion of aspect-oriented programming (AOP).
[4] Please consider Dependency Injection: Design patterns using Spring and Guice for a more detailed discussion of dependency injection (DI).