What is this about?
Composable architecture means building a system from capabilities that can be combined, replaced and evolved independently. That sounds simple, but it changes how we think about teams, integration, product ownership and long-term system evolution.
The term has become much more visible in the context of DXP, headless CMS, MACH and modern platform engineering, where it often arrives wrapped in marketing vocabulary. This article is my attempt to separate the useful architectural idea from that vocabulary, and to say where it stops being worth the cost.
To avoid a mix-up: this is about system and enterprise architecture, not The Composable Architecture, the Swift library from Point-Free.
The idea is not new. The earliest use of the related term I know of is Jonathan Murray’s 2013 post The Composable Enterprise, which treats business functions, organizations, suppliers and technology as building blocks that can be reconfigured. Gartner gave the term much wider reach in 2020 with its report Future of Applications: Delivering the Composable Enterprise, built around “packaged business capabilities”: software components that a business user would recognize as a business capability.
The terms around this topic are often used as if they were synonyms. They are not, and most of the confusion disappears once you sort them by the question each one answers.
Where DXP fits in
DXP, or Digital Experience Platform, describes the business-facing problem space: organizations want to deliver consistent digital experiences across websites, apps, portals, commerce and other touchpoints.
In that sense, DXP is less an architecture pattern and more the target. It describes what the business wants to achieve. Composable architecture describes one way to structure the underlying system so that this complexity remains manageable.
The term got its weight from Gartner, which retired its Magic Quadrant for Web Content Management in 2020 and kept the broader one for Digital Experience Platforms. Gartner describes a DXP as a cohesive set of integrated technologies for the composition, management, delivery and optimization of personalized digital experiences across channels.
Note what that definition leaves open. A DXP can be bought as one suite or assembled from parts, so the term says nothing about how the system is built. That is why I treat DXP as a description of the target system from the customer’s perspective, and look elsewhere for the architecture.
Composable architecture as a strategy
I call composable architecture a strategy, and I use that word consciously. It covers more than the technical shape of the system: team structure, product ownership, UX, the platform team’s work, sometimes even sales and marketing. Talking about a strategy also makes it easier to find a common language with non-technical roles than talking about services and APIs.
Still, it needs an engineering definition, or it stays a slogan. So let’s define composability.
Composability
According to Wikipedia, composability is a system design principle that deals with the inter-relationships of components. A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements.
In this context I would expect the following properties:
- Modularity: The system is divided into distinct parts, each responsible for one capability, with clear boundaries. I wrote earlier about how modularity enables agility.
- Interoperability: Components work together through well-defined, stable contracts, usually APIs or events.
- Replaceability: A component can be swapped for another implementation without rewriting its neighbours. This is what separates composable from merely modular, and it is the easiest property to lose.
- Reusability: A capability can serve more than one product or channel.
- Independent evolution: Teams can change, release and scale a component on their own schedule.
Scalability and flexibility often appear in such lists too, but I see them as possible results rather than defining properties. A system can scale very well and still be impossible to recompose.
If we manage to build such a system, the payoff is agility, because the organization can respond faster to changes in the market or in technology, and efficiency, because teams can focus on specific components and reuse existing ones.
Microservices and headless CMS are popular ways to get there, but neither guarantees it. A set of microservices that share a database and release together is not composable. A single headless product can still be a monolith behind an API. And a well-structured modular monolith can be composable at build time.
To see where the vocabulary helps and where it misleads, let’s take the building blocks one at a time, starting with the most familiar one.
Headless CMS: one boundary, cut cleanly
A traditional CMS owns both the content and the page that displays it. Editing, templates and rendering live in one system and ship together. A headless CMS cuts that system in two: it manages structured content and exposes it through an API, and it renders nothing. The “head”, the presentation layer, becomes a separate product with its own release cycle.
That single cut has consequences worth spelling out:
- Content becomes structured data. A page with a rich-text blob turns into typed fields: an article, an author, a product description. This is what makes reuse across channels possible, and it is where most of the design work sits.
- The content model becomes a public contract. Content is delivered over REST or GraphQL, which vendors like to call Content as a Service. From then on, renaming a field can break a consumer you have never heard of.
- Any front end can consume it. React, Vue, Angular, a mobile app, or a static site generator such as Hugo in a Jamstack setup.
- Capabilities that used to be included now need an owner. Page layout, preview, personalization and often search came with the old suite. With headless, someone has to build or buy them, and editors usually notice the missing preview first.
Headless is the cleanest small example of the whole argument. You get one real replaceable boundary, and you can see what it takes to keep it replaceable: content only moves freely as long as the model is not tied to one vendor’s features. Even plain Markdown shows this. When I moved this blog from Hugo to Astro, the text was portable, but frontmatter fields and Hugo-specific shortcodes still had to be transformed.
It is also why headless and composable are not synonyms. Headless decouples one boundary, the one between content and presentation. Composability asks for that kind of independence at every boundary that matters.
Cloud native
Headless is about one boundary. Cloud native is about what it takes to operate many of them. It describes how software is designed and run, one level below the product choices. The CNCF definition says such systems “typically consist of some combination of” containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless and declarative APIs, and calls that list non-exhaustive. So microservices are common here, but not mandatory.
In practice, cloud native usually comes with:
- Containers: Consistent runtime environments.
- DevOps and CI/CD: Automated testing and frequent, reliable releases, often through GitOps.
- Dynamic orchestration: Tools like Kubernetes manage deployment and scaling.
- Resilience and horizontal scaling: Fault tolerance is designed in.
- Infrastructure as Code: Provisioning is automated and reviewable.
- Managed service communication: APIs, sometimes with a service mesh.
- Observability: Monitoring, logs and traces show what is going on.
Why does this matter for composability? Because it keeps many independent components affordable to run. Without automated delivery, provisioning and observability, every extra component is mostly extra work.
MACH: the building blocks as a package
Put those pieces together and you are close to MACH, a more specific and opinionated interpretation of composable architecture. The acronym stands for:
- Microservices: Pieces of business functionality that are developed, deployed and managed independently.
- API-first: All functionality is exposed through an API.
- Cloud-native SaaS: Software delivered as a service that uses the cloud beyond storage and hosting, including elastic scaling and automatic updates.
- Headless: The front end is decoupled from the back end.
Keep in mind who is behind it. The MACH Alliance was formed in June 2020 by commercetools, Contentstack, EPAM and Valtech, so the definition also serves a market. Note the difference from the previous section: the “C” is usually read as cloud-native SaaS, a narrower idea than cloud native in general, and one that leans towards buying products rather than building them.
Where composable architecture describes the general strategy, MACH describes a concrete set of technology principles often used in digital commerce and DXP environments.
So MACH is a recipe. I would not say that every composable system must follow it, but many MACH systems are attempts to make composability practical at enterprise scale. And a recipe is only useful if you know what it costs.
What composability costs
This is the part the marketing tends to skip. Every boundary that lets you replace a component is also a contract you have to maintain.
- Integration work moves to you. A suite vendor integrates its own modules. In a composed system that is your job, including upgrades, data synchronization and failure handling across products.
- Ownership gets fuzzy. When a customer journey crosses five components, someone has to own the journey and not only the components.
- Replaceability is often theoretical. Data models, vendor-specific features and contracts create lock-in even behind a clean API. I only count a component as replaceable if we know what a swap would take.
- Composition needs orchestration. Something has to combine the parts into one experience. Tim Benniks, who works in this space at Contentstack, notes that a standalone orchestration layer “adds a vendor, a contract, a team, and another critical path.”
The debate is still open. A 2025 CMSWire roundup sets a commerce vendor’s critique that MACH has become dogmatic and expensive against the MACH Alliance’s defence, and frames it this way: “composability isn’t binary—it’s a spectrum”. I agree with that. The labels keep moving too: vendors now sell the “composable DXP”, and “agentic” is the newest addition.
When I would use it
It is worth the cost when different parts of the business change at different speeds, when several channels need the same capabilities, and when you can afford teams that own the boundaries.
I would hold back for a single website with predictable content and one small team. A suite or a well-structured monolith will serve that better, and it can still be modular inside.
Decisions like this deserve a written record. Architecture Decision Records are a good way to keep the reasons behind each boundary, so that replacing a component later is a decision and not archaeology.
My short version: composable architecture is most useful as a question. Can we replace this part without rewriting its neighbours, and do we know what that would cost? The rest of the vocabulary is different ways of answering it.