Adopting a modular architecture ecosystem approach that places certain core services at the heart of the ecosystem is needed to meet the demands the customer experience across all channels and touchpoints. In order to make this possible, it needs to be a next-level modular DXP.
For the sake of clarity, a Digital Experience Platform (DXP) is an integrated platform ecosystem where customer data and journeys are joined together in a holistic way to offer the best possible experience for the visitors, across all channels and touchpoints.
The DXP report and the term DXP are not new. I first heard the term some years ago, and since then it has gathered a lot of momentum. That does not mean there were no DXPs before that time but that we just used a different name for it. Back then we were talking about things like omni-channel personalization and a 360-degree customer view. Like usual, a lot of the technology market chatter is just old wine in new bottles.
This does not mean that there have not been major developments. In fact, I feel that in the last couple of years, DXP technology has come a long way. The idea of a holistic approach towards an omni-channel customer journey has become the industry standard. This idea has been around for longer, but I feel that in the last couple of years it has really become the central starting point for most companies. At the same time, I have seen that DXP platforms are being embedded into an existing ecosystem instead of as a semi-standalone suite.
This brings me to an observation: Traditional IT architecture design has told us that it is always a good idea to put certain things that need to be shared by multiple systems at a deeper level in the architecture. This still applies 100 percent in today’s world. Luckily, I see a lot of DXP vendors moving into that direction. I feel that it is absolutely necessary to deliver the promise of a true omni-channel DXP.
Before Digital Experience Platforms
Before the advent of DXP suite vendors, a DXP solution normally comprised of a number of loosely related solutions that covered the functional scope. This resulted in an architecture with mostly disjointed solutions that were integrated with each other via point-to-point integrations. For instance, a Content Management System (CMS) that stores content and renders a website with a Customer Relationship Management (CRM) solution that stores customer data and an Electronic Direct Mail (EDM) solution that is used to send and track email campaigns.
This kind of architecture always results in an overlap in functionalities, duplication of data and a lack of coherence because there can never be a strong central architectural thought behind the architecture. More often than not, this results in an unmanageable and overly complex architecture that does not make maximal use of all the components. It therefore does not deliver the full theoretical potential of the solution.
First Generation Suite DXPs
First generation suite DXP platform were created as a solution for the problems that existed at that time. Like described above, marketing technology was typically a bundle of solutions cobbled together and added on top of each other. The promise of first generation DXPs was to remove this complexity and make it more manageable. It was a reaction to the disjointed architectures that existed before. The promise of an easier and manageable architecture has always been the biggest reason why companies choose such a platform. Another important reason is that a suite DXP is better suited to meet the demands of the digital experience because the scope of a DXP is broad and covers more channels than just the website.
The Need for Next-Level Modular DXPs
The reality is that most of the suite platforms are not as seamless as you might think because they were not created as one seamless platform. Most vendors grew their functionality through the acquisition of separate companies and by adding those capabilities to the suite. This typically means that the technology is not completely seamless and that underneath, a lot needs to be done to make it work as advertised. The result can be somewhat of a technological monster with multiple solution UI’s that are semi-integrated underneath. Also, the suites grow more complex with every acquisition and normalizing the technical landscape becomes impossible because it simply changes too fast.
Furthermore, as I stated before, Experience Platforms nowadays are almost always embedded into an existing ecosystem of solutions. This still means that there can be functional or data overlap in these solutions. Of course, the customer does not care about overlapping solutions. The customer wants to be served coherently, consistently and independent of where they are in the journey. Therefore, a next-level modular DXP should place all that is needed to manage the experience across all touchpoints centrally in the architecture. Also remember that it is certainly not always the case that all your touchpoints and channels will be served from the same technical solution.
Companies that place the customer experience at the centre of their way of working will benefit from moving away from the all-in suite approach and adopting a more modular approach. Instead of a packaged suite, the architecture approach should be an open framework that allows for different solutions to be added into the platform. At the same time, the framework should make sure that things like data and journey decisioning re-use are possible, no matter the touchpoint, present or future. This is needed to make sure the organization’s demands towards the digital marketing experience are met, independent of the solutions used and touchpoints served. A clear architecture design based on the principles of separation of concern plus a focus on openness and connectivity will also lower costs and complexity.
Attributes of a Next-level Modular DXP Architecture
When a company places journey thinking at the core of what they are doing, it should take responsibility and ownership of the architectural foundation that facilitates it. This specifically applies for anything around data, analytics, identities, journey orchestration and decisioning. If you really take journey thinking and omni-channel experiences seriously, you should not encapsulate and bury these things in a channel-specific solution. Instead, put it lower in the architecture and build your own (microservice based) architecture that makes it available for any channel while also reducing complexity and overlap by adopting an open and modular approach. Subsequently, you must own and enforce the approach because it is a key requisite for reaching the company’s holistic experience goals. Another big benefit of an open and modular architecture is that companies do not need to go all in from the start. Instead, they can start small and grow as they develop capabilities and mature.
The elements that need to be placed lower in a DXP architecture are Customer Data, Identities, Journey Orchestration Engine, Omni-Channel Content and Omni-Channel Order Management (in case your platform is also a commerce platform).
All customer data plus the conclusions that are derived from the data should be available to all channels in order to manage the customer experience. Customer Data Platforms (CDPs) provide a unified view of the customer, their attributes, behaviours, segments, etc. In a CDP, behavioural traits can be recognized and turned into segments that can be used to target audiences in the channels. Part of a CDP is also a Data Management Platform that is used to aggregate and collect first-, second- and third-party analytics data and the analytics solution that feeds the CDP with data.
This speaks for itself. Identities are a foundational service needed to link data to specific users in one (or more) of the channels. This needs to be managed centrally so you can recognize a user in any of the channels and subsequently tie the user to the proper data context.
Journey Orchestration Engine
This is the experience decisioning and automation engine that determines where the engaging user in a channel is sent, based on their behaviour and current location in the journey. It is a central orchestration engine that determines what happens, how it happens, when it happens and in which channel it happens.
These are the channel agnostic core content and experience elements that can be used by the channels. This is a system like a Digital Asset Management (DAM) and Product Information Management (PIM) solution that holds a broad variety of product data and assets next to the typical DAM elements like media files or images. It does not hold all of your content, just what you need in all the channels.
Omni-Channel Order Management
When your DXP is also a commerce platform, the orders typically can be created in multiple channels. For example, orders that are being created in your webshop versus orders that are being created in store, via the call centre, or via an online service desk. In order to make the orders accessible in all these channels, the order should be managed in a central Order Management System (OMS). The OMS can then be used by any channel to get information about orders and also create and modify them.
At the top level, a solution architecture of the platform would then look something like this:
In order to efficiently manage the user journey and experience across all channels, it is needed to create a holistic view of the whole architecture ecosystem. This means creating an architecture ecosystem where all elements that are needed to make this possible are put at a shared level in the architecture, so they are available to all the channels. The architecture needs to be open and modular so it can easily integrate.
Over the years, we at Valtech have built up a great amount of experience in creating these kinds of ecosystem architectures through the projects we do for our clients. If your company is also facing these kinds of challenges, feel free to contact us. We would be more than happy to help and share our experiences with you.