Composable architecture

Composable architecture is an approach to building a digital system out of independent parts, each chosen because it is well suited to its job, connected together over APIs. It stands in contrast to adopting a single suite that provides everything in one product. The word “composable” points to the idea that the system is composed from pieces you select and can recompose later, rather than delivered whole. It is an approach, not a product you buy, which is worth holding onto because nearly every vendor now applies the label to what it sells.

Best-of-breed parts over one suite

The central idea is best-of-breed: instead of accepting whatever a suite includes for search, or commerce, or content, you pick a strong tool for each and wire them together. If one becomes a poor fit, you replace that part without rebuilding the rest. The parts talk over APIs, which is what lets them be swapped independently.

This gives an organisation flexibility and a degree of ownership over its own stack. It can adopt the best available option for each need, add capabilities over time, and avoid being tied to one supplier’s whole bundle.

What it asks in return

The responsibility that a suite would carry moves to you. Assembling independent parts means owning the integration between them, and running several services means more moving pieces to operate, monitor, and keep in step as each evolves. A suite hands you those connections already made; a composable stack asks you to make and maintain them.

Because of that cost, the industry has grown more measured about the approach, and some vendors now publish honest pieces titled along the lines of “you may not need composable.” The point of those is not that the approach is wrong but that its flexibility is only worth its integration overhead when a team genuinely needs it. A straightforward website rarely does; an organisation with varied, changing needs across many channels often does.

How it relates

Composable architecture shares its spirit with MACH, which names a specific set of principles for building this way, and both usually assume a headless CMS for the content part. The suite model it is contrasted with is the DXP.