Can monolith really evolve into a composable DXP?

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?

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

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.

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.

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.

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.

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.