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. I'll explain it the way I'd explain it to a managing partner over coffee rather than the way it appears 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 core idea. Composable architecture brings together separate technical components in an arrangement suited to the job. It offers an alternative to buying one large suite and accepting its way of handling every capability.
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 operating change that comes with it
The usual pitch presents composable architecture as a technology decision. It is also an operating-model decision. It asks three things of you, and two have little to do with code.
You have to change how you think about technology. Most organisations treat the technology stack as a fixed structure: something they buy, install and live with for seven years. Composable architecture treats it as a set of pieces that may be rearranged as needs change. That different posture needs continuing ownership, architecture decisions and change control.
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 invest. Money is part of it. You also need the discipline to buy components 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 potential benefits matter, and they compound when the integrations and operating model work.
You can create better experiences for clients, because connected systems can support a journey that feels like one organisation rather than several. You gain scalability when a product that starts as a website can add a portal or client dashboard without replacing every foundation. You gain flexibility when a component can be changed without reopening the entire platform decision. Those benefits can contribute to lower change costs over time when the organisation reuses interfaces and capabilities instead of commissioning another complete rebuild.
Lower long-term cost is a possibility, not a law. A composable estate introduces integration, monitoring, security, supplier and specialist-skill costs. On day one it may cost more than a suitable suite. The business case should show which future changes become easier, how often those changes are likely and who will operate the components between them.
APIs do not remove dependency
An API gives systems a defined way to exchange data or actions. It does not guarantee that the connection is complete, stable or inexpensive. Before selecting a component, check which operations the API supports, how it handles identity and permissions, what limits apply, how changes are versioned and what happens when either side is unavailable.
The dependency also moves. A suite concentrates dependency in one supplier. A composable estate spreads it across components, integration code, hosting and the team that understands the architecture. That can reduce the effect of one vendor decision, while making coordination more important.
Ask who will own the end-to-end service. A client does not care whether a failed form belongs to the website component, integration layer or CRM. Someone needs monitoring across the boundary, a support route and authority to bring multiple suppliers together when the fault is unclear.
Test one replacement before believing the promise
If optionality is central to the investment case, test it. Choose one component and ask the proposed team to describe how it would be replaced. Which data and interfaces would move? Which other components would be affected? Who owns the configuration and documentation? How would the organisation run the old and new components during transition?
A credible answer exposes the seams and estimates the work. A vague answer about open standards suggests that the promised flexibility has not yet been designed. You can also test a small integration or technical spike before committing to the complete architecture.
Is it right for you?
It is not always right. If your requirements are simple and stable, a well-chosen suite may serve you better than a set of components you have to own and maintain. Composable architecture buys optionality, and optionality has a price. The question is whether you'll use it.
Look back over the last three years. How many valuable changes were blocked, delayed or dropped because "the system won't let us"? If the answer is none, a simpler platform may remain the sensible choice. If the examples keep accumulating, the current foundation is imposing a measurable change cost. Put those delayed changes, integration costs and dependencies into the business case.
Before approving a composable approach, ask five questions:
- Which components need to change independently, and what evidence shows that need?
- Who owns the architecture, integrations and end-to-end service?
- What will the complete estate cost to build, operate, secure and change?
- How will a failed component be isolated, monitored and recovered?
- Which small test would prove that a component can really be added or replaced?
Put the delayed changes and full operating responsibility beside the composable proposal. If it removes a costly constraint under an ownership model the organisation can sustain, the case is credible. If it mainly creates more components, keep the simpler architecture.
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.
