The rise of the Composable DXP

Composable DXP

What is the Composable DXP and what does it mean for you? 

Development Composable DXP
17 mei 2022
Ruud van Falier

Content Management Systems(CMS)

Around the turn of the millennium, digital strategy became increasingly vital for many businesses. Websites transcended their role as mere business cards, growing in functionality, complexity, and content volume. To address this growth and ensure manageability, Content Management Systems (CMS) came into play. Initially, they had a straightforward objective: to manage the content of web pages—text, images, and links. Often, this involved a user interface designed for database management. 

Building the visual presentation of websites was custom-made during that time. The CMS later adapted to this: the visual presentation (rendering) of web pages became a functionality of the CMS. Users were now able to manage not only the content but also the visual structure of pages from the same system. 

As websites became more complex and richer in functionality, Content Management Systems were further expanded. Features for:

  • Personalization
  • Email marketing
  • Customer profiling
  • Analytics
  • A/B testing
  • Multi-channel delivery. 

The CMS evolved into a single system that provided all the functionalities needed to manage a complete digital experience: a Digital Experience Platform (DXP).

Two examples of DXPs that we work with at Human Digital are the Sitecore Experience Platform and Kentico Xperience. Both are based on Microsoft technology and provide an all-in-one solution for a digital platform.

Disadvantages of a 'monolithic' DXP

The all-in-one solution is also known as a monolith, a monolithic DXP. In many cases, it provides a solid solution, but there are also drawbacks, three of which we will elaborate on.

Monolithic DXP can do many things well but excels in none

The monolithic DXP is a versatile all-in-one solution, offering numerous features that address specific issues. As an overall package, it often provides a satisfactory solution. However, when you examine individual features, they generally do not match up to a product that specializes in that specific function.

A simple example is the digital asset management (DAM) feature, handling media files such as images and videos. The monolithic DXP usually provides a Media Library for uploading and organizing digital assets, with perhaps some additional features for resizing and cropping. However, its capabilities often fall short in comparison to a product specialized in DAM.

How does this compare to a specialized Digital Asset Management (DAM) solution like Bynder? Bynder DAM offers the capability to manage vast amounts of digital assets, assign metadata for searchability, and automatically transform assets using filters, for example. Functionally, it provides many more capabilities than the average Media Library in a DXP.

In this example, Bynder DAM is a Best of Breed system; by specializing in addressing a specific issue, they can fully focus on it and deliver the best possible solution for that particular problem. This is not applicable to an all-in-one system where attention must be divided among various functions.

Limited scalability

Due to the integration of all feautures within the DXP into a single system, scalability is inherently limited. 

Take, for instance, the example of the Media Library. When the number of digital assets grows, reaching, for example, 100.000 items, ideally, you would want to scale only the Media Library component of the system. However, this is only achievable if the entire system is scaled. 

More complex platforms, such as the Sitecore Experience Platform, offer the capability to independently scale specific components of the platform. However, the granularity with which this can be done is determined by the DXP. Even with platforms like Sitecore XP, it is not possible, for instance, to scale only the Media Library without scaling other content management functionalities. 

Even with the ability to scale specific components independently, a challenge arises: you must handle the scaling yourself. Typically, you are responsible for hosting the DXP and, consequently, for scaling the infrastructure. Cloud services such as Azure provide excellent tools for this purpose, but ultimately, you still need to set it up and manage it yourself.

Development frameworks

The development methodologies and frameworks employed for building your digital platform are often dictated by the DXP. If you are developing a platform using the Sitecore Experience Platform, for instance, the foundation is based on the Microsoft .NET Framework and C# (simplified for clarity). On the other hand, if you are developing for Adobe CXM, the emphasis is on Java.

The visual presentation of web pages is managed by the DXP, but to achieve this, you must align with the way the system constructs these pages. For instance, if the DXP utilizes traditional .NET Framework MVC for components, your team may face challenges if they intend to leverage .NET Core.

Composable DXP

A Composable Digital Experience Platform essentially refers to a DXP that is assembled from various independent, best-of-breed systems, often built on Software-as-a-Service (SaaS) models. Given the foundation in SaaS systems, there is typically a cloud-native architecture in place. The premise is that everything operates in the cloud, and the responsibility for the functionality, availability, and scaling of the components of the Composable DXP rests with the respective SaaS providers. 

Best of breed

One of the most significant advantages of a Composable DXP over a monolithic DXP is the ability to select the best possible solution for each specific purpose, tailored to your organization. For example, it's not necessarily the case that Bynder DAM is the best DAM solution for every organization and scenario. Your business might have specific requirements for which Sitecore Content Hub DAM provides a better solution. With a Composable DXP, you have the freedom to make these choices according to your organization's needs. 


The potential combinations that lead to a Composable DXP are limitless. Below, we have outlined an example of a combination of products that collectively form a unified DXP.

  • Content Management: Kentico Kontent
  • Digital Asset Management: Bynder DAM
  • Personalization & Testing: Uniform
  • Forms Builder: Jotform
  • Email Marketing: Sitecore Send
  • Search: Elastic Site Search
  • Analytics: Google Analytics
  • Front-end: Next.js
  • Site hosting: Vercel
  • Code repository: GitHub

As you can observe, we have the flexibility to choose systems, allowing you to opt for the exact solution that is most suitable for the task and aligns seamlessly with your organization.


When specific components of the system require increased capacity, such as a DAM expanding due to the growing number of assets or a CDN accommodating rising website traffic, the SaaS service responsible for that particular component addresses these needs. This horizontal scalability is no longer your technical concern; it is entirely with the purview of the SaaS providers. 

Should your organization evolve with additional requirements over time, new systems can be seamlessly added to the composable platform to meet those needs.

Reduced vendor lock-in

In the context of a monolithic DXP scenario, dependence on a single vendor, namely that of the DXP, develops quickly. As you utilize all components of a DXP, over time, all your content items, assets, customer data, and email marketing data become stored in a single system. Custom code required to operate the backend and frontend of your platform relies on the frameworks and SDK provided by the DXP vendor. This makes it exceptionally challenging if you intend to migrate (part of) the platform to a different product from another vendor, creating a vendor lock-in situation. 

With a composable platform, consisting of standalone products, it becomes much easier to replace one of these products without overhauling the entire platform. If the DAM no longer meets your requirements, you can replace the DAM while continuing to use the same CMS, personalization engine, and email marketing tools. 


A Composable DXP is closely aligned with the Jamstack architecture. Without delving into an overly technical explanation (which we'll reserve for a future article), Jamstack is an architecture for websites that are predominantly pre-generated and therefore static, enabling them to be served directly from a Content Delivery Network (CDN). This approach allows for the best possible performance. 

Because Jamstack sites are pre-generated, there is no need for server-side processing when a visitor requests a page. Dynamic elements are handled and loaded from APIs on the browser side. 

Not only does this result in low response times for your website, but the hosting costs for Jamstack websites are also very economical. Geographically distributed 'edge' hosting with 1 TB bandwidth can be obtained for as low as $20 per month through services like Vercel and Netlify.

Technical Freedom

Finally, we want to highlight the technical freedom you experience when developing a composable platform. All services comprising the platform are integrated through APIs, making the underlying technology between those APIs irrelevant. If your development team prefers Python, you can seamlessly integrate everything with Python. If you are proficient in .NET Core, you can use that as well. The flexibility to choose technologies based on your team's expertise is a key advantage of a composable platform.

Current state of affairs

This article delves into the rise of the Composable DXP. If you're somewhat familiar with the digital experience realm, you likely encounter the term multiple times daily. However, despite the increasing popularity of Composable, the monolithic DXP remains widely embraced. Composable is on the rise but is far from being the standard. 

The concept of acquiring an all-in-one-ready-made platform with immediate access to all tools remains an appealing notion. Dealing with just one vendor for the entire platform has its advantages - it can be a disadvantage if you decide to switch, but it's a benefit as long as you're working with it. For the agencies implementing the DXP, it's also attractive, as you easily consolidate all expertise related to that single platform, as opposed to dealing with various available SaaS services.

There is also a small piece of the Composable DXP puzzle missing, a feature most monolithic DXPs typically provide: wysiwyg (what you see is what you get) editing of web pages. Since you are responsible for building the front-end, often based on Jamstack that relies on statically generated sites, you also need to provide your own wysiwyg editing capability. Where significant developments can be expected in the coming years is in the realm of Front-end as a Service (FEaaS or FaaS): SaaS services that enable you to manage the construction of your web pages and facilitate 'live' designing of your pages. 


It is evident that there are limitations to the monolithic DXP and how the Composable DXP can bring improvements in those areas. While there continues to be a need for the monolithic DXP, and that need is likely to persist for a long time, the Composable DXP is expected to continue gaining popularity in the coming years. 

Where the DXP used to be the starting point, we now begin with business requirements and business architecture, searching for the best tools that align with these needs. Instead of independently translating client requests into a technical custom solution, the focus is shifting towards finding specific SaaS services that can perform these tasks for us and excel in their respective domains; Best-of-Breed.

If you have any questions or would like to engage in a discussion on this topic after reading this article, please feel free to reach out to us at

This site uses anonymous cookies. Click on "Agree" if you agree to the use of cookies, or click on "Change" to determine your preferences.
This site uses anonymous cookies.