Composable ERP is not about breaking the monolith apart; it is about placing seams where the business genuinely needs faster change. Decouple a domain only when its iteration speed, best-of-breed fit, regulatory autonomy, or cost profile clearly outruns the ERP core, and only where integration density is low and data contracts are stable. Each seam adds integration debt, so govern it with typed APIs, named module owners, and monitored SLAs. Done with discipline, composable ERP keeps a reliable core while letting edge capabilities move at their own pace.
The monolith is a choice, not a law
For two decades the safe answer to "where should this capability live" was "inside the ERP." A single vendor stack meant one data model, one upgrade path, and one throat to choke. That safety came at a price most teams only noticed later: every improvement to warehousing, pricing, or field service had to wait for the core release cycle, and every customization made the next upgrade heavier. Composable ERP inverts the default. It treats the ERP as a stable financial and transactional spine, then lets selected domains run as decoupled modules that evolve on their own clock.
The trap is treating composability as a fashion rather than a trade. Decoupling a domain buys you iteration speed and best-of-breed capability, and it charges you integration debt for the life of the seam. A team that carves out a warehouse management system to ship features every two weeks has also signed up to own the interface contract, the master-data synchronization, the identity model, and the monitoring that used to be free inside the monolith. The discipline is knowing which domains earn that ongoing cost and which are quietly better off staying vanilla inside the core.
The stakes are asymmetric, which is why the decision deserves a scorecard rather than a preference. A good carve-out compounds in your favor: the decoupled domain ships value the core could never have delivered, and the seam stays cheap because the contract is narrow and rarely changes. A bad carve-out compounds against you, adding nightly reconciliations, drifting master data, and a support queue nobody owns, all to serve a domain that never needed to move fast in the first place. Composable is not a target state you migrate toward wholesale; it is a series of individual, reversible bets, each of which should clear a bar before you spend engineering on it.
A composability scorecard for each candidate domain
Do not decouple by intuition. Score each candidate domain on the forces that justify a seam and the properties that make a seam cheap to run. A domain worth decoupling shows at least one strong trigger and a clean seam profile. If the triggers are weak or the seam is messy, keep it in the core and default to fit-to-standard.
| Domain | Strongest trigger | Integration density | Data-contract stability | Verdict |
|---|---|---|---|---|
| Warehouse management (WMS) | Innovation speed: 2-week release cadence vs annual core | Low: item master in, stock movements out | High: stable item and location contracts | Decouple |
| Configure-price-quote (CPQ) | Best-of-breed fit: guided selling the core lacks | Medium: pricing and order handoff | Medium: pricing conditions change often | Decouple with strong contract governance |
| Statutory tax and e-invoicing | Regulatory autonomy: per-country mandates | Medium: touches AR, AP, GL | Medium: rules shift by jurisdiction | Decouple per region only |
| General ledger and close | None: stability is the value | High: every module posts here | High but deeply coupled | Keep in core |
| Procurement approvals | Cost containment (weak) | High: PO, GR, invoice match | High | Keep in core, configure |
| Field service scheduling | Best-of-breed fit: mobile-first optimization | Low: work orders in, completion out | High: stable work-order contract | Decouple |
Read the table as a filter, not a menu. Two forces drive the "decouple" verdict: a real trigger that the core cannot serve, and a seam clean enough that the interface is a handful of stable contracts rather than a web of nightly reconciliations. The general ledger and procurement approvals fail the second test even where a trigger exists, because everything posts through them; their stability is the point. Consider a distributor that ran the scorecard across six domains. It scored its WMS at the top: a 2-week desired release cadence against an annual core, a seam of just two contracts (item master in, stock movements out), and a distinct warehouse-operations user base. It carved out the WMS, shipped slotting and wave-picking improvements every sprint, and kept the seam cheap because the contract never widened. The same firm scored its general ledger as a clear keep, because the trigger was absent and the density was total, and it kept CPQ inside a decoupled module but demanded strict contract governance to absorb the frequent pricing changes. That single scorecard saved it from the most common composable-ERP mistake: cutting a seam through the one domain that should never move.
How to decouple without regret
- Run the scorecard on every candidate domain and require a written verdict; a seam with no strong trigger stays in the core at fit-to-standard.
- Model total cost over 3 to 5 years, not the first release: include interface build, master-data sync, and the run-state monitoring the seam now demands.
- Freeze the data contract before you build; version it, publish it, and treat a breaking change as a release event with backward compatibility for at least one cycle.
- Name a product owner for each decoupled module and a single owner for integration, then write the RACI so nobody assumes the interface owns itself.
- Instrument every seam from day one: data latency, error rate, and reconciliation variance become SLAs, and a breached SLA pages someone.
Where composable ERP goes wrong
- Decoupling for fashion, not need. Fix: require a documented trigger and a clean seam profile before any carve-out is approved.
- Cutting a seam through a high-density domain like the GL. Fix: keep coupled cores in the ERP and decouple only low-density edges with stable contracts.
- Master data drifting between systems within weeks. Fix: name one golden source per entity and run scheduled synchronization with drift detection on key reference tables.
- Security gaps opening between the core and the module. Fix: apply one identity and access model across both, with consistent audit logging and least-privilege grants.
- Operational sprawl as each module brings its own dashboards and support queue. Fix: consolidate monitoring and support into one pane and one escalation ladder before go-live.
Before you approve a carve-out
- The domain scores a strong trigger and a low integration-density, high-contract-stability seam profile.
- A 3 to 5 year total-cost model exists and includes the run-state, not just the build.
- The data contract is versioned, published, and owned before any code is written.
- A module product owner and an integration owner are named, with a RACI signed.
- Seam SLAs for latency, error rate, and reconciliation variance are defined and wired to alerting.