Of course, I would never say something untrue just to gain attention. So let me clarify exactly what’s deceased. It isn’t composability or CDP, or the vendors who have adopted the “composable CDP” label. What’s dead is “composable CDP” as a distinct category of software.
You might stop here to argue that “composable CDP” was never a meaningful category, and I wouldn't necessarily disagree. But the term did have a broad meaning along the lines of “software components that provide functions needed in a CDP.” What made it useful was the contrast with packaged (a.k.a. standard, conventional, traditional, integrated, or just plain “real”) CDPs, which, according to the CDP Institute definition, provide a complete set of CDP functions – specifically, the functions to collect, organize, and share customer profiles. Companies that wanted to build their own CDP, possibly using their existing data warehouse as a base, could use the “composable CDP” label to identify products that might help with their project.
What’s changed is that many of the packaged CDP vendors quickly caught on to the demand for CDP components and split their products into modules. This let companies buy only the functions they needed and apply those functions to data in a cloud data warehouse. The repackaging is easier for some vendors than others, depending on how their products were originally built. But enough of the original CDP vendors now offer some flavor of CDP components that companies looking for components to build an in-house CDP should consider them as well. Thus ends the utility of “composable CDP” as a category. RIP.
The composable CDP vendors saw this day coming. Many have switched their positioning to "warehouse-native," which is more accurate and reduces the focus on point solutions. But their main strategy has been to move beyond offering a single component for a single function – that is, their original product – to offer multiple components and a complete set of CDP functions.1 The change to offering a complete solution weakens some of the composable vendors’ original sales arguments, including the superiority of “best of breed” solutions and the ease of swapping components from different vendors “like Lego blocks”. But it also allows new arguments, including the virtues of buying multiple preintegrated components from the same vendor and the value to end users of working with fewer tools. If any of the vendors feels embarrassed at switching from one side of the debate to the other, I haven’t noticed.
Then again, there’s no reason they should be ashamed. Products naturally expand their footprints: it’s a marketing truism that it’s easier to sell new products to existing customers than to sell existing products to new customers. And CDP buyers clearly prefer integrated solutions: according to the CDP Institute Industry Update, nearly three-quarters of CDP products extend beyond profile creation to include marketing execution. In practice, only very large companies can afford to build custom solutions by cobbling together “best of breed” products. I summarized this years before CDPs existed as “Raab’s Law”, which states that “Given a choice, most buyers prefer suites over best-of-breed solutions.” The pithier version is “Suites win.”
This doesn't mean that most companies actually use integrated marketing suites. The majority clearly do not. In fact, a recent Acxiom survey found just 17% of marketers plan to move to a suite in the next twelve months; the rest are using multiple products and 29% expect to add more. Reasons companies don't adopt suites include cost, agility, and the lack of required functions. Still, when you look at marketing software categories including campaign management, journey orchestration, analytics, and email execution, leading independent vendors have been acquired by suite owners and the remaining independents are largely relegated to niche segments or have expanded to become suites themselves. This is what the composable CDP vendors are doing.
Wait, did I just say that an integrated CDP is a software suite? To some degree, yes: in the finest Alice-in-Software-Land tradition, words mean whatever I want them to mean.2 But the less flippant answer is that it depends on your perspective: in discussing CDP functionality, a single product that provides all necessary functions does look like a suite, while components for individual functions look like point solutions. But if you raise the perspective to marketing architecture, the CDP itself might be a single component alongside content management, marketing automation, email, and media buying components, while a marketing suite like Adobe would encompass them all. Go up to the enterprise level, and the marketing suite could be one component alongside finance, human resources, and operations, compared with an enterprise-wide suite like SAP.
It’s possible that Raab’s Law begins to weaken above the departmental level, where conflicting managers are powerful enough to insist on their own systems rather than accepting the loss of control implied by a shared system. Feel free to explore this on your own. What matters here is that talk of components reintroduces the topic of composability.
Although composable CDP only entered the martech discussion about two years ago, the broader label of composable architecture began to build momentum around 2020.3 Today it’s applied to nearly every type of software, and we see composable-oriented organizations like MACH Alliance expanding their scope accordingly.4
There’s actually a good chance that composability has hit its peak on the hype cycle, as greater experience gives practitioners a better understanding of its limits. As with composable CDP, these primarily involve integration costs and support complexity. They also include scaling challenges to move large volumes of data between large numbers of components, and problems when one weak component drags down performance across the entire structure. Call it the Revenge of Raab’s Law.
For composable CDP in particular, experience has also revealed high processing costs when everything is done within a cloud data warehouse. (This is why cloud data companies like Snowflake and AWS are so enthusiastic about the warehouse-native CDP approach.) Users have also discovered that the cloud data warehouses struggle with certain kinds of real-time processing, a core requirement for many CDP applications.
This more realistic understanding of composable limitations doesn’t mean that composability is dead. Marketers were never really all that interested to begin with: just 3% in the Acxiom survey said they plan to move to a composable strategy in the next 12 months, compared with 17% moving towards a suite.5 The people who really care about composability are the technicians: when Messagegears surveyed people interested in “data cleaning and quality control,” 56% said they prefer a composable architecture and 33% had no preference, leaving at most 11% in favor of packaged systems.
But don’t get too excited, composable fans: preference isn’t the same as intent, let alone action. You can bet many of those technicians won’t be able to make the changes they’d prefer.6 Still, the technicians’ views matter a great deal because growing use of customer data beyond marketing gives IT and data teams a larger role in selecting customer data systems.
Will technicians get over their infatuation with composability? Only time will tell. But it’s likely their ardor will cool as they learn more about it and get distracted by whatever Big Thing comes Next.
This doesn’t mean the the pendulum will swing back to favor traditional, integrated CDPs. Rather, as Hegel would have predicted, we can expect a synthesis where most customer data is assembled and remains in the warehouse, but some functions are executed outside of the warehouse in a CDP that reads the warehouse data directly. In this world, traditional CDP functions such as data ingestion and identity management become components that operate within the warehouse, while functions such as real-time response, analytics, and journey orchestration become part of a separate, internally-integrated component that can reasonably be labeled a CDP.
The composable CDP is dead. Long live the CDP components.
_________________________________________________________________________________
1. The definition of “complete” varies from vendor to vendor, and inevitably matches whatever components the vendor has available at any particular moment. But that approach is common throughout the software industry, so it doesn’t’ represent uniquely deceptive behavior by the composable CDP camp.)
2. See the previous discussion of “complete.”
3. The idea of building systems from components has been around much longer than the label, using terms such as micro-services architecture and headless CMS. CDP itself is also much older than four years. All these terms are much more widely used than composable architecture and composable CDP.
4. I’ve never spoken with anyone at MACH Alliance, but surely they face the same struggles maintain consistent definitions and standards as the CDP Institute. Fun fact: while several of the traditional CDP vendors have met the rigorous standards required to join the MACH Alliance, none of the composable CDP vendors are members.
5. The remainder intend to muddle through with their current crazy wall of loosely connected applications, while complaining about integration cost and feature overlap.)
6. How big is gap between preference and planning? Well, in the Acxiom survey where 3% of respondents said they plan moving to a composable approach, 36% said they thought a “modern sophisticated marketing stack” should have a composable architecture. Let’s call them composable-curious. Of the rest, 38% cited an integrated marketing suite, compared with 17% planning to move in that direction, and 34% chose a best of breed approach, compared with about 80% living that particular dream.
