4 Replies Tweet In the (ADEP)

Menu Tag Archives : architecture.
Cloud first, mobile first , social first.
3 Replies Tweet The (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] In pursuing interaction patterns, ADEP starts its approach with mobile devices (particularly tablets) and then expands to consider other environment s.
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.
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

Please feel free to provide me with your feedback on that work here

Thanks in advance.
Footnotes: [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.
This entry was posted in and tagged , , , Cloud, , mobile, Social, on 2011-07-29 by.
Context is king.

3 Replies Tweet Given the previous principle

you may be surprised to read that context, not content, is king in the.
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.
Several things make Adobe’s implementation of the Context Cloud unique: 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.
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).

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].
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 as a.
Please feel free to provide me with your feedback on that work here.
Thanks in advance.
Footnotes: [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.
This entry was posted in and tagged , , , Client Context, context, , on 2011-07-28 by.
Everything is content.
4 Replies Tweet In the (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.
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 as a.
Please feel free to provide me with your feedback on that work here.
Thanks in advance.
Footnotes: [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

This entry was posted in , and tagged , , , Content, , on 2011-07-27 by.
Modularity is critical to industrialize differentiated experience.
1 Reply Tweet Modularity is perhaps the most essential architecture principle applied across the (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 as a.
Please feel free to provide me with your feedback on that work here.
Thanks in advance.
Footnotes: [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).
This entry was posted in and tagged , , , , LiveCycle, modularity, on 2011-07-27 by.
Adobe Digital Enterprise Platform architecture principles.
4 Replies Tweet Architecture is the result of a collective set of design choices, and these choices are informed by principles.
It occurred to me that before I continue much further with my current series on “content + apps”–a design pillar in Adobe’s enterprise software platform for Customer Experience Management–it would be good to share the architectural principles of the Adobe Digital Enterprise Platform (ADEP).
Talking first about ADEP architectural aspirations will hopefully clarify their realization (i.e.

Architecture implementation choices in ADEP)

In summary, here are the principles: Modularity is critical to industrialize differentiated experience.
Everything is content.
Context is king.
Cloud first, mobile first, social first.
Next, .

We’ll examine the importance of modularity to ADEP

Update 9/6/2011: The larger technical white paper from which this post was drawn is now available from the as a PDF download.
Please feel free to provide me with your feedback on that work here.
Thanks in advance.
This entry was posted in and tagged , , on 2011-07-26 by.
Post navigation.
← Older posts.