A lot has been said and written lately about the Digital Experience Platform (DXP) in general and, more specifically, about building a DXP based on a MACH – or composable architecture – in which MACH stands for Microservices, API first, Cloud-native SaaS and Headless.
It is open to question, however, whether these two architectures really differ. And the more I read about it, the more I am inclined to say that they don’t. There are some differences but the problem which these architectures tackle is the same in both cases. But because customers increasingly ask about this, I would like to take the time here to explain what I mean.
Composable DXP: An existing concept repackaged
It seems to be something of an IT habit. As soon as anything new appears, all sorts of suppliers or analysts, like Forrester or Gartner, claim it as their idea. After making a few minor adjustments, they often give it their own name. This can sometimes make it confusing and unclear whether we are talking about the same thing, or something else entirely.
Digital Experience Platform (DXP)
In terms of the digital experience platform, it is broadly agreed that we do not live in an era in which a single, monolithic, digital experience platform can provide the complete end-to-end experience for a customer journey. [By customer journey I mean: branding, targeting, engagement, the delivery of products, services and aftersales to a given customer, retaining the customer and turning them into an ambassador for your brand.] Added to which a DXP covers the implementation of the necessary digital capabilities to help you with that part of the customer journey which you want to support in an integrated manner, so that the experience for your customers is a smooth and positive one.
There is no one, all-encompassing definition of a DXP; it’s about the breadth of the customer journey that you want to support, as well as the depth and degree of personalization you wish apply to achieve that.
We could therefore see DXP as a type of reference architecture that you can use and about which you know that the way in which you use it will change over time, e.g., if you change your business model, or if customers start using a new technology.
MACH and your composable DXP
So, if you need flexibility in your DXP architecture, both now and in the future, while also maintaining an overview and keeping a grip on your investments, then DXP – which provides only the necessary level of functionality at any give time – is the way to go.
Specific functionality needs (e.g., following the transition from an indirect channel to a more hybrid direct channel in retail) may change over time. This means that you have to be able to isolate and replace that functionality fairly quickly to keep pace with changing business needs.
The same applies to new functionality needs, e.g., when you switch to a more automated way of working based on hyperpersonalization, through the use of a Customer Data Platform together with AI.
You can only use a composable DXP in this way if, in addition to the composable DXP functions, it has two basic elements:
- A middle layer between the composable DXP functionality consisting of APIs that can be connected to a DXP functionality (such as your commerce or CRM application) and a set of services or microservices.
- A headless approach. It’s all about customer interaction in which every necessary app has been developed on the basis of headless principles which means that, in principle, they can operate independently (technically) of every underlying composable DXP functionality. From an architectural viewpoint, this gives you the flexibility to be able to exchange headless customer interaction apps and composable DXP functionality, as and when needed.
From a technology point of view, as I see it, communication with customers in a digital world, with the vital support of a DXP consisting of multiple composable DXP functions, requires a cloud platform.
When it comes to microservices (for connections), APIs to composable DXP functionalities, the cloud and headless apps to communicate flexibly with customers, as well as to meet customer-driven needs and expectations, we automatically arrive at a MACH environment.
Implementing a successful and sustainable composable DXP invariably leads to ‘MACH by design’. A composable DXP functionality is far more than conventional DXP functionality which is composable, such as content management, commerce, campaigning, e-mail and other direct marketing, etc. Data – held on a customer data platform – will always be the critical success factor of a DXP. And, as with a MACH design, your customer data platform has to be part of your DXP solution right from the outset.
While a MACH design allows you to connect elements (composable DXP functionality) within your digital experience platform to communicate with your customers, your customer data platform gives you insight into how to put them in the right order.
Microservices, APIs, cloud – where have you heard that before?
We need microservices, APIs and cloud technology to connect every system in your DXP. The more ‘breadth and depth’ you want and need from your DXP to support the customer journey, the more this affects other systems, such as your CRM, SCM and ERP systems or your business apps.
If you have no platform to support your day-to-day activities, you will have a hybrid set of systems: from standard to customized. In essence this is also a type of composable architecture, although less dynamic than it would be in a DXP domain.
For decades we have used a middle-layer architecture to connect these systems with each other. Over the course of time this evolved into an enterprise service bus which then developed into an API/services or microservices layer, which we still use today.
But more flexibility is needed, even in the more classical back-end world. Take, for example, a low-code enterprise application which facilitates a more agile response to customers’ changing needs and behavior. This trend underlines the need for a more sophisticated middle layer which, because of its structure, increasingly requires a cloud setting. We therefore now have a parallel with one of the basic elements of a DXP. This ‘digital operations setting’ is currently referred to by the analysts as a Digital Operations Platform.
In principle, this is good news. Because when you extend your DXP to your operational digital systems, you will find that – from an architectural point of view – connecting (or interconnecting) is hardly any different than it is in a composable DXP setting.
Get maximum value from your DXP platform
When you take your first steps towards a DXP you will have already reached a major milestone. But that on its own won’t take you all the way. Because how can you ensure that the platform continues to add value in the long term? That requires a carefully considered implementation and its maximum adoption. On top of which you need to ask yourself whether you have the right competences in house and how it will fit into a flexible application landscape. In this whitepaper we look at the challenges of a DXP for the CTO and CMO and provide you with four tools to ensure you get maximum value from your platform.
