The pitch for composable ERP is now easy to make and hard to argue with. Buy a strong ledger, add a specialist tax engine, a planning tool that actually does planning, an expense product people will use, a procurement platform the suppliers can log into, and connect them. Every one of those products has a documented interface, a subscription price and a demo that beats the equivalent module in the suite. The analysts have been calling it postmodern ERP for a few years; the vendors selling the pieces prefer composable. The pitch is right about features and quiet about the thing that actually determines whether it works, which is who owns the seams.
What the suite was really selling
A monolithic ERP sold three things, and only one of them was functionality. The first was a shared data model. One definition of a customer, a product, a cost centre and a period, enforced by the database rather than by agreement. The second was pre-integrated process: an order that becomes a delivery that becomes an invoice that becomes a ledger entry without anybody writing code. The third was single accountability. When the month does not close, there is one vendor to call and no argument about whose problem it is. Composition unbundles all three. It is straightforwardly better on features, because a specialist with a thousand customers in one domain will out-build a suite module every time. It is worse on the other two, and the gap has to be filled by someone inside your organisation.
Why it is plausible now, when it was not in 2012
Three things changed. Interfaces stopped being a differentiator: a serious enterprise product without a documented REST API and a webhook model is now unsellable, which was not true five years ago. Integration platforms matured from middleware projects into subscription services that a small team can operate. And subscription licensing made capability-level purchasing possible, because you can now buy one function for two hundred users without negotiating an enterprise agreement. A fourth thing is more specific to this year. Organisations running the previous generation of SAP are working against a 2025 maintenance horizon, which means a re-platforming decision has to be taken in the next two or three years regardless of appetite. Once a programme is opening the core anyway, the question of whether to rebuild the monolith or decompose it becomes unavoidable rather than theoretical. The deadline is doing more to drive composable architecture conversations than any vendor's marketing.
The bill nobody itemises
The integration work is not the expensive part. The ownership is. Identity and access. Every added system has its own user model. Without a single identity provider and provisioning, joiners and leavers become a manual checklist and access reviews become impossible to evidence. Master and reference data. Which system owns the customer record, the item master, the chart of accounts, the tax codes, the exchange rates. In a suite the answer is implicit. In a composed estate it must be decided, documented and enforced, and it is the decision most often skipped. Transaction boundaries and reconciliation. Distributed systems fail partially. A payment recorded in one system and not the other is not an edge case; it is a weekly occurrence at volume. Someone has to own the reconciliation and the exception queue, and that person is usually discovered rather than appointed. Release calendars. Each vendor upgrades on its own schedule, and none of them coordinate with yours. A suite gives you one disruptive upgrade every few years. A composed estate gives you a continuous stream of small ones, any of which can break an interface. The audit trail across systems. An auditor following a transaction end to end now crosses four products and an integration layer. If the trail breaks at a seam, the control does not exist.
| Seam | Ownership decision |
|---|---|
| Identity and access | Who provisions users, removes leavers and evidences access review? |
| Master data | Which system owns each customer, item, account and reference record? |
| Transactions and reconciliation | Who monitors failed messages and resolves partial transactions? |
| Release calendars | Who tracks upgrades, interface versions and deprecation notices? |
| Audit trail | Who can demonstrate the end-to-end transaction across all components? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Where to compose and where not to
The useful test is not best-of-breed enthusiasm. It is two questions. Does this capability need to write to the ledger in real time, and does it need to share the core data model rather than exchange messages with it. Capabilities that fail both tests compose well: expenses, procurement, planning and forecasting, field service, e-commerce, treasury, tax determination, payroll. Capabilities that pass either one belong in or immediately beside the core: general ledger, sub-ledgers, inventory valuation, anything that must be consistent at a point in time for a statutory report. That is the whole architecture in two questions, and it survives most vendor conversations.
Practical Guidance for a Composable Architecture Assessment
- Write the system of record map first. One page, one owner per data object. If two systems can both create a customer, you have already decided to do reconciliation forever.
- Fund integration as a permanent function, not a project line. A composed estate needs someone whose job is the seams, in the budget every year, or the estate degrades quietly between programmes.
- Standardise identity before the second system arrives. Single sign-on and automated provisioning are cheap at two systems and painful at eight.
- Ask every vendor for their upgrade and deprecation policy in writing. Notice periods for interface changes, versioning, and how long old versions are supported. This is a more useful procurement question than the feature matrix.
- Design the exception queue with the integration. Where failed messages go, who looks at them, how quickly, and what the escalation is. Most composed estates discover this after the first month-end.
- Keep the ledger boring. Specialist products around the edge, conventional and well-supported at the centre. The core is where novelty is punished.
- Price the integration platform at realistic volume. Connector counts, message volumes and environment charges behave badly as adoption grows, and the pilot price is not the price.
- Rehearse the exit. For each composed component, how long to replace it and what breaks meanwhile. Composability is only genuine flexibility if a piece can actually be swapped.
The Regional Angle
Groups here are already composed, whether or not anybody planned it. The regional hub model puts one consolidated instance in Dubai or Riyadh serving several countries, and the local requirements that instance cannot meet get met elsewhere. Payroll is the clearest case: salary transfer files in the prescribed bank format, social insurance contributions in Saudi Arabia, end-of-service provisions calculated on local rules, visa and residency status tied to employment records. Almost nobody runs all of that in the group ERP. The composition happened by necessity years ago and simply was not called an architecture. That makes the system of record question unusually urgent here rather than academic. Second year of value added tax, multiple entities across mainland and free zones, and a reporting obligation that requires the same transaction to be consistent in the ledger, the tax filing and the local statutory accounts. A composed estate where two systems can both create a customer or a tax code will produce filings that do not tie out, and the discovery point is an audit rather than a dashboard. Trading and distribution businesses have a second version of this problem. Customs and shipping data, tariff classifications, certificates of origin and port documentation typically live in a freight or customs platform rather than the ERP, and the item master in that platform drifts from the one in the ledger. It is a small integration and a large annual irritation. Procurement economics deserve a mention that the global discussion never makes. In-country value and local content scoring is now a real factor in winning work with government-linked customers in Saudi Arabia and the UAE, and it rewards spend that lands with entities present in the country. A composed estate distributes spend across a dozen foreign software vendors with no local presence, where a single integrator-delivered suite concentrates it with a supplier who scores well. That is not a reason to choose an architecture, but it is a line in a bid evaluation that architects do not see and commercial teams discover late. Finally, the scarce resource is different here. Implementation consultants are abundant and integration engineers are not. A composed estate requires people who can operate an integration platform, read a vendor's API changelog and own an exception queue, and those people are hard to hire, expensive to retain and frequently the reason a well-designed composed estate becomes a badly maintained one within two years.
The objection worth taking seriously
The objection is that this is a pendulum and we are simply at one end of it. Best of breed in the nineties produced interface spaghetti, which sold the suite in the two thousands, which produced rigidity and upgrade debt, which is now selling composition. Give it five years and the same people will be presenting consolidation as the strategic direction, at higher total cost, having paid for both transitions. The harder version of the objection is about consolidation happening to you rather than by you. The specialist products being composed today are acquisition targets. SAP closed its eight-billion-dollar purchase of Qualtrics this month, Salesforce bought MuleSoft last year for a figure north of six billion, and the integration layer itself is being bought by the suite vendors whose rigidity it was sold to escape. Compose an estate from six independent specialists and within three years two of them will belong to your competitor's platform, with the pricing and roadmap that follow. Both points are true and neither argues for the monolith, because the realistic alternative is not a clean suite. It is the composed estate you already have, assembled by exception over a decade, with no system of record map, no named owner for the seams and no exit plan for any component. The choice is not between composing and not composing. It is between composing deliberately, with the two-question test and a written ownership map, and continuing to compose accidentally and calling it an ERP.
Common Questions
How many systems is too many?
The count matters less than the number of unowned seams. Four systems with a clear system of record map and one integration owner is more stable than two systems where both can create a customer. If nobody can name the owner of an interface, that interface is already a liability.
Does composition cost more or less than a suite?
Less in licensing and implementation, more in permanent operating cost, and the crossover depends entirely on how much integration you own. Organisations that budget for the integration function and the exception handling generally come out ahead. Organisations that count only the subscriptions do not.
What should stay in the core?
Anything that must be consistent at a point in time for a statutory or financial report, and anything that needs the shared data model rather than a message. In practice that is the ledger, the sub-ledgers and inventory valuation. Almost everything else is a candidate for composition.
What should we expect over the next twelve months?
Expect the 2025 maintenance horizon to dominate roadmap discussions and to force the decompose-or-rebuild question at organisations that would rather defer it. Expect more acquisitions in the integration layer, because the suite vendors have decided that owning the connective tissue is how they stay central. Expect integration platform pricing to become a negotiation point as customers hit real volumes. And expect the first serious audit findings at composed estates that never wrote down who owns which record.
Composable Architecture Assessment — we map what your estate has already composed by accident, decide what belongs in the core, and name an owner for every seam before month-end finds them for you.