When a new idea catches on, confusion often results regarding what it entails and what it actually means. Over the last two years, there has been a lot of buzz about "composability" and now "composable DXP” in the sphere of digital experience platforms (DXPs). The Q&As below clarify the ins and outs.
Apps that you pick are essential for your mobile phone, on which they run and interact with one another. Similarly, the fact that you can select the apps you want is the basic idea of composability.
Integrated products are, at a minimum, connected in some way. A composable system means that its components were selected by a brand and then integrated. Without integrated components, the system is not composable.
However, systems that comprise integrated components are not necessarily composable. For example, although Microsoft Office consists of integrated components (Word, PowerPoint, Excel, etc.), it’s not composable, and you cannot, say, replace Word with Google Docs.
With a DXP, you can build, manage, and deliver omnichannel experiences. A composable DXP means that you get to choose the tools—just as you pick the apps for your phone—for your tasks. So you can select the CMS you want to use and the analytics system you want to use and the personalization tool you want to use, etc.
One alternative to a composable system is a monolithic one. For example, the capabilities of the mobile phones before iPhone and Android were built by a single vendor. You could not replace the apps on the phone or add new ones. Back in those days, that was no 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 those legacy phones.
Another alternative for composable is the product suite, such as Microsoft Office, a collection of products from a single vendor that work together to an extent. You might be able to buy the products separately and integrate them with other products, but you cannot change the suite. Nor can you replace the products there without losing significant functionality.
It can be both. The early definition of composable DXPs called them an architecture. That’s because, if vendors offer products as components (for example, a headless CMS
) for easy integration by organizations into their own tech stack, a composable DXP would be born. Organizations like the MACH Alliance promote that kind of architecture.
Nonetheless, however "easy" it is to integrate components, it’s still challenging and risky because it requires custom development. Organizations that desire a composable, problem-free, and riskless DXP can opt for a “productized” composable DXP, which does the following:
Enable you to select the components for the DXP, adding, removing, or replacing them later on as necessary.
Perform integration and orchestration across those components.
That’s unlikely because it’s to the vendor’s advantage to get you to use its products, not a competitor’s. Remember, the hallmark of composability is that you—not the vendor—pick your tools. You can do that with a composable DXP, assured that those tools would work well together regardless of vendor. Without that freedom of choice, you’re left with a product suite.
Hence, the easiest way to determine if a vendor's product is composable is to find out what happens if you replace one of its components with a competitor's product.
To be clear, a composable DXP might not be the best solution for all organizations, nor is a composable architecture
inherently superior to the alternatives. The bottom line is that composability requires a commitment to openness and interoperability, which is what sets it apart from monoliths and suites.
There are three features that are missing in pure composable approaches taken by DXPs:
API orchestration, which makes it easier to integrate all your tools similar to how you did it in the past.
Governance, which ensures that you maintain control and agility even as you move faster.
Continuity, which guarantees a consistent experience for your audience even after you’ve added new technologies or channels.
Digital experience composition helps you build experiences with headless, API-first services like CMS, commerce, and DAM. Despite their many advantages for developers, composable architectures can be challenging and time consuming for marketers and business users, who must use several tools to perform tasks that used to be easy.
To address those problems, a new category of tools called digital experience composition
enables business teams to work independently and maintain control over experiences while offering technical and cost benefits for developers. An example is Uniform Digital Experience Composition Platform (DXCP)
, on which marketers can build composable experiences with no-code tools while developers own the back-end infrastructure. Among the platform’s many benefits for raising conversion rates are the following:
For details, schedule a free demo