The DXP Catalyst Update - Aug 26, 2025

INTRO
Welcome to This Week’s DXP Catalyst Update

In this week’s DXP Catalyst Update , we look at how “composable” has become one of the most widely used terms in the digital experience space and why not every claim matches reality. Legacy vendors are now describing their platforms as composable, even when the underlying architectures and licensing models remain rooted in traditional approaches. Meanwhile, some vendors were built around composability from the very beginning, while others had the vision and execution needed to successfully transition their platforms toward composable architectures over the past few years.

This edition explores how to distinguish real modular flexibility from marketing spin, and why the distinction matters for IT and marketing leaders making platform decisions.

LEADERSHIP GUIDANCE

The Composable DXP Debate: Marketing Rhetoric vs. Architectural Reality

Composable digital experience platforms (DXPs) are built around the principle of flexibility. Instead of one monolithic system controlling content, personalization, search, and commerce, a composable stack is assembled from modular services that can be swapped out as needs evolve. It offers clear benefits: faster innovation, reduced vendor lock-in, and the ability to align best-of-breed tools with specific business requirements.

The term “composable” has gained so much traction that almost every vendor now applies it to their platform in some way. This creates a problem for buyers. When everyone claims composability, the term risks losing meaning. IT and marketing leaders are left to parse whether a vendor’s architecture genuinely supports modular flexibility, or whether the claim is primarily a branding exercise layered on top of older systems.

Legacy Vendors and the Composable Badge

Some of the longest-standing names in the DXP market have begun to describe their products as composable, even though their platforms remain largely tied to legacy models. OpenText, Liferay, and HCL are examples. These vendors continue to appear in some analyst reports, but less often in active RFPs. In fact, many organizations are exploring replatforming options away from them rather than moving onto them.

These platforms were built in an earlier era when enterprise portals and tightly integrated suites were the dominant approach. While incremental updates have added APIs or headless delivery capabilities, the underlying architecture remains complex, and the ecosystems are often closed. For buyers, this means that despite the composable messaging, the practical experience of working with these platforms still feels heavy, inflexible, and difficult to evolve.

The composable positioning may help these vendors maintain relevance in analyst reports, but buyers should treat such claims cautiously. Simply adding APIs or cloud deployment options does not transform a system into a truly composable DXP.

Hybrid Players: Sitecore and Acquia

Other vendors fall into a hybrid category. They have stronger market presence and more active customer bases, but their composable claims still outpace the lived reality. Sitecore and Acquia both position themselves as composable DXPs, but their ecosystems tell a more nuanced story.

Sitecore, for example, has repositioned itself aggressively around composable messaging over the past few years. Yet in practice, its ecosystem feels like a set of loosely integrated SaaS products, each with its own UI, licensing model, and deployment path. Customers often struggle with portfolio complexity, particularly when trying to upgrade from older Sitecore CMS products to somewhat newer SaaS offerings like XM Cloud. While APIs enable integration, the experience of managing the portfolio still carries significant friction.

Acquia markets itself as a composable DXP but continues to be deeply tied to Drupal. Initiatives like Drupal Starshot and Experience Builder represent important steps forward, yet the ecosystem still leans toward a Drupal-first mentality. Many of Acquia’s add-ons, such as personalization and DAM, are designed primarily to interoperate within its own ecosystem. This creates a form of ecosystem lock-in that runs counter to the flexibility promised by composability.

Both Sitecore and Acquia are way further along than legacy vendors, but they illustrate the gap between composable as a marketing term and composable as an architectural reality.

Composable-First Approaches

In contrast to legacy vendors, some players either started with composability as their foundation or made a clear pivot toward it when launching new platforms. Uniform is an example of a vendor designed composable from day one, focusing on orchestration across the stack without being tied to a single CMS.

Squiz offers an interesting case. While the company has a long history with its CMS and search products, it only formally launched its DXP offering in 2022. From the outset, that DXP was positioned as composable, reflecting a deliberate architectural choice rather than a retrofit. In that sense, Squiz can be seen as composable from day one of its DXP era, even if its earlier CMS history was more conventional.

Optimizely represents a different trajectory. With roots in Episerver and Ektron, it began as a more traditional suite vendor. However, strong vision and execution have allowed it to transition toward composability, with an API-first model and modular services now positioned at the core of its strategy.

This variety illustrates how vendors arrive at composability by different paths. Some, like Uniform and Squiz, embody it from the beginning of their DXP positioning. Others, like Optimizely, show how established players can successfully evolve into it. For buyers, the takeaway is that composability should be judged by the platform architecture and ecosystem today, not simply the vendor’s marketing language or legacy roots.

How to Distinguish Rhetoric from Reality

With so many vendors using the term, IT and marketing leaders need practical criteria for evaluating composability claims. A few signs help distinguish genuine composability from marketing spin.

First, consider how modular the platform truly is. If every product in the vendor’s ecosystem has its own licensing model and UI but only works seamlessly with other products from the same vendor, it is not fully composable. That is ecosystem lock-in dressed up as modularity.

Second, look at how interchangeable the components are. True composability means you can replace one service with another without disrupting the rest of the stack. If swapping out the CMS or personalization engine requires massive rework, the platform may not be composable in practice.

Third, assess the developer and operator experience. Does the platform support API-first integrations across a wide range of systems, or does it assume a particular backend? Does it provide tooling that simplifies orchestration across multiple vendors, or does it pull you deeper into its own ecosystem?

Finally, weigh the vendor’s business model. If the licensing and commercial terms push you toward buying bundles rather than discrete services, that is a strong indicator that composability is more of a marketing veneer than an operational reality.

Why the Distinction Matters

Some might argue that it does not matter how vendors define composability as long as the technology works. But in practice, the distinction carries major implications.

Organizations embracing composability are typically doing so to achieve flexibility, speed, and reduced risk of lock-in. If a vendor markets composability but delivers a tightly coupled suite, that promise is undermined. Businesses end up carrying the complexity of integration without realizing the benefits of true modularity.

This can affect budgeting, resource allocation, and roadmap planning. Leaders may expect faster time to market, only to encounter the same delays and bottlenecks that characterized legacy systems. Worse, they may find themselves locked into a single vendor ecosystem while assuming they had avoided that very problem.

The distinction between rhetoric and reality is therefore critical for setting expectations, managing risk, and ensuring that investments actually deliver the intended outcomes.

Final Thoughts

Composable architecture has reshaped the language of the DXP market. Nearly every vendor now claims to be composable, but the reality is uneven. Legacy vendors like OpenText, Liferay, and HCL have adopted the label without fundamentally changing their platforms. Hybrid players like Sitecore and Acquia have made progress but remain tied to portfolio complexity or Drupal-first ecosystems. Other vendors such as Uniform, Optimizely, and Squiz provide stronger evidence of what composability looks like in practice.

For IT and marketing leaders, the challenge is not simply listening to how vendors describe themselves but digging into how their platforms actually function. Ask whether the architecture supports modular adoption, whether components can be swapped without major disruption, and whether the licensing model aligns with the principles of flexibility.

Composable should not become a hollow buzzword. It should represent a real shift in how digital platforms are designed, purchased, and operated. Organizations that can separate marketing rhetoric from architectural reality will be better equipped to make smart platform decisions, avoid costly missteps, and build digital ecosystems that evolve as quickly as their customers do.