In the Forrester Wave™: Digital Experience Platforms, Q4 2015, authors Mark Grannan, Ted Schadler and Stephen Powers pronounce that, “Today, the proliferation of customer touchpoints, applications and digital interactions demands a new technology architecture. We call this architecture a digital experience platform.”

They go on to define digital experience (DX) platforms broadly as:

“Software to manage, deliver, and optimize experiences consistently across every digital touchpoint.”

Note that the authors refer to “digital touchpoints” (also sometimes called channels) inclusively, treating marketing, commerce and customer service touchpoints in the aggregate. Why is this seemingly obvious distinction important? Because that’s not how most organizations approach touchpoints — or buy and use DX software today. Most organizations purchase digital experience software as point solutions at the departmental level in the hopes that their IT department can stitch them together into a platform at a later date. Bad idea.

Consistency is incredibly important in the context of digital experience. To clarify, I’ll define the core components of the DX platform, what “consistency” means, and how to achieve it.

Defining the Digital Experience Platform

Forrester's authors propose that a DX platform must fulfill six key needs:

  1. Coordinate content, customer data and core services to drive reuse and quality.
  2. Unify marketing, commerce and service processes to improve practitioner workflows.
  3. Deliver contextually and share targeting rules to unify the “glass.”
  4. Share front-end code across digital touchpoints to manage a common user experience.
  5. Link data and analytics to add insight and drive action.
  6. Manage code and extensions for maximum reuse while avoiding over-customization.

These needs infer a high degree of integration across the DX platform: Integration of function (marketing, commerce, service), of data, of content development/management environment(s), and at the service layer. Which begs the question: What should we consider to be the core components of the DX platform?

There’s a great graphic in the DX Platform Wave, which I’m including (with permission) below.

Forrester Digital Experience Platform Architecture

Here, you can see the elements that Forrester considers foundational: customer data and content. “Other services” is a catch-all for other systems of record, insight and engagement that you might want to integrate with the DX platform. The applications of marketing, commerce and service sit on top of the foundational elements.

Defining and Achieving Consistency

The Forrester graphic makes it clear how content connects marketing, commerce and service together (or at least, that it should). It is by sharing content among the three applications that an organization can achieve consistency across the applications.

So what happens when an organization has one or more DX platform solutions for each application area? According to Grannan and Schadler, this is very common today, and likely will be for at least the next 18 months.

Integration

Grannan, Schadler and Powers assert that, “Forrester maintains that platform promises — common tooling, reusable assets, shared data models, short implementation times, and limited training — need not be limited to a single-vendor strategy.” Here, reusable assets refer to content, and ideally, content shared by the marketing, commerce and service applications.

In a follow-up webinar entitled Who Won The Digital Experience Platform War? Hint: It’s Not Over Yet, Grannan and Schadler further noted that, “No vendor has everything you need today.” This puts an emphasis on integration, both among components offered by any single vendor, and between any components you choose to add on from other vendors. 

But beware: Grannan and Schadler noted that “integrating the building blocks is your demon.” That’s because integration means different things to different vendors, at least in degree, if not by definition.

I believe there must be direct and indirect integration points among DX platform components to allow for combining components from different vendors. If content is foundational, or pivotal, then content itself must be a pivot point. Therefore how — not whether — content is shared within and without the DX platform becomes an important consideration. Why? Because poor integration of content can — and often does — show through to customers.

How to Achieve Consistent Content

I've previously recommended looking for solutions that support open source and/or open standards. That recommendation applies in particular to sharing content. In fact, integration is what enables content to truly be reusable within the DX platform.

When it comes to sharing content, consistency might mean choosing DX platform components that use the same underlying technology (e.g., a content repository based on the JSR 170 and JSR 283 Java Content Repository specifications). At minimum, consistency should mean all DX platform components support the ability to import content from and/or link to content repositories using standard interfaces (e.g., OASIS CMIS and CMIS4DAM) and/or RESTful web services, as well as coordinating content check in/out and versioning functions.

The bottom line is, you need to take a hard look at your digital experience platform components, and your content management system(s) in particular. Investigate whether or how well your DX platform supports sharing content. If you are unable to share content across digital experience applications, then you might want to start looking for alternative solutions. The DX Platform Wave is a good place to start.

Title image by David Marcu