Since 2020, Gartner has been pushing the “Composable ERP” model, the logical evolution of its Postmodern ERP concept introduced in 2013. Since 2022, every vendor has adopted the vocabulary: API-first, best-of-breed, clean core, decoupling. Since 2024, some CTOs have hit the wall and quietly rolled back, often without saying so. 2026 is the year for an honest assessment.
Is Composable ERP the end of monoliths or an oversold promise by analysts and iPaaS vendors? The answer is nuanced. For a large multi-business unit industrial enterprise, yes, it’s probably the reasonable 5-year target. For a 200-person company with a single activity, it’s often a governance trap that costs more than it delivers. This article distinguishes what works, what breaks, and under what conditions.
What is Composable ERP
An Old Idea Accelerating
The concept isn’t new. In 2012, Gartner published its Pace-Layered Application Strategy, which proposed classifying applications into three layers according to their rate of change (Gartner Glossary):
- Systems of Record (long cycle): finance, payroll, general ledger, master data. Stable, regulated, non-differentiating.
- Systems of Differentiation (medium cycle, 1-3 years): processes that distinguish the company in its market. Specific sales management, supply chain, planning.
- Systems of Innovation (short cycle, 0-12 months): experimentation, last-minute business applications, POCs.
In 2013, Gartner formalized “Postmodern ERP”: the monolithic ERP breaks into a financial core plus best-of-breed satellite applications. In 2020, the term becomes “Composable ERP”, following Composable Business. In 2022, the trend enters Gartner’s Hype Cycle for ERP (Gartner Hype Cycle for ERP 2024).
The Four MACH Principles Applied to ERP
Composable borrows its fundamentals from MACH, the architecture popularized by headless e-commerce and formalized by the MACH Alliance (MACH Alliance):
- Microservices: each business function (billing, inventory, payroll) is an independent service, deployable and scalable separately.
- API-first: all interaction between components goes through documented API contracts, REST or GraphQL. No direct database access.
- Cloud-native: components are designed for the cloud from the ground up, not ported from an existing on-premise solution. Elastic scalability, CI/CD pipelines, continuous updates.
- Headless: the back-end is decoupled from the user interface. The same service powers a web portal, mobile app, chatbot, or AI agent.
Applied to ERP, these principles produce an architecture where the general ledger doesn’t need to know the purchasing module, where sales management can be replaced without touching accounting, where an AI agent can directly call the invoicing API.
The Difference from 2000s Best-of-Breed
Assembling multiple business software solutions isn’t new. In the 2000s, we already talked about “best-of-breed”: an ERP for finance, a dedicated CRM, a specific WMS, interconnected by EDI batches or nightly ETL. This isn’t the same as Composable ERP.
Three key differences:
- APIs are real-time, not 2 AM batch flows. An order placed in the CRM reaches the ERP in seconds, not the next day.
- Components are cloud-native, not on-premise software with adapters. This changes update frequency and resilience.
- Integration is industrialized via an iPaaS (MuleSoft, Boomi, Workato, Celigo), not ad-hoc connectors hand-coded that rot without maintenance.
A 2026 composable looks like event-driven architecture with a managed integration bus, not a flat file train station.
Typical Architecture Schema
At the center, an integration hub (iPaaS + API management). Around it, six to ten independent business components: a cloud finance core (NetSuite, Sage Intacct, Workday Financials), an HRIS (Workday, SAP SuccessFactors, BambooHR), a CRM (Salesforce, HubSpot, Dynamics Sales), a procurement platform (Coupa, Ivalua, SAP Ariba), a WMS or business TMS, and a CDP or PIM for product and customer master data. Each component has its own vendor, contract, roadmap, release cycle. The hub orchestrates flows, applies compliance rules, centralizes observability.
Why Monoliths Are Being Questioned
Asymmetric Innovation Pace
A monolithic on-premise ERP has historically had a long release cycle: 18-36 months for a major version. Specialized SaaS solutions deliver features every two to four weeks. This gap becomes unsustainable when business departments compare Odoo or Salesforce to their central ERP. On SAP’s side, the transition to S/4HANA Cloud Public Edition brings the rhythms closer (quarterly updates), but Private Cloud edition and the rest of the existing ECC legacy remain on slower cycles.
SAP ECC End-of-Support Pressure
Calendar pressure is real. SAP has confirmed that standard maintenance for SAP ECC 6.0 and SAP Business Suite 7 will end on December 31, 2027, with optional extended maintenance until December 31, 2030 (SAP Maintenance Strategy). Thousands of European mid-market companies must choose between S/4HANA migration (brownfield or greenfield) or complete IT landscape recomposition. The timing is right for rethinking architecture.
Inability to Modernize by Component
In a monolith, modernizing HR often involves touching finance, because both share the same employee master data, cost tables, automated postings. In composable architecture, you replace an aging HRIS without touching the general ledger. Modernization becomes incremental: HR in 2026, procurement in 2027, supply in 2028. This is the real business argument, not technical jargon.
Vendor Lock-in
A monolith concentrates dependencies. Changing vendors requires a multi-year project worth tens of millions for a large enterprise. Composable disperses risk: each component is individually replaceable over 12-18 months. Negotiation leverage during renewals is substantially different.
Business Department Demands
Business departments want the best tool for their domain. HR directors want Workday or SAP SuccessFactors, not the legacy HR module. Procurement departments want Coupa. Sales departments want Salesforce. The central ERP becomes a bottleneck, and departments bypass IT by directly subscribing to SaaS. Shadow IT ends up costing more than assumed composable architecture.
Three Models of Composable ERP in 2026
Not all composable architectures look alike. Three major models coexist, with different economics and risks.
Model 1: Minimal Finance Core Plus Business Satellites
Keep a compact ERP focused on finance: NetSuite, Sage Intacct, Workday Financials, Oracle Fusion Financials. Around it, satellite other domains: Workday or SAP SuccessFactors for HR, Coupa or Ivalua for procurement, Kinaxis or o9 for supply chain, Salesforce for CRM. An iPaaS orchestrates flows. An MDM or CDP holds master repositories.
This is the most mature model, dominant in B2B services, SaaS, tech and healthcare. US players (NetSuite, Workday, Coupa, Salesforce) are very structural, creating an ecosystem effect.
Model 2: Low-Code Platform as Core
Build your own ERP on a low-code platform: Mendix (Siemens), OutSystems or Microsoft Power Platform. Business applications are built on-demand, integrations are native, governance is centralized.
This model suits companies with very specific processes not covered by standards (rare businesses, complex logistics, highly regulated industries). It requires a solid IT team and strict governance: without this, you fall back into industrialized shadow IT. For more on these tools, see our low-code ERP guide: customizing Odoo, SAP and Dynamics without coding.
Model 3: Legacy ERP Opened Plus Selective Satellites
Keep SAP S/4HANA Cloud, Oracle Fusion Cloud ERP or Dynamics 365 as the core. Leverage their public APIs and extension platforms (SAP BTP, Oracle OIC, Microsoft Power Platform) to connect specialized components only where the ERP is weak. Finance, management control and supply remain on the ERP. HR, CRM or procurement can be satellited.
This is the pragmatic hybrid model, chosen by most large enterprises doing S/4HANA or Oracle Fusion today. It’s also what SAP pushes under the name “Clean Core”: keep the S/4HANA core close to standard and externalize differentiations to BTP. For a detailed analysis of both platforms, see our comparison SAP S/4HANA vs Oracle Cloud ERP 2026.
What Works in Composable
| Benefit | Observed Effect |
|---|---|
| Incremental modernization | Replacement of one component in 6-12 months without blocking other domains |
| Negotiation leverage | Fractional contracts, competition on each domain, no single lock-in |
| UX innovation | Modern interfaces per component, faster user adoption |
| Better business coverage | Each domain has the tool designed for it, not a generalist compromise |
| Talent attractiveness | Developers prefer coding on modern APIs than legacy ERP ABAP or AL |
The most tangible return isn’t the initial time-to-value (which is often equivalent to a good monolithic project) but modernization velocity over 5-7 years. A well-governed composable architecture allows replacing three components over this duration without multi-year projects. A monolith doesn’t.
The second underestimated effect is adoption. End users much better tolerate a good specialized UX than the generalist compromise of a central ERP module. Procurement teams prefer Coupa to the legacy purchasing module, even if IT is skeptical.
What Breaks in Composable
The iPaaS vendor discourse systematically omits the downsides. Here’s what can make a composable transition fail.
Integration Costs Explode
iPaaS isn’t free. MuleSoft prices from €30,000 per year for a 2 vCore Gold deployment, and a large enterprise case easily reaches €210,000 annually for multi-environment Platinum (MuleSoft Pricing 2026, Automation Atlas). Add initial implementation costs, which in some cases exceed platform cost in the first year. Boomi, Workato or Celigo are cheaper but remain structural expense items. The empirical rule widely observed among mid-market companies: integration cost represents 30-50% of the cumulative annual license cost of business components.
Master Data Repository Becomes a Puzzle
In a monolith, the customer exists in one place. In composable, the same customer is in Salesforce, NetSuite, Coupa (as supplier), Workday (if contractor), the CDP and sometimes in the DWH. Who is the source of truth? Who propagates updates? Who resolves conflicts? Without a serious MDM (Master Data Management) strategy, you get silent divergences that pollute reporting and audit.
IT Governance Becomes Ten Times More Demanding
Composable requires a dedicated enterprise architect, integration team (not external consultants), API management (Apigee, Kong, Axway) with strict versioning, and multi-vendor contractual governance. Without this, each component evolves independently, APIs break in cascade, and production incidents multiply.
Financial Closing Becomes a Project in Itself
Consolidating five or six systems into monthly financial reporting is technically feasible, but consumes time, software (BlackLine, Trintech, OneStream) and management control resources. CFOs who’ve lived through the transition all testify to closing hardening before it stabilizes, 12-18 months after switchover.
Cross-System Compliance Becomes Harder
Applying GDPR to a monolith is one project. Applying it to eight systems, with processing registers that must align, coherent access rights, and deletion workflows that cross APIs, becomes a permanent undertaking. Same logic for SOX, CSRD, NIS2, DORA or mandatory e-invoicing in several European countries.
Criteria to Know if Composable is for You
Not all contexts call for composable architecture. Four criteria to apply before deciding.
Company Size
In practice, composable becomes profitable around €500 million in revenue or 2,000-3,000 employees. Below that, governance complexity and integration costs exceed flexibility gains. Above, it’s almost unavoidable to remain competitive on business delivery pace.
IT Department Maturity
Non-negotiable prerequisites: dedicated enterprise architect, internal integration team (minimum 2-5 people), formalized API governance, managed iPaaS. If the current IT department is in “external contractor command” mode, composable transition will expose all governance weaknesses.
Time Horizon
A composable transition makes sense over 5-7 years. Not 2 years. If the sponsor (CEO, CFO, CIO) has a shorter mandate horizon, you should either postpone or stick to light composable (see below).
Business Profile
Composable pays off especially when the business is heterogeneous: multi-BU, multi-country, multi-business with specific needs per domain. On a mono-business activity geographically concentrated, a well-configured monolith often remains more efficient.
Pragmatic Comparison: Composable vs Cloud Monolith
| Criterion | Composable (e.g. NetSuite + Workday + Coupa + Salesforce) | Monolith S/4HANA Cloud or Oracle Fusion |
|---|---|---|
| Five-year TCO | 20-40% higher typically, heavily dependent on integration | More predictable, better-controlled envelope |
| Time-to-value per component | Fast (6-12 months per domain) | Slower (18-24 months for core) |
| Vendor lock-in | Distributed across 5-8 vendors | Concentrated on one main vendor |
| Required IT governance | Heavy (architect, integration, MDM, API management) | Lighter, one ERP competency center suffices |
| Innovation per domain | High | Depends on main vendor pace |
| Financial consolidation | Ongoing project with dedicated software | Native, integrated into general ledger |
| Operational resilience | Depends on integration quality | Mutualized by monolith |
The table above isn’t a recommendation. It’s a trade-off. Depending on whether you optimize total cost, flexibility, or velocity, the right answer changes.
Alternative: Light Composable
For mid-market companies between €50-500 million in revenue, the right target is often neither full composable nor pure monolith, but an intermediate version. A compact ERP plus one or two specialized satellites.
Three common archetypes in Europe:
- SAP Business One + Sage People + HubSpot for a growing industrial SME.
- NetSuite + Workday + Salesforce for a services company with strong commercial component.
- Odoo Enterprise + BambooHR + HubSpot for a multi-country distribution model.
This light composable captures 70% of full composable benefits (component-wise modernization for HR and CRM, specialized UX) without full best-of-breed governance complexity. A light iPaaS (Make, Zapier Enterprise, Workato small scale, or native Odoo or SAP B1 connectors) suffices for volumes. To understand how to properly wire CRM and ERP, see our guide CRM and ERP integration: architecture, flows, errors to avoid.
Conclusion and Resources
Composable ERP isn’t the end of monoliths. It’s an architecture option among others, relevant when size, IT maturity and time horizon align. For large multi-BU enterprises with mature IT departments, it’s the reasonable direction for 2030. For mid-market companies, light composable captures most benefits without governance costs. For SMEs, a good well-configured SaaS monolith often remains the best economic decision.
The debate isn’t ideological, it’s contextual. The classic mistake is adopting vocabulary without adopting prerequisites: without budgeted iPaaS, dedicated architect, MDM strategy, a poorly governed composable costs more and delivers less value than an honest monolith.
For more on structural architecture choices, also read our cloud vs on-premise comparison: advantages and disadvantages and our low-code guide for customizing ERP without coding.
You’re steering a structural ERP choice in 2026 and want neutral framing before launching an RFP? A 3-month POC on a single domain (finance, HR or procurement) lets you test the composable hypothesis on your real context, for a typical budget of €15-30k. Result: an argued Go/No-Go decision, not a slide of commercial promises.
