For most of its history, ERP was designed to be the place data went, not a place data came from. Integration existed, but it was built on the vendor's terms: proprietary interface formats, batch file drops, middleware that required a specialist, and a certification programme for partners who wanted to connect. The assumption underneath all of it was that the ERP was the centre and everything else negotiated access to it. By the middle of the 2010s that assumption was failing. The applications around the ERP — e-commerce storefronts, field service apps, payment providers, logistics platforms, CRM, expense tools, marketplaces — had all standardised on REST and JSON, published documentation openly, and expected to be integrated in an afternoon rather than in a quarter. The ERP was the slowest, most expensive, most restricted endpoint in the estate, and increasingly it was the one holding up delivery. The API economy reached ERP as a demand rather than as a product decision, and the vendors' responses to that demand shaped the next decade of integration architecture.
What the gap actually looked like
The technical mismatch was concrete. Established ERP integration ran through document formats and remote function calls designed in the 1990s, with strongly typed interfaces, batch orientation and a tooling chain that required specialist knowledge. A competent web developer could not integrate with an ERP without help. A competent ERP consultant could not build an integration that a modern application team would consider usable. The cultural mismatch was larger. Web platforms published APIs as products: documented, versioned, self-service, with sandbox environments and sample code. ERP interfaces were project deliverables — documented in a functional specification, built for one purpose, owned by whoever last touched them, and undiscoverable by anyone else. Organisations regularly built a second integration for the same data because nobody knew the first existed. And the operational mismatch caused the most pain. Modern applications expect near-real-time responses. Classical ERP integration was batch and eventually consistent — which is perfectly fine for a nightly general ledger posting and unacceptable for a customer checking stock availability on a website.
How the vendors responded, and what it cost buyers
Every major vendor added REST API layers, developer portals and, eventually, integration platforms of their own. Cloud ERP entrants had shipped APIs from the beginning and used that as a competitive argument. Independent integration platforms — the category that became iPaaS — grew rapidly by sitting between the ERP and everything else, and the largest of them were acquired at significant valuations, which tells you how much value the market placed on solving this specific problem. But the commercially significant development was not technical. It was licensing. Once data flowed out of the ERP through open interfaces, vendors had to decide how to charge for users who never logged in. The resulting disputes over indirect or digital access — where a customer with a licensed user count found itself facing claims for systems and end users touching ERP data through an interface — became one of the defining commercial arguments of the period. A well-publicised case involving a beverage company and its ERP vendor brought the issue into open court and forced the vendor to publish a revised licensing model based on documents processed rather than on indirect users. That episode is the single most important thing for an integration strategy to account for, and it is routinely ignored by the architects designing the integration. A technically elegant design that exposes ERP data to fifty thousand customers through a portal may carry a licensing consequence larger than the project budget. The commercial model and the integration architecture are the same decision.
The architectural question that survived
Stripped of the era's vocabulary, the question the API economy forced on ERP owners is still live: where does integration logic live? The answer that failed was point-to-point. Each new application integrated directly to the ERP, with its own credentials, its own field mapping and its own error handling. It works for the first five integrations and becomes unmanageable at thirty, because every ERP upgrade requires regression testing against every connection and nobody has a complete list of them. The answer that worked was a deliberate integration layer — an API gateway, integration platform or service tier that owns the contract with consuming applications and insulates them from what the ERP actually does. Consumers call a stable, documented interface. The layer handles authentication, rate limiting, transformation, retry, monitoring and version management. When the ERP is upgraded, migrated or partially replaced, the consumers do not change. That pattern is what made later modernisation feasible. Organisations that built it in the API-economy era were able to move to cloud ERP, split functionality out, or change vendors without renegotiating every downstream connection. Organisations that built point-to-point integrations are still paying for that decision, because the integration estate is now the thing preventing them from moving.
| Responsibility | What to define |
|---|---|
| Interface contract | Owner, documentation, version and consuming applications. |
| Master data | Which system owns each data definition. |
| Access | Credentials, permitted operations and audit records. |
| Operations | Monitoring, retries, errors and the fallback. |
| Commercial terms | API limits and the written licensing position for the proposed flows. |
| Change | The inventory and regression checks needed for upgrades. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for ERP Integration Strategy
- Build an integration layer between the ERP and everything else, and route all new consumers through it. This is the decision that determines whether you can change the ERP later.
- Treat APIs as products with owners, documentation and versions. A catalogue of available interfaces prevents the most common waste in this area, which is building the same integration twice.
- Model the licensing impact before the architecture is approved. Indirect and digital access terms can make an integration design commercially unviable, and the time to discover that is in design, not in an audit.
- Define which data the ERP owns and which it merely holds. Master data ownership disputes cause more integration failures than protocols do, and they cannot be resolved by the integration team.
- Distinguish genuine real-time needs from convenience. Real-time integration is materially more expensive to build and operate; much of what is requested as real-time is satisfied by a five-minute cycle.
- Instrument every interface with monitoring and alerting from day one. The characteristic integration failure is silent — a job stops running and nobody notices until month-end reconciliation.
- Maintain a complete inventory of integrations with owners and consumers. Upgrade planning is impossible without it, and most organisations discover interfaces during the upgrade that they did not know existed.
- Negotiate API access terms, rate limits and licensing at contract time. Once you are live, the vendor's interpretation of what constitutes a licensed use becomes considerably firmer.
The Regional Dimension
In the Gulf, the API question is shaped less by e-commerce than by government systems, and that changes the priority order. The most consequential integrations for a regional business are frequently statutory. E-invoicing in Saudi Arabia requires transactional integration with a clearance and reporting regime, with defined formats and timing. Wage protection in the UAE requires payroll files submitted through banking channels in prescribed structures. Customs, labour, immigration and social insurance systems each have their own submission mechanisms, and several of them were designed for portal entry by a human rather than for machine integration. The result is a category of integration that is mandatory, externally versioned, and changed on the regulator's timetable rather than yours. That has a specific architectural implication: statutory interfaces should sit behind the integration layer like any other, with monitoring and a rehearsed manual fallback, because a regulator-side change that breaks a direct point-to-point connection stops your ability to file. Multi-entity structures multiply the surface. A group with mainland companies, free-zone entities and a Saudi subsidiary frequently runs more than one ERP instance, and the integrations that matter most — consolidation, intercompany, group reporting — are internal rather than external. An integration layer that exposes a consistent interface across instances is worth considerably more here than in a single-instance environment. Delivery model is the third factor and the most commonly mishandled. Where a systems integrator built the estate, the integrations are typically the integrator's intellectual property under the terms of the statement of work, sitting in their middleware, documented in their format. Clients discover at renewal that changing integrator means rebuilding the integration layer. Ownership of interface designs, mappings and documentation belongs in the contract, and it rarely is. Finally, data quality. Bilingual master data — Arabic and English names, inconsistent transliteration, duplicate customer and supplier records — breaks automated matching between systems far more often than protocol issues do. An integration programme in this region that does not include a master data workstream will spend its second year building exception handling for problems it should have prevented.
The objection worth taking seriously
The serious criticism is that the API economy, applied to ERP, mostly produced a new integration layer to maintain rather than genuinely simpler architecture. The point-to-point estate was replaced by an integration platform, which required its own licences, its own specialists, its own upgrade cycle and its own operational monitoring. Organisations that were told integration would become self-service found that building a reliable interface still took weeks, still required someone who understood the ERP data model, and now also required someone who understood the integration platform. The specialist did not disappear; the specialism changed. There is a stronger version. Making ERP data easily accessible produced a proliferation of consumers, each creating a dependency on the ERP's data structures and each raising the cost of ever changing them. The openness that was supposed to enable modernisation arguably entrenched the core further, because now forty systems break when you change a field. The defensible answer is that the alternative was worse and the discipline is what distinguishes outcomes. A governed integration layer with versioned contracts and owned interfaces does insulate consumers from core changes — that is precisely its purpose. An ungoverned one, where consumers call whatever endpoints they discover and no contract exists, delivers all the coupling with none of the protection. Most of the disappointment in this area comes from organisations that bought the platform and skipped the governance.
Common Questions
Do we need an integration platform, or are native APIs enough?
Native APIs are sufficient for a small number of integrations with capable consuming teams. Beyond roughly ten to fifteen active interfaces, the operational overhead of monitoring, credential management, transformation and version control justifies a platform — or at minimum a gateway that provides those functions consistently.
How do we avoid an indirect access licensing problem?
Model the data flows against the licensing terms before building, count the systems and end users that will touch ERP data through interfaces, and get the vendor's written position on your specific architecture. Document-based licensing models make this more predictable than user-based ones, but only if you have estimated the document volumes honestly.
What should we do about integrations nobody owns?
Inventory first, then assign ownership or retire. Any interface that no one will claim is either unnecessary or a risk waiting for an upgrade. Retiring unowned integrations is usually the highest-value early activity in an integration programme.
How do AI agents change integration requirements?
They raise the bar on API quality and on authorisation design. Agents need discoverable, well-described interfaces with clear semantics — the same properties that make APIs usable by developers, but less forgiving of gaps, because an agent cannot ask a colleague what a field means. More importantly, an agent acting on ERP data needs scoped, auditable credentials of its own rather than a shared service account, and a record of what it read and changed. Organisations with a governed integration layer can add that control in one place; organisations with point-to-point connections will be granting broad access and hoping.
ERP Integration Strategy — the integration layer you build today decides whether you can change your ERP in five years, so design the contracts before you design the connections.