Analysis

3 Proven Architecture Patterns for Integrating Digital Experience Platforms

The business justification

Today’s consumer doesn’t distinguish between channels and moments of engagement, transaction, and service. A modernized IT platform that supports digital experiences has to allow a seamless journey from awareness to engagement and discovery, purchase and transactions and even customer service and support. Unfortunately, that expectation is not easy to live up to for most enterprises today.

Many enterprises and their IT platforms have traditionally been organized by “functions” (e.g., Marketing, eBusiness, and Customer Support), thereby leading to unwanted silos. To deliver a unified, integrated consumer experience, many enterprises have started to bridge this gap by adopting and embracing the concept of a unified digital experience platform (DEP) that cuts across organizational silos (see Figure 1).

A few key considerations for digital
experience platforms

• The consumer journey is typically the key construct against which a digital experience platform is built.
• Everything within the DEP must come together to support an integrated, seamless, cross-channel consumer journey.
• Each layer of the platform is designed to solve for a particular need – e.g., customer interaction vs. back-end orchestration.
• Each layer has a variety of capabilities and solution components deployed.
• For the DEPs in certain organizations, the technology landscape within 
and across each layer may be heterogeneous (often evolving organically over time).

A scenario-driven approach to building digital experience platforms

Having worked with hundreds of marquee clients over the last 20 years, we’ve seen a broad array of business drivers and use cases for why a client may want to invest in a digital experience platform like the AEM solution. Correspondingly, we’ve also explored, defined, and implemented a variety of different solution patterns for how a DEP can be constructed and brought to life. Based on our learnings across all of these, it is evident to us that every DEP solution within each organization is somewhat unique – there is really no “single solution” or “silver bullet” for how these platforms can (or should) be architected.

Against this backdrop, our experiences have shown that there are four key business scenarios and use cases for a modernized DEP:

The architectures

There are various ways in which a digital platform and its underlying solution architecture can be defined. Consequently, there are a number of different design patterns that can be applied to architect the solution as well. These patterns dictate how responsibilities are assigned across the various layers of the architecture, how systems, technologies, and packages are “mapped” to these responsibilities, and how the interactions between the different layers and systems work to deliver the complete solution. Again, as opposed to advocating the “one-size-fits-all” solution pattern that works for every scenario, we believe in considering a catalog of solution patterns that can then be evaluated and applied against each enterprise’s needs and unique situation.

For the purposes of this paper, we will focus primarily on the Adobe Experience Manager as the web content and experience management solution. We will highlight a few key architecture patterns for building digital experience platforms around the AEM solution and reveal how AEM can be deployed and extended in different ways to support various needs.

The deployment of a standard AEM solution is ideal for a wide spectrum of brand marketing experiences, including corporate websites and microsites, global and local brand coordination, and multi-brand/channel/ regional marketing. With this pattern, IT teams separate concerns and responsibilities by decoupling front-end activities from those of the back end (see Figure 2). This enables both to evolve independently – not to mention allowing front and back-end teams to do what they do best.

Even with a decoupled front end, the application of this pattern retains all the power of the authoring and marketer capabilities available out-of-the-box with the AEM solution. The benefit is given by the seamless integration of the front-end experience and modules with back-end AEM platform components, which (by leveraging a “schema” or contract-driven component development model) minimizes churn and rework in the integration process.

By adopting a front-end view library that supports a “write once, run anywhere” approach, brands are able to rapidly evolve their experiences from largely static ones to interactive, personalized, and dynamic interactions. This, combined with the use of the out-of-the-box (server-side) templating construct available in AEM, enables a multi-tenant architecture that allows multiple brands to derive reuse from a shared platform – yet grants each of them and their corresponding agencies full creative independence in how they design and develop the customer experience.

The standard AEM solution also takes advantage of a “progressive rendering” model that enables a good portion (or even the entirety) of the experience or page to be rendered by the AEM, all while reusing the same front-end view library for rendering across both the server and browser containers. The AEM solution (in this case, AEM Publish) is then used as the primary deployment container and “presentation assembly” layer to host, deliver, and serve the consumer experience. Subsequent integration needs associated with the organization’s marketing ecosystem (e.g., analytics, targeting, digital asset management, search, and consumer data) can be largely handled within the AEM platform itself or done client-side (i.e., browser-side).

When integrating browsing and shopping experiences or driving content-driven commerce, adopting an experience-driven pattern is preferred. In this deployment, there are three factors at play: the front-end team defining templates and designing user-facing elements, the AEM platform team creating editable content components, and the integration developers building scalable integration services and application programming interfaces (APIs). Together, they combine marketing content and editorial capabilities with the data and business applications of underlying transactional systems to enable a unified consumer experience characterized by integrated experience management (the authoring) and delivery (the rendering).

In this solution, as in the previous one, the consumer experience and back-end systems are again decoupled and evolve independently. The AEM solution retains the power of its out-of-the-box authoring and marketer capabilities as well – this time to enable integrated in-context authoring, editorial tasks, and experience previews within the AEM environment itself. The front-end view library is also carried forward to enable front-end developers to build and manage user-facing elements separately – thereby facilitating greater experience agility.

Lastly, in most scenarios, the solution continues to leverage the AEM Publish Server as the primary “presentation assembly and composition” layer to render and deliver the customer experience. The overall experience, page layout, and marketing components can all be rendered by AEM Publish, however, dynamic components that require integration and orchestration (e.g., product details, booking widgets, etc.) can be resolved and rendered by using either server-side include technologies.

The key to applying this pattern is an “API-first” mindset (see Figure 3). Based on this, a scalable service orchestration layer within the architecture is established to integrate with back-end systems, including commerce, customer relationship management (CRM), booking engines, etc. This is particularly relevant as the number of integrations increase and greater orchestration is required across services (back-end systems) to deliver and render the customer experience.

Our last pattern is a game changer when compared to your standard AEM solution, CMS platform, or any other content and experience platform deployment. This is due to three critical, differentiating factors:

Enable extreme scale for business-critical transactions

The scalability and agility of this pattern stretches far beyond the simple delivery of content and marketing experiences to enable business transactions, digital commerce, and online customer conversion at incomparable scale.

Build the entire system for change

Our third pattern can rapidly – and independently – evolve both your cross-channel consumer experience and its underlying integrations/transactional systems without needing to “rip and replace” with every major change.

Unite the CMO and CIO in collaboration

The ultimate goal of this pattern is to empower marketers with the toolsets they need to create and deliver great experiences, while simultaneously gifting IT with an architecture pattern that allows them to not only rapidly scale, manage, and maintain the solution easily but also to become the CMO’s best friend by supporting their (and the architecture’s) need to evolve.

Based on microservices, which are typically the core of the digital experience platform, this pattern is ideal for the heavy orchestration involved in architecting omnichannel consumer experiences at web scale. These applications include cross-channel business-to-consumer or business-to-business commerce, multi-brand or multi-store product catalogs with high counts, and high-volume order or transaction processing. This third pattern is also preferred for integrating across browsing, shopping, purchasing, and customer service interactions.

All of the aforementioned examples necessitate a high degree of modularity and agility – along with the ability to manage, deploy, and upscale each layer independently. A cloud-native, pure microservices architecture pattern solves for 
this by adopting an everything-as-a-service model that identifies multiple interactions (e.g., content consumption, commerce experience management, ordering, product catalogs, promotions, loyalty) as “headless” services (see Figure 4). The headless approach is what allows for a high degree of decoupling and flexibility across the consumer experience. It supports a variety of evolving channels, as well as offers 
a platform architecture future-proofed for the evolving technology landscape – 
one in which individual services and their underlying products are likely to change over time.

Similar to the experience-driven pattern, the microservices architecture also leverages an API-first model when interfacing with all underlying systems and services. In fact, this is what establishes the highly scalable, non-blocking service orchestration and integration layer within the architecture. This layer is separated from the actual microservices. The service orchestration layer is highly optimized for a channel (typically delivering a single, composite, and optimized response for each one), but that channel can spread across several underlying microservices. It is the architecture that combines the responses from several underlying API calls into one unified response: the customer experience.

That experience (the overall application) is supported by a set of loosely-coupled, fairly independent modules that can follow their own development lifecycles – also referred to as “non-monolithic” deployment. It has a preference for a “decoupled presentation assembly” layer (a.k.a. a “decoupled glass”) in which a server-side MV* (Model-View-Wildcard) application enables:²

• Routing
• Server-side presentation logic (controllers)
• Orchestration across APIs and back-end services
• Dynamic experience composition
• Asynchronous processing and parallel execution
• Event-driven and reactive programming models

These activities are typically done outside of the underlying systems (e.g., content, commerce, etc.) via a “Universal JavaScript” application pattern for the assembly, rendering, and presentation layer –wherein the same MV* application can assemble and render the dynamic experience across server and client. The application is typically deployed as the “decoupled glass” that simultaneously enables high-speed, high-performance rendering on the server, front-end rendering in the browser, and rapid updates to the customer experience layer.

With this, the consumer engagement platform is able to rapidly update with faster release cycles and more frequent deployments, all while isolated from the underlying mission-critical transaction system (which may follow its own release and update schedule). It is this notion of “bi-modal” or “two-speed IT” that enables the right balance between experimentation and agility vs. stability and scalability.

Lastly, experience management needs are relatively simpler than what is typically seen with the experience-driven solution. Some degree of layout, page, and template management is still desirable and required, but this is either limited to specific sections of the customer experience (e.g., product discovery) or is focused on specific needs such as component/slot placement (primarily for the purposes of merchandising).

That being said, IT leaders z the opportunity to share, leverage, and adapt the underlying AEM solution within the enterprise across multiple solution patterns. For example, the experience-driven and headless patterns (second and third, respectively) can be combined using the same AEM infrastructure – a decision that makes sense if the enterprise has already invested in one Adobe solution and now wishes to leverage the unique benefits of another.

The benefits

Organizations and enterprises worldwide are betting on digital experience platforms as the new innovation frontier and primary customer engagement vehicles. Many are taking a look at their business needs and scenarios and considering how the implementation of an optimal DEP solution could benefit them in both the short- and long-term.³ Given that each organization has their own unique business goals and drivers, these inputs are vital when determining how best to architect that solution (see Figure 5).

The business scenarios and solution patterns outlined in this paper are meant to guide the process, helping IT architects and application development teams determine which architecture makes the most sense for any given organizational situation. This catalog of patterns should enable architects, consultants, and client IT teams to collaborate jointly and have conversations on which approach is most applicable and beneficial to them.

Of course, these patterns can be further extended, modified, and tweaked as necessary. In fact, leading companies are taking steps to plan for these types of flexible digital experience platforms and then rapidly implement them with partners to achieve business goals.

Sources:

1. Forrester. Vendor Landscape: Digital Experience Platforms.
2. MV* refers to any server-side technology framework that references one of many model-view design patterns, such as MVVM (model-view-view model), MVP (model-view-presenter), or MVC (model-view-controller).
3. Publicis Sapient. The Rise of Digital Experience Platforms.