178: What is "composable software" and how does it work?

There’s a scene in The Good, The Bad, and the Ugly where Tuco – he’s the ugly guy – goes into a gun shop, examines several revolvers, takes the parts that he likes from each and puts them together to make a revolver that suits his preferences.

That’s composability.

The problem with buying software is that you buy 100 percent of it, but often you only use 20 percent.

For example, your email software can do marketing automation, but so can your customer data platform. So in one place or another you’re wasting that function. And your customer data platform can do content recommendations, but so can Outbrain. So you buy more functions than you can use.

When a company buys a new service for their tech stack, they’re often only adding a small portion of that new service’s capabilities.

Imagine that you could get a demo of a software suite and say, “That part doesn’t interest me, but your recommendation engine is great. Can I have just that piece?”

It sounds lovely. You’d have modular, interchangeable components, like building blocks. But the only way that could work would be if all the pieces had a standard type of connector, like Lego blocks. All Lego blocks have the same size connectors.

Software doesn’t work that way. It would be great if it did, but … it doesn’t. Sometimes by design. Apple doesn’t want to make things compatible with Android and vice versa.

So what does it mean when people talk about composable customer data platforms?

It means they’ve designed the CDP to be modular, allowing organizations to tailor their customer data infrastructure to their specific needs and objectives. The system is supposed to have interchangeable and interoperable parts or components, so that you can plug in any email service provider, any database, any business intelligence tool, and so on.

But it’s not quite like Tuco at the gun shop. You can’t pull this piece from here and this other piece from over there, and assemble your own system.

For one thing, all these allegedly modular components aren’t always priced that way. You still have to buy components that you don’t want.

Another issue is that even if the CDP were completely composable, so that you could pick and choose a la carte, there’s no accepted standard for how all these pieces are supposed to work together.

Think of the industrial revolution. We standardized parts so that one factory could make one part, another factory could make a different part, and somebody else assembled it. That only works because of cooperation between the different factories. They have to agree on specs.

In the software world, this becomes “integrations.” You need to build special connectors between different modules.

While “composability” sounds great in theory. It sounds like we’re taking the lessons of the industrial revolution and applying them to software. But it doesn’t seem to be working quite yet. There are still too many custom formats and custom layouts, so we’re still stuck with building bespoke tech stacks where there’s duplication of function and a lot of inefficiency.