K
KnowMBAAdvisory
Digital TransformationAdvanced8 min read

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.

Also known asComposable BusinessMACH ArchitectureHeadless CommerceModular ArchitecturePackaged Business Capabilities

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

Composability ROI = (Speed-to-Market Improvement ร— Revenue per Launch) โˆ’ (Integration Cost + Multi-Vendor Overhead โˆ’ Avoided Re-Platform Cost)

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 platforms

Composable 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

success

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.'

Source โ†—
๐Ÿ“ฆ

Hypothetical: $300M B2B distributor MACH attempt

2021-2023 (anonymized engagement)

failure

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.