Tag Archives: XOA

Experience-Oriented Architecture

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.

What is the Client Component Framework?

Related series of posts about Adobe® Digital Enterprise Platform (ADEP):

  1. What is XOA?
  2. What is a UX Component?
  3. This post :-)

Awhile ago, Stacy Young broke the news of an internal-to-Adobe framework for RIA development, inspired by OSGi and Spring and targeting the Flash Platform, called “Gravity.”

If you’re a Java developer, you probably already now about OSGi and Spring, de facto standard implementations of modularity and dependency injection (among other things), respectively. Both are leveraged within the Adobe® Digital Enterprise Platform (ADEP).

Although “Gravity” never did make it to Adobe Labs, work on the framework never ceased. In fact, work on “Gravity” increased as it became clear that large-scale application development on the client (edge device) with Flash and AIR required similar modularity and dependency injection support.

One of the attractions of so-called Rich Internet Application[1] development is a blurred line between client and server, leveraging the full facilities of the local environment where software executes. In order to promote such blur, though, it helps to have a consistent programming model end-to-end. ADEP provides this consistency by embracing OSGi and Spring on the server-side and by offering the Client Component Framework (pka “Gravity”) on the client-side for customer experiences built on AIR or the Flash Player.

If you attended my session at MAX last year, “Realizing great customer experiences with LiveCycle ES3,” you may remember that I talked a fair bit about “Gravity”–now the Client Component Framework in ADEP. As you can see, marketing has since determined final product names; so, please apply the following translation when reviewing that content (i.e. slides 26-47 in particular):

  • Gravity – now Client Component Framework
  • Mosaic – now Composite Application Framework
  • LiveCycle RIA Server – now ADEP Experience Server
  • LiveCycle ES (user management integration) – now ADEP Document Server
  • LiveCycle ES3 Solution Application – now Customer Experience Solution (powered by ADEP)
  • Field Force Automation – now the Adobe Unified Workspace Customer Experience Solution

Shortly after MAX 2010, Stacy reiterated that a public release of “Gravity” was approaching.

As has been the case for the past few months, you can play with the Client Component Framework now. To do so, please join the pre-release program for the Adobe® Digital Enterprise Platform (ADEP). (Don’t worry if the initial screen says something about LiveCycle ES3; you will subsequently see reference to ADEP.) Once you do sign-up, please post your feedback on this technology (and the rest of the platform) to the pre-release forums. Thanks! :-)

Although it’s just now becoming a public, supported API in its own right, the Client Component Framework in ADEP has been used in production for awhile now. LiveCycle Mosaic 9.5 (part of LiveCycle ES2.5) leverages Gravity internally for managing composite RIA components (i.e. tiles).

Where does the Client Component Framework fit within the Flash Platform?

As shown in the above figure, the Client Component Framework operates above the Flash Player and below the Flex SDK–much like the Text Layout Framework. That is, the framework operates independent of the Flex SDK and supports a mixed-SDK-version runtime environment. This is especially important for large enterprise project that may need to reuse components from other vendors that don’t all leverage the very latest (or same) Flex SDK.

Additional points of value in the framework include the following:

  • It enables you to choose what parts of your solution to upgrade and when.
  • Newer versions of a component that may leverage a newer Flex SDK can co-exist with older versions of the same components based on an older SDK.
  • Since components using the Client Component Framework communicate via a service registry, not each other, you can apply versioning and other policies as you would expect of a service-oriented architecture.
  • Components using the Client Component Framework are intrinsically loosely-coupled, which improves their changeability, comprehensibility and testability.

Having introduced the Client Component Framework, next we’ll talk about the Composite Application Framework, which leverages the subject of today’s post. Cheers!

[1] Aren’t most apps RIAs these days?

Update 7/26/2011: Instead of moving on to the Composite Application Framework, I thought it best to address ADEP architecture principles first with a set of posts.

What is a UX Component?

Previously, I offered some thoughts in response to “What is XOA?” To recap, experience-oriented architecture indicates an approach to solution design that is about the customer in, not the underlying systems out. I mentioned the concept of experience components in the Adobe® Digital Enterprise Platform (ADEP) as a concrete expression of XOA for Flex developers, noting that XOA is, in fact, technology agnostic.

Now, let’s talk in more detail about UX Components.

UX Component makeup

Adobe CEM applications use a component model that is oriented toward reuse across a spectrum of applications. At one end of the spectrum we have static applications where individual components are statically linked into an application. At the other end of the spectrum, individual components are placed in a catalog on a server and dynamically injected into an application at runtime. We call these “experience components”–UX Components.

Technically speaking, a UX Component is a combination of MXML and ActionScript classes that is bundled into SWC files that separate concerns and encapsulate each concern behind an interface. Interfaces make the implementation of concerns (i.e. presentation, domain, etc.) replaceable and extensible.

Technical decomposition of a UX Component

The fact that a UX Component is well-composed behind a set of interfaces, allows you to focus on the concrete implementation of familiar coding patterns productively.

For example, let’s assume that the domain model and service integration specified by Adobe for a UX Component is well-suited for your use case, but in order to differentiate your customer experience, you need to implement a custom user interface. By leveraging UX Components in ADEP, you simply focus your attention on implementing a custom view and presentation model that will leverage everything as-is:

UX Component pattern: custom view and presentation model

Another common requirement involves integrating existing systems into new customer experiences. Depending on your use case, you may be satisfied with a UX Component as provided by Adobe. So, you need only focus on implementing a custom façade to ensure that customer interaction with your experience is integrated with your existing infrastructure:

UX Component pattern: custom application façade

Here is an example of a UX Component:

Example UX Component

At the top is a logo component and a navigation bar. The left column has a calendar, and the right column has resources finder and a document viewer. Each of these components are very generic displays of information. For instance, the project calendar is a graphical list of items, actually a tree of items that is rolled up into a Gantt chart. Each of these items has a start date, finish date, phases, a current state shown in color and descriptions.

A UX Component is completely independent of its data source. Simply by injecting a data source at runtime and providing a different skin, a different application experience can be delivered:

Previous UX Component with new look and feel

Here is the same calendar UX component, with a new skin and a new data source. This shows a charcoal theme, and the data is a product development plan rather than a marketing plan. The renderer for each of the items now shows the phases of the project as colors in the bar.

By creating a well thought out UX Component, where concerns are inheritable, skins are replaceable, and services are injectable, ADEP enables you to achieve a high level of reuse while providing both richness and consistency in the experience.

More on ADEP‘s Composite Application Framework (pka Mosaic) and Client Component Framework (pka Gravity) in future posts…

Update 7/6/2011: “What is the Client Component Framework?

What is XOA?

XOA stands for experience-oriented architecture. XOA was first coined by Adobe’s Steven Webster “to very specifically mean applying design thinking to evolving an architecture stack, and more recently, to talk about instrumenting an experience in order that it can be measured and monitored as delivering against intended KPIs.” It is therefore incorrect to reduce XOA down to component development. At its heart, XOA embodies best practices for RIA development, whether in the browser or on the desktop.

In the (just-announced) Adobe® Digital Enterprise Platform, XOA manifests its RIA best practices via layers (concerns) as follows:

  • Presentation – view rendering
  • Domain – client-side computations, abstraction of server calls, etc.
  • Infrastructure – server communication

XOA is an architectural approach and is not bound to a particular technology (e.g. applies to Flex, HTML5, native mobile, etc.). XOA is certainly not meant to be a formal label–just like you wouldn’t expect to see “SOA” in XML, etc.

This layered architecture [1] provides an efficient way of segregating the code related to view rendition, client side computations, perpetual asynchronous communication, etc. Embracing such separation of concerns enables ADEP development projects to be easier to understand and to manage. Moreover, it helps developers with different personas to work in tandem on a component (e.g. the UI developer in concert with a business logic developer).

Example of applying XOA to ADEP-based Flex development: Enterprise Flex components (aka UX (User Experience) Components) are mostly data-driven with data synchronizing from a backend server over Remoting, Data Services, etc. With data coming from server in an asynchronous fashion and component assembling itself by computations, the complexity increases manifold since the component, apart from rendering itself also needs to construct itself. Therefore, it becomes extremely important to separate concerns before the component development turns unmanageable. However, please keep in mind that XOA is about much more than component development as noted above.

For example, a UX Component in ADEP is an enterprise Flex component that embodies XOA principles.

More on UX Components and other aspects of ADEP in future posts…

Update 6/30/2011: “What is a UX Component?

[1] You may recall that I spoke about XOA during my MAX 2010 session, “Realizing great customer experiences with LiveCycle ES3.” (ADEP replaces “LiveCycle ES3.” ADEP is the new brand that incorporates aspects of LiveCycle with aspects of the Day Software aquisition.)

Realizing great customer experiences with LiveCycle ES3

Thanks to everyone at Adobe MAX 2010 who came to the sessions that I presented. I enjoyed the interactivity during after after the presentations, especially listening to your thoughts on how Adobe CEM will enable you to realize your own customer experience vision as well as the growing expectations of your prospects, consumers, customers and clients.

In order to keep the conversation going, I’ve uploaded this presentation as follows:

Realizing Great Customer Experiences with Adobe® LiveCycle® ES3 – Craig Randall

Whether you were able to attend MAX or not, I encourage you to check out MAX 2010 on Adobe TV (e.g. here are the keynotes). Please also visit the MAX 2010 session catalog to browse all sessions and download presentations of interest.

Update 11/5/2010: You can now watch and listen to this MAX session online (i.e. in synchronized fashion). It appears that the good folks at MAX decided to post the slides and recording that corresponded to my first delivery (on Monday during MAX). While that session went well, I did receive some feedback that I incorporated into a revised deck that was also recorded (on Wednesday during MAX). Personally, I liked the latter content and delivery better than the first, and that is what is provided here in this blog post, above.

Update 12/3/2010: Jayan has done a nice job of rounding up LiveCycle-flavored MAX sessions, including this one, here.