Lately, I’ve been excitedly talking about “composability” as a major new trend in martech (and business technology in general). But in the absence of defining it more precisely, the term has triggered some confusion and debate about what is or isn’t technically feasible today.
So let’s rectify that.
In the most broad sense, composability is simply the ability to combine things together. This might be data, for instance, if you want to analyze products (one dataset) that have been sold to customers (another dataset). Or it might be steps in a workflow, app, or customer experience — e.g., when a prospect fills out a form, add or update them in your CRM and email them the report they requested.
So, wait, this doesn’t sound very new. Haven’t people been doing that for decades?
Yes! If we look at this spectrum of composability that I’ve sketched — I’ll explain it in more detail in a moment — some ways of composing things together have been around for ages.
Spreadsheets are probably the oldest “no-code” tool for business users to “compose” data analysis by combining different lumps of data together on a sheet — or, more ambitiously, in a workbook — where they could manipulate them into something insightful. Historically, most of those lumps of data were either manually typed in by the user or imported from a CSV file. Not exactly state-of-the-art data pipelining. But effective. Marketers have gotten a ton of mileage out of Excel and Google Sheets.
On the more technical end of the spectrum, programmers have been “composing” apps by using packaged functionality from reusable libraries for the past half century. The concepts of encapsulation, modularity, and reusability have been foundational to the discipline of software engineering. No developer writes everything from scratch. They pull in existing libraries — Python has over 400,000 such packages — or API services in the cloud from AWS, Azure, or Google Cloud to assemble an app. They stand on the shoulders of others who came before them and try to only add net new functionality or the logic of how these pieces fit together for a specific purpose.
Trading granularity/flexibility vs. guardrails/safety
I keep putting “composability” in quotes above because while spreadsheets and software libraries are used for composing things, the more modern notion of composability seeks to bend the trade-offs between these two opposite ends of the spectrum.
There’s been a kind of Pareto curve between granularity of composability (how much control do you have at the most minute level) and guardrails for composability (how constrained are you in what you can do, often for your own good).
Composing with code, with a high-degree of granularity, has required significant technical expertise. It gave you essentially unlimited flexibility in what you could build. But all that freedom was a double-edged sword. You could easily hurt yourself by accidentally doing bad things. Bug city, baby.
In contrast, using a basic spreadsheet — without any fancy scripting or advanced function calls — would let you combine data together. But you could only work with “small data” that fit into a tabular format that was a static snapshot in time. You couldn’t execute workflows or build apps with it. This was significantly more limiting than programming with code. But it was much, much safer. The guardrails of what you were able to do and not do within a spreadsheet kept you from hurting yourself, at least in a technical sense. (You could still hurt yourself with shoddy data analysis presented to a skeptical CFO, but that’s different.)
Much of the innovation in composability over the past 5-10 years has been filling in the middle between these two ends of the spectrum. Low-code platforms could build apps or workflows with a little less flexibility but safer guardrails. No-code products even more so. Pick your preferred trade-off point along the curve.
Many contexts for composability in marketing
“Filling in the middle” between the dangerously-unlimited and the safely-constrained incarnations of composability has been a boon for marketing and martech. A lot of the innovation here has been a result of narrowing the context of a particular platform or tool, so as to put guardrails around that context but provide a lot more flexibility within it.
Sorry, that’s a bit abstract. A couple of examples to illustrate the power of context…
No-code website builders took off because they narrowed the focus to creating pages that had limited technical functionality and set design boundaries with themes and templates. This gave non-technical marketers tremendous freedom to quickly, easily, cheaply publish great-looking landing pages and microsites, with low-risk of technical error.
Any content marketer could now compose a web page from pre-built components within the no-code website builder’s editor.
On the more technical side, CDPs have been a heck of a lot easier for technical marketers to work with than raw databases, because they operated within the context of creating customer profiles and audience segments explicitly for marketing use cases. They enabled more freedom for how data could be ingested and composed into operational marketing datasets than the “closed” marketing suites that came before them. But the operations of how such data was leveraged — which could get more technically complex — was often downstream from the CDP itself. This made the environment inside the CDP safer to work in, at least relatively speaking.
Yes, I know, you can still make mistakes — big mistakes — with data inside a CDP and the things you execute with that data downstream. But those risks are much more controlled than the open-ended, Wild West of writing Python programs against a generic relational database.
Any data-savvy marketing operations professional could now compose audiences within a CDP, assembled from multiple sources of data.
Now, the term “composable CDP” has come to mean something more specific. Instead of having to copy data into your CDP to use it, composable CDPs let you use data directly from your cloud data warehouse without copying it. This has advantages of reducing storage costs, data desyncs, and security and compliance risks. In this sense, you’re composing across physical data storage in addition to composing logical datasets.
But setting aside the technical architecture innovation, the benefit of a composable CDP is to simply make it cheaper, easier, and faster to compose customer profiles and audience segments.
My point: everything described above is composability that exists in marketing today. To the degree that we don’t talk much about it explicitly, it’s actually a testament to how well this composability works. Composability is best when it’s almost second-nature in context.
So why is composability being talked about as something new?
A New Generation of Composability
This new generation of composability is riding a massive wave of API proliferation and the gravitational flow of more data into centralized cloud data warehouses (CDWs).
As applications expose more of their functionality via APIs — driven by the market demand for integration between apps — those APIs can be used to programmatically “compose” workflows and customer experiences that span multiple applications behind-the-scenes. As applications pipe more data into CDWs, it’s all stored in one universal and professionally governed location, where it can more easily be “composed” into context-specific datasets.
iPaaS and workflow automation products, such as Workato (enterprise) and Zapier (SMB), have long taken advantage of APIs to let low-code/no-code users orchestrate workflows across multiple apps. But as the number of APIs grows — and as deeper functionality is exposed through them — it becomes possible to not merely sequence integration tasks between apps, but to effectively craft your own custom apps with those API services used under the hood.
Here’s a metaphor: instead of the glue holding the timbers of a ship together, the glue becomes the surface of the ship itself, with the embedded timbers serving as a frame and a structural support inside. The glue is infinitely more malleable, and lets the shipbuilder create highly differentiated ship designs.
Okay, that’s an overextended metaphor. But do you get the idea?
There’s also a ton of innovation happening in building better “contexts” for composability in marketing. One approach that has a lot of runway is multi-level composability: an IT expert might define certain boundaries for composability, upon which a marketing ops manager might package up pre-defined bundles of data or functionality, upon which a non-technical marketer can assemble campaigns and programs from those ready-made components. Each level creates a “context” for the next level up.
However, the really exciting thing ahead for composability is generative AI.
You knew that was coming, right?
Generative AI engines will be able to understand the technical mechanics of writing code, invoking APIs, and mapping across multiple data sources on one side. On the other side, they’ll be able to accept natural language requests from more non-technical users and translate them into composed workflows and datasets.
This will effectively shift the accessibility of more advanced composability further within reach of less technical users. The likely second-order effect of this will be ever more customized internal digital operations and external digital customer experiences, crafted and adapted on-demand by everyone across the marketing org.
Generative AI will be able to push out the Pareto frontier of enabling more flexibility while simultaneously providing more context-specific guardrails because it will be able to understand the full enterprise architecture in which these requests are being made.
We’re not there yet — although it’s advancing quickly.
This is why I and many others are so excited about composability as a “new” thing these days. Composability-wise, we’re on the cusp of transitioning from rowboats to rocketships. But the core concept of composing things from point A to point B has been with us from the beginning.
