Frequently Asked Questions about Composable DXPs
When a new idea catches the attention of a community, there’s often some confusion regarding what the idea entails and what it actually means. In the world of digital experience platforms (DXPs), there is a lot of talk about "composability" and "composable DXP.” I want to address some questions that frequently come up so you can be sure that what is being called "composable" actually is composable.
What is composability?
Think about your mobile phone. Without apps, that phone doesn't do you much good. The phone provides a place for the apps to run and a way for those apps to interact with one another. The fact that you're able to select the apps you want is the basic idea of composability.
What is the difference between integrated and composable?
When two or more products are integrated, at minimum it means they are connected in some way. (The word "integrated" has a lot of meanings. We’ve written a white paper to help you understand some of the nuances of integration.)
When a system is described as composable, it means that the components that make up the system were selected by a brand and then integrated. You can’t have a composable system without integrated components.
However, even a system consisting of multiple, integrated components isn’t necessarily a composable system. Although Microsoft Office consists of multiple, integrated components (Word, PowerPoint, Excel, etc.) it isn’t composable. For example, you cannot replace Word with Google Docs.
What is a composable DXP?
A DXP lets your organization build, manage, and deliver omnichannel digital experiences. A composable DXP does this as well, but with a key difference. Your organization gets to choose the components (like the apps on your phone) that provide these capabilities.
If a DXP isn't composable, what is it?
One alternative to a composable system is a monolithic system. Remember mobile phones before iPhone and Android? A single vendor provided all the capabilities for you. You couldn't replace the apps that came on the phone, and you couldn't really add new ones. Back in the days of flip phones, this design wasn't a problem because it was the only option available. Today, unless you are making a conscious statement about the effect of technology on society, you probably wouldn’t be satisfied with the experience offered by that kind of phone.
Another alternative is the product suite: a collection of products from a single vendor that work together to some extent. Microsoft Office is an example of a product suite. You may be able to buy the products in the suite separately, and you may be able to integrate those products with other products, but you cannot change the suite. You can’t replace any of the products in the suite without losing significant functionality.
Is a composable DXP an architecture or a product?
It can be both. The earliest discussions of composable DXPs treated it as an architecture. The idea was that if vendors would provide their products as components (for example, a headless CMS) that were designed in a way that made it as easy as possible for an organization to integrate the components into their own tech stack, a "composable DXP" would be possible. Organizations like the MACH Alliance promote this kind of architecture.
But however "easy" it is to integrate components, integration is still challenging and risky. That’s because it requires custom development. Organizations that want a composable DXP but without the challenges or risks have an alternative. They can opt for a “productized” composable DXP. This product:
- Enables an organization to select the components that make up the DXP.
- Provides integration and orchestration across those components.
- Allows an organization to add, remove, and replace components as needed.
If a DXP ships with products from a single vendor, is it composable?
It is certainly possible, but unlikely. That’s because the vendor is highly motivated to get you to use its own products, not a competitor’s. Remember, the hallmark of composability is that you - not the vendor - select your tools. A composable DXP lets you choose those tools and ensures that those tools work well together, regardless of which vendor built them. When you remove the option of choice, you are left with a product suite.
The easiest way to determine if a vendor's product is composable is to consider what happens if you want to replace one of the vendor's products with a competitor's product.
To be clear, I am not arguing that a composable DXP is the best solution for all organizations. Nor am I arguing that a composable architecture is inherently superior to the alternatives. But today there remains some confusion regarding what composability is and what a composable DXP offers. What I am arguing is that composability is something that requires a commitment to openness and interoperability, and that is what sets it apart from monoliths and suites.