Every so often a term gets used so often, and explained so badly, that senior leaders start nodding along to it without anyone admitting they'd struggle to define it. "Composable architecture" is having that moment. So let me try to explain it the way I'd explain it to a managing partner over coffee, rather than the way it gets explained in a vendor deck.
Think of Lego. Different pieces, joined in different configurations. Build a tower, take it apart, build a house instead. Swap a piece out when it stops serving you. That's the whole idea. Composable architecture means bringing together separate technical components in whatever arrangement suits the job, rather than buying one enormous system that promises to do everything and quietly does most of it badly.
The glue is APIs - the connections that let systems talk to each other and share information. Get those right and you can plug things together and pull them apart. Your CRM talks to your website, so enquiries land with the right person without being re-keyed by hand. The same data updates the app, or builds the proposal, so a client's experience from first enquiry to signed contract doesn't feel like it's been assembled by four teams who've never met.
The bit nobody warns you about
Here's where I'd push back on the usual pitch. Composable architecture is sold as a technology decision. It isn't - or rather, it isn't only that. It asks three things of you, and two of them have nothing to do with code.
You have to change how you think about technology. Most organisations are used to thinking about their tech stack as a fixed structure. Something you buy, install and then live with for seven years while quietly resenting it. Composable asks you to treat it as a set of pieces you'll rearrange as needs change. That's a genuinely different posture, and it's a harder shift than it sounds.
You may have to change how you're organised. Departmental silos tend to form around systems - the team that "owns" the CRM, the team that "owns" the website. When the systems become interchangeable, those boundaries start to look arbitrary. Structures organised around outcomes tend to work better than structures organised around bits of software.
And you have to actually invest. Not just money, though there's that. You need the discipline to buy things that are genuinely modular and compatible with what you already run. Buying a closed system and calling it composable because it has an API is a bit like buying a caravan and calling it a Lego set.
Composable architecture is sold as a technology decision. It's really a decision about how willing you are to change your mind later.
So what do you actually get?
Four things, in my experience, and they compound.
You get better experiences for your clients, because connected systems let you build a journey that feels like one organisation rather than several. You get scalability - a product that starts life as a website can grow a mobile app, a portal, a client dashboard, without you rebuilding the foundations each time. You get flexibility, which is really just the freedom to change your mind when the market does. And, because of all three, you tend to get lower costs over time, since you're rearranging what you already own rather than commissioning another rebuild.
That last point deserves a caveat, because I'd rather be honest than persuasive. Composable is not cheaper on day one. It's cheaper on day one thousand. If your board is looking for a saving this quarter, this isn't the story to tell them.
Is it right for you?
Not always. If your requirements are genuinely simple and stable - and some firms' are - then a well-chosen off-the-shelf platform will serve you better than a set of components you now have to own and maintain. Composable buys you optionality, and optionality has a price. The question is whether you'll actually use it.
So here's the question I'd sit with. Over the last three years, how many times has a change you wanted to make been blocked, delayed or quietly dropped because "the system won't let us"? If the answer is none, stay where you are. If you've lost count, that's not a technology problem you're describing. That's the cost of a foundation that can't move as fast as you need to.
Worth a conversation? Book a short discovery call with the team at Distinction - no pitch, just an honest read on whether your foundations are holding you back.
