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 …
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. (Source
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 important 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.
- 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.
- Tied to that is build vs buy. A composable CDP means you have to select all the components. Do you want to do that?
- 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 monitor them and keep them going?
- 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.
- 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
