All-in-one vs. composable approach for digital experience platforms

Michał Cukierman

by Michał Cukierman
5 min read

Monolithic vs Composable - can one become the other Monolithic vs Composable - can one become the other

Monolithic architecture, a prominent characteristic of traditional DXPs, refers to the integration of all services and functionalities into a single platform. This approach originated from the development of CMS or WCM systems in the early 2000s.

Back then, setting up an external server for handling specific functionalities such as full-text search or authentication was challenging, especially if a new point-to-point integration was needed to make it work with the CMS. Therefore, clients were seeking CMS solutions that would provide a wide range of features right out of the box. However, 20 years and dozens of technological leaps later, is an all-in-one solution still the best fit?

Unpacking the all-inclusive DXP

The CMS author instance is responsible for providing features related to content management, collaboration, classification, and publishing. The publish instance, on the other hand, is used for delivering data and rendering content. For each of those instances, any extra functionalities will obviously need to be different. So with built-in solutions, we are talking about adding on average 10-15 additional services stacked on top of CMS.

Examples of functionalities provided in the publishing layer are:

  • Full-text search

  • Authentication and authorization, including closed users groups (CUG)

  • Users and groups management 

  • Handling user-generated content (UGC)

  • Personalization and recommendation

  • Custom workflows execution

  • Ability to provide custom endpoints

And for the authoring layer:

  • Personalisation management

  • Digital assets management (DAM)

  • Campaign management

  • Workflows management

  • Analytics

The biggest problem with built-in functionalities

In my 15 years of working with DXPs, I have learned a crucial lesson: built-in functionalities are only good for basic use cases. In many instances, they fall short due to limited features, less-than-ideal performance, or lack of scalability and resilience.

A well-designed site content should always be fully cacheable. However, it is usually not possible to cache the results of additional publisher features. If the publisher is responsible for handling the search functionality, it needs to be exposed. This can easily lead to overloading the server with concurrent search queries.

In a monolithic architecture, where resources are shared, if one service goes down, it brings down the entire application. No one wants to experience a site crash simply because one endpoint is consuming excessive memory or threads. And yet, this is a situation I had to face multiple times as a senior DXP developer.

MACH and Composable: a shift towards specialized solutions

These are only a few of the reasons why, for the most demanding projects, it’s often a wiser choice to avoid built-in CMS features altogether. 9 times out of 10, you are better off choosing one of the specialized solutions available on the market.

It’s now easier to achieve than years ago, thanks to changes in the tech landscape. Today, we can easily provision environments with specialized solutions, either through a few lines of code or a few clicks. Options include custom containers, cloud services, or Software as a Service (SaaS) platforms.

These approaches are now becoming standardized, with popular headless architectures like MACH or Jamstack. Within these architectures, the only structured data comes from “headless” CMS, and all custom functionalities are handled by microservices or external providers.

Lastly, a new type of Digital Experience Platform (DXP) is gaining popularity - the Composable DXP. These platforms counteract the limitations of traditional DXPs' monolithic nature by integrating best-of-breed modules and services. This gives the platform a new degree of flexibility, where any innovative product can be included, and any legacy one - replaced.

A conceptual graph showing differences between Monolith DXP and Composable DXP architecture

Figure 1: Composable DXP vs Monolithic DXP

The emperor is wearing new clothes now - but is he really?

As alternative platform architectures gain traction, traditional Digital Experience Platforms (DXPs) are striving to keep up. Most are now claiming to be headless, API-first, composable, and cloud-native.

Indeed, most of these platforms have introduced an array of modern features. However, the reality of using these features in real-world projects is far from ideal. It’s more like the scenes from Anton Gudim's “yes, but” meme series.

a man with a hat - meme

YES

BUT

DAM module

it’s not keeping up with the market. It is still the only one that can be used without complex integrations

Headless module

it’s not as good as external headless CMS products

Analytics

they slow down the platform, and bring only basic information about the visitors

Search

it can be used as a target for DDoS attacks. As a consequence, the whole platform may go offline, not only the search

Custom service

it can contain a bug, which can cause platform-wide unavailability. In a true MACH architecture or Composable DXP, only a service or module would be affected

Authentication module

it’s hard to implement authentication mechanisms like SAML, JWT, or OAuth at scale

The list could go on, but these are just a few examples from my personal project experience.

In reality, no CMS should be used as the core technology of a DXP. CMS was originally designed for content management and publishing - and that's what it should be used for. The fact that there are a lot of functionalities built around DXP modules is not reason enough to use them.

Making the decision for yourself

Always carefully review the architecture you're setting up: especially whether you will be able to manage the integration of external services yourself. Choosing to use the built-in features of a monolithic DXP can result in:

  • A platform that lacks scalability and performance

  • A fragile system where an error in one module can break the entire platform

  • The inability to utilize the best tools available in the market

  • Vendor lock-in, resulting in a highly intertwined system

  • High maintenance costs due to the complexity of the monolithic platform

The focus should always be on using the best tools on the market. If a job requires a hammer, invest in the best hammer available. Avoid buying a multi-tool that promises to do everything, or a toolbox full of everything you might possibly need. 

With DXP, the best advice is to build your own tech stack - one that contains the specific tools you need, perfectly optimized for your requirements.