The growing use of cloud data warehouses will challenge how we think about martech stacks. It might even lead to an unbundling of applications from the data they activate.<\/p>\n
Don\u2019t underestimate the significance of this revolution, already happening under the banner of \u201ccomposability.\u201d<\/p>\n
The meaning of \u201ccomposability\u201d<\/h2>\n
Who hasn\u2019t heard talk recently about the \u201ccomposable CDP\u201d \u2014 a solution, that is, that calls itself a CDP but that, rather than ingesting data, activates data located in a data warehouse? The label is a little misleading because \u201ccomposability\u201d is really a much broader term. Composability really just means the ability to stitch different solutions together. <\/p>\n
Providers of digital experience platforms (DXPs), for example, have been talking about composability for at least two years. Typically, these platforms offer a CMS, intelligent content and product recommendation tools, sometimes an integrated CDP, sometimes a digital asset management system. What they mean when they say their offerings are composable is that you don\u2019t have to invest in the whole suite. If you have a DAM you like already, you can hang on to it and plug other components of the DXP into it.<\/p>\n
Notice, there\u2019s no reference to data warehouses here.<\/p>\n
But the sense of composability we\u2019re discussing here is that much narrower one (perhaps misused, but now so commonly misused as to be standard) in which applications are stitched specifically to data located in a data warehouse, the warehouse typically holding company-wide data, not just customer data.<\/p>\n
The composable CDP<\/h2>\n
As we\u2019ll see in another article, this narrower sense of composability doesn\u2019t just relate to CDPs, but it\u2019s in the CDP space that it\u2019s most commonly used. Let\u2019s start with the traditional definition of a CDP: <\/p>\n
\n\u201cPackaged software that creates a persistent, unified customer database that is accessible to other systems.\u201d<\/p>\n
CDP Institute, \u201cWhat is a CDP?\u201d<\/a><\/cite><\/p><\/blockquote>\n
The composable CDP does not, essentially, create a persistent, unified customer database, but relies on data located elsewhere. A number of established CDPs, like ActionIQ for example, now offer a composable model alongside their traditional offering. Examples of natively composable CDPs might be Hightouch or Rudderstack, although some would argue that they\u2019re not really CDPs at all. <\/p>\n
\u201cReverse ETL, a fancy name for data extraction, that\u2019s what Hightouch originally did,\u201d said David Raab, founder and CEO at the CDP Institute. \u201cThey\u2019ve now expanded to add other modules. Rudderstack or Census are still pretty much reverse ETL vendors and that\u2019s it. I\u2019d need to look at their current product offerings, but anyway that\u2019s how they started out.\u201d Reverse ETL is one way of pulling data from a data warehouse for activation purposes.<\/p>\n
\u201cA \u2018composable CDP\u2019 is not a CDP,\u201d Raab argued, \u201cit\u2019s a CDP component. We try to avoid the term, but the market is really with it so you can\u2019t avoid it altogether or people won\u2019t know what you\u2019re talking about.\u201d Raab thinks \u201cwarehouse-native CDP\u201d is a less misleading term than \u201ccomposable CDP.\u201d \u201cIT departments relate to the term \u2018warehouse-native\u2019 but marketing departments relate to the term \u2018composable,\u2019 so you can\u2019t just not use it.\u201d<\/p>\n
Dig deeper: Composable<\/strong>\u00a0CDPs: How do they differ from packaged solutions?<\/a><\/em><\/strong><\/p>\n
The lakehouse CDP<\/h2>\n
As if terminology in this space wasn\u2019t already confusing, earlier this year Amperity boldly announced the first \u201clakehouse CDP.\u201d The first thing to note is that data \u201clakehouses\u201d (Databricks offers one, as does Google Cloud and Microsoft Fabric) combine the characteristics of data warehouses (organized structured data) and data lakes (large scale raw data).<\/p>\n
The second thing to note about Amperity\u2019s offering is that it enables zero-copy data sharing to and from the lakehouse. In other words, customer data can be activated in Amperity by marketing teams without making and storing a copy of that data. This proved to be a controversial claim.<\/p>\n
Tasso Argyros, founder and CEO at ActionIQ, has written about the different ways composable CDPs can activate data from a data warehouse (or lakehouse): ETL (batch data copying); data sharing through a data connector; or query pushdown in which data is queried in the warehouse but not copied (ActionIQ\u2019s approach).<\/p>\n
Of the zero-copy option offered by Amperity (and Salesforce), he said:<\/p>\n
\n\u201cDespite their imaginative language, the data is again copied from the customer\u2019s warehouse to the vendor\u2019s own warehouse and CDP. The data copy is now simpler and faster, which is an enhancement. However, it still results in data residing in two locations with divergent data models as soon as the data is edited or enhanced.\u201d<\/p>\n
Tasso Argyros, LinkedIn<\/a><\/cite><\/p><\/blockquote>\n
We spoke to Barry Padgett just before he transitioned from the CEO role to being an advisor at Amperity. \u201cInstead of pulling data out of the data warehouse and shoving it into some other system, that other system can just read that data directly from the system. It doesn\u2019t need to pull that data and make a copy,\u201d he said.<\/p>\n
He was familiar with the Argyros argument. \u201cWe exist in a noisy space where people have a lot to say,\u201d he mused. \u201cIf you want to pull data from the lakehouse and not do anything interesting to it, you\u2019re sort of limited. You can just read the data or you can query some subset of it. Of course we have to read the data \u2014 if we don\u2019t read the data our system is useless. As an output of what we do, we create data.\u201d Amperity\u2019s AI capabilities are in play here. \u201cThat\u2019s not copying data from the source. We\u2019re deriving insights from that data by running AI. We\u2019re building new data assets; that\u2019s the distinction.\u201d<\/p>\n
The new data asset can be shared with Amperity\u2019s CDP, but that\u2019s not the same as copying the original data, Padgett argued. \u201cI get that it\u2019s frustrating to have nuance, but there\u2019s just nuance here.\u201d<\/p>\n
Why composable (or lakehouse) CDPs and why now?<\/h2>\n
Lakehouse, said Padgett, is not Amperity\u2019s term. It rose to prominence with some of the marketing language Databricks was using. He explained: \u201cTen years ago we were building data lakes and consolidating data. Then there was the rise of the cloud data warehouse. The warehouse was great for running SQL queries; the data lake was good for more complicated stuff, especially AI. Now, what\u2019s the name for that combined infrastructure where you can do all that stuff? \u2018Lakehouse\u2019 seemed pretty close. It really is just data lake plus data warehouse.\u201d<\/p>\n
But doesn\u2019t a lakehouse CDP depend on customers having\u2026lakehouses? \u201cIt does seem like a space that\u2019s really hot right now,\u201d said Padgett. \u201cWe\u2019re certainly seeing all the major vendors following a path there; we\u2019re anticipating that AWS will join the party.\u201d Amperity created something it calls Bridge, a layer that adapts Amperity\u2019s functionality to the various lakehouses out there. \u201cAs new platforms emerge, we\u2019ll just make a new Bridge.\u201d<\/p>\n
The traditional CDP evolved as a solution, said David Raab, because companies were not providing actionable customer profiles through their IT deparment or from their data warehouses \u2014 certainly not for marketers. \u201cWhat\u2019s happened now is that the data warehouse has gotten a little better in terms of technology,\u201d he explained, \u201cand the motivation for IT departments to meet those needs has gotten much stronger, because not only marketing, but customer service, sales and operations are all looking for usable customer profiles. Once it becomes an enterprise problem rather than a marketing department problem, the enterprise IT and data teams become engaged in looking for solutions.\u201d<\/p>\n
Extending the data warehouse can contribute to such a solution and there\u2019s also value in leveraging an existing investment rather than building something new. \u201cWhat composable does,\u201d he said, \u201cis give them a few more tools because instead of having to build a data extraction or ETL tool from scratch they can go out and buy one that is quite nice and quite mature. Composable CDPs are making their money by making what IT departments want to do a little easier.\u201d<\/p>\n
But whether an organization leverages a traditional, packaged CDP or leverages its data warehouse using so-called composable tools, it\u2019s attempting to meet the same need for actionable, unified customer profiles.<\/p>\n
Composable CDPs are, however, only part of the composability revolution that seems set to change the face of the marketing stack. Customer engagement platforms are now playing the same game, as we\u2019ll see in the next article in this series.<\/p>\n
Dig deeper: The truth behind martech stack\u00a0composability<\/strong><\/a><\/em><\/strong><\/p>\n
![\"2024](\"https:\/\/i0.wp.com\/martech.org\/wp-content\/uploads\/2024\/06\/2024-replacement-survey-logo.png.webp?resize=549%2C354&ssl=1\"\/){kind=logo}
![\"2024](\"https:\/\/i0.wp.com\/martech.org\/wp-content\/uploads\/2024\/06\/2024-replacement-survey-logo.png.webp?resize=549%2C354&ssl=1\"){kind=logo}
<\/a><\/figure>\n<\/div>\n