Composable Architecture
Composable Architecture is the practice of building business capabilities as independent, interoperable, swappable modules โ connected via APIs, deployable independently, and combinable into different business processes without rewriting the underlying code. The MACH variant (Microservices, API-first, Cloud-native, Headless) is the most cited framework. The strategic case: in a composable architecture, replacing your e-commerce platform doesn't require replacing your CMS, search, payments, or loyalty system. You can swap one component without disrupting the others โ speed and optionality become the moat. The cost: composability requires more architectural discipline, more integration management, and a stronger platform engineering function than monolithic alternatives.
The Trap
The trap is composability for composability's sake โ assembling 30 best-of-breed point solutions into a Frankenstein architecture that nobody understands and that takes 5x longer to make any change to. Composability isn't 'more vendors' โ it's 'right-sized modules with stable contracts.' The other trap: assuming composable means cheap. The TCO of a composable architecture (multiple vendor contracts, integration management, observability across components) is often HIGHER than a monolithic suite โ the value comes from speed and optionality, not cost savings. Treating composability as a cost play ends in disappointment.
What to Do
Apply the 'Pace Layering' framework before composing: classify each capability as Systems of Record (slow-changing, stability matters โ ERP, ledger), Systems of Differentiation (medium-change, where you compete โ pricing, product config), or Systems of Innovation (fast-change, experimentation โ campaigns, mobile experiences). Use monolithic vendor suites for Systems of Record (don't compose your general ledger). Use composable best-of-breed for Systems of Differentiation. Use lightweight, replaceable tools for Systems of Innovation. Composing the wrong layer is the #1 cause of composable architecture failure.
Formula
In Practice
When Lego rebuilt its e-commerce platform around 2017-2020, they moved from a monolithic SAP Hybris stack to a composable MACH architecture: commercetools for the commerce engine, Contentful for content, Algolia for search, custom-built loyalty and product configurator. The result: they shipped new digital experiences in weeks instead of months, supported aggressive geographic expansion, and could swap individual components without re-platforming. Critically, they DIDN'T compose the back-office ERP โ that stayed monolithic with SAP. The selective application of composability is what made it work.
Pro Tips
- 01
Adopt a 'Reference Architecture' before any vendor selection. Define how components must integrate (event-driven? sync API? shared identity?), what observability standards apply, and how data flows. Without this, every team picks their favorite vendor and you build 47 unique integration patterns.
- 02
Budget 20-30% of your build cost for integration and orchestration โ explicitly. Composability moves cost from 'vendor licenses' to 'integration glue.' If your business case shows zero integration cost, it's wrong and you'll discover this in production.
- 03
Composability shines for B2C and customer-facing experiences (frequent change, A/B testing, personalization). It struggles for back-office Systems of Record (regulatory complexity, data integrity, infrequent change). Don't compose your accounting; do compose your storefront.
Myth vs Reality
Myth
โComposable architecture eliminates vendor lock-inโ
Reality
Composable shifts lock-in from one big vendor to 8-15 medium vendors plus the integration platform that wires them together. The integration layer (often custom-built or via an iPaaS) becomes the new lock-in. Total switching cost can be HIGHER than a monolithic suite because every component swap requires re-integration work.
Myth
โBest-of-breed always beats monolithic suitesโ
Reality
Best-of-breed wins on individual component capability and lock-in reduction. Monolithic suites win on integration cost, single throat-to-choke for support, and unified data models. The right answer is workload-specific. Companies that go composable across the board and companies that go suite-only across the board both make the same category error: failing to match approach to capability type.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge โ answer the challenge or try the live scenario.
Knowledge Check
A retail CTO is rebuilding the digital stack and proposes a fully composable MACH architecture for everything: commerce, content, ERP, finance, HR, fulfillment. What's the most likely outcome 24 months in?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets โ not absolutes.
Time-to-Market for New Digital Capability
Mid-market and enterprise digital commerce platformsComposable Mature
2-6 weeks
Composable Early / Suite Optimized
6-12 weeks
Standard Suite Implementation
12-20 weeks
Heavy Customization
20-36 weeks
Legacy Monolith
> 36 weeks
Source: https://machalliance.org/composable-architecture
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Lego
2017-2020
Lego replaced its monolithic SAP Hybris commerce platform with a composable MACH stack: commercetools (commerce engine), Contentful (CMS), Algolia (search), and custom services for the loyalty program and product configurator. The deliberate choice: NOT to compose the back-office ERP and supply chain (which stayed monolithic with SAP). Result: faster geographic expansion, A/B testing cycles cut from months to weeks, and the ability to swap individual front-end components without re-platforming. The selective application โ composable for the customer-facing layers, monolithic for the systems of record โ is what made the project succeed where many full-MACH attempts failed.
Replaced Platform
SAP Hybris monolith
Composable Components Used
4 best-of-breed + custom services
Time-to-Market Improvement
Months โ Weeks
Components NOT Composed
ERP and supply chain (kept SAP)
Composable architecture works when it's selective. Lego composed the layers where speed mattered (storefront, content, search) and kept the layers where stability mattered (ERP, supply chain) on the monolith. The hybrid pace-layering approach is harder to design but dramatically more successful than 'compose everything.'
Hypothetical: $300M B2B distributor MACH attempt
2021-2023 (anonymized engagement)
A B2B industrial distributor attempted a full-MACH composable rebuild covering commerce, ERP, CRM, fulfillment, and finance. 14 vendors, $11M planned budget, 24 months to launch. By month 18, they had spent $14M with 9 of 14 components in various states of integration. The Order Management vendor went out of business. Two of the AI/personalization vendors couldn't deliver on B2B-specific use cases (their training was B2C). By month 24, leadership reset the project: kept 5 composable components for the digital storefront and B2B portal, returned the ERP and finance to a SAP S/4HANA suite, retired 4 vendor contracts. Final stable architecture launched at month 36, $19M total cost.
Original Vendor Count
14
Original Budget / Timeline
$11M / 24 months
Final Cost / Timeline
$19M / 36 months
Final Architecture
Hybrid: 5 composable + SAP suite
Full-MACH for everything is a strategic error in most enterprise contexts. Composing too many components creates integration debt that overwhelms the agility benefits. The right architecture is almost always a hybrid where Systems of Record stay monolithic and Systems of Differentiation/Innovation are composable.
Related concepts
Keep connecting.
The concepts that orbit this one โ each one sharpens the others.
Beyond the concept
Turn Composable Architecture into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h ยท No retainer required
Turn Composable Architecture into a live operating decision.
Use Composable Architecture as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.