Composable vs. packages customer data platforms -- what's the difference?

As if the CDP landscape wasn’t complicated enough, now we have the additional complication of composable vs. integrated, or packaged CDPs.

To unpack this, let’s start with composability. From Wikipedia …

Composability is a system design principle that deals with the inter-relationships of components. A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements. In information systems, the essential features that make a component composable are that it be:

self-contained (modular): it can be deployed independently – it may cooperate with other components, but dependent components are replaceable
Stateless – which means it treats each request as an independent transaction

Although not everybody agrees with the stateless requirement.

Proponents of the “composable” CDP [I’m citing an article that I’ll link below] see the CDP itself as a software platform that could be broken up into components. Their argument is that companies should not buy an all-in-one CDP to handle everything from data collection, to integration, to profile unification, but rather purchase separate components for each function.

It’s not clear to me that a “composable” CDP is actually a CDP. One of the main distinguishing marks of a CDP is that it creates a comprehensive view of each customer. But in a composable environment, that may be happening in other places, like in the data warehouse.

The question, of course, is not whether a composable system meets somebody’s definition of a CDP. The question is whether it will work for your use cases and your staff. I can help you figure that out.

Here are five things to consider about composable CDPs.

1. The Swiss army knife question. None of the tools on a Swiss army knife are best of breed. They’re basically adequate. But the point is that if you have a Swiss army knife, you have all those tools at your disposal. When you evaluate CDPs, keep that analogy in mind.
2. Tied to that is build vs buy. A composable CDP means you have to select all the components. Do you want to do that?
3. Closely related to build vs. buy is how many integrations do you want to make? Integrations can be tough to build and maintain. They break. Do you have a team to keep them going?
4. Do you have a data lake, or a data warehouse? If so, you might think it’s duplicative to also dump everything into the CDP.
5. Are you a data-driven company, and do you have data engineers on staff? If so, the composable option might be good. If you think of “CDP” as a function rather than as a platform, why does the data have to live in any given bit of software?

That’s a very short introduction to the subject. If you want to know more, read the first link below, or give me a call and we can chat about it.

Sources

Composable CDP Vs. Integrated CDP: What’s The Difference?
https://cdp.com/articles/composable-cdp-vs-integrated-cdp/

What is a CDP?
https://www.cdpinstitute.org/learning-center/what-is-a-cdp/

Composability
https://en.wikipedia.org/wiki/Composability