Middleware denotes the software layer that sits between applications, enabling them to communicate, exchange data and coordinate operations. In the ERP context, middleware connects the ERP backbone with CRM, e-commerce, marketplaces, BI, IoT, supplier portals, partner systems and legacy applications. The middleware category spans classical Enterprise Service Bus (ESB), modern iPaaS, message brokers, API gateways and event-streaming platforms.
Middleware categories
ESB (Enterprise Service Bus) — classical 2000s pattern with a central bus routing messages between systems. IBM Integration Bus, Oracle Service Bus, TIBCO BusinessWorks, MuleSoft (originally ESB, now iPaaS)
iPaaS (Integration Platform as a Service) — modern cloud-native successor: Mulesoft, Boomi, Microsoft Azure Logic Apps and Power Automate, SAP Integration Suite, Workato, Celigo, Informatica IICS
Message brokers — asynchronous messaging: Apache Kafka, RabbitMQ, Amazon SQS, Azure Service Bus, IBM MQ
API gateways — managing exposed APIs: Apigee (Google), Kong, AWS API Gateway, Azure API Management, Tyk, MuleSoft Anypoint API Manager
Event-streaming platforms — Apache Kafka, Apache Pulsar, AWS Kinesis, Azure Event Hubs, Google Pub/Sub — for real-time data flows
ETL/ELT (see ETL) — for analytical data movement, often complementary to operational middleware
Architectural patterns
Three patterns dominate ERP-centric middleware architectures. (1) Hub-and-spoke: all integrations route through a central middleware platform. Simpler governance, single point of failure, can become a bottleneck. Standard for ESB-era integrations. (2) Mesh / point-to-point: applications integrate directly or through lightweight middleware. More resilient, harder to govern at scale. Common in cloud-native landscapes. (3) Event-driven: applications publish events to a central stream (Kafka-style); consumers subscribe to relevant events. Scales well, enables loose coupling. Increasingly common in modern composable architectures. Mid-market in DACH typically combines patterns — iPaaS for operational integrations, event-streaming for real-time data flows, ETL for analytical data, all coordinated through some form of integration governance.
Common ERP middleware use cases
E-commerce to ERP: orders flow from shop into ERP, stock and price flow back. Typically lightweight iPaaS (Microsoft Power Automate, Boomi, Celigo). CRM to ERP: customer master-data sync, opportunity-to-order handoff. Often via native vendor connectors (Salesforce-SAP, HubSpot-NetSuite). Marketplace orchestration: Amazon, eBay, Otto unified into a single ERP. Specialist iPaaS (Plytix, Productsup) or marketplace-management platforms (channable, sellforte). EDI for B2B: legacy EDIFACT plus modern API-based flows to retail and automotive customers. Managed-EDI providers (SEEBURGER, ecosio, Crossinx) act as integration platforms specialised for trading-partner connectivity. BI and analytics: ETL/ELT moves ERP data to data warehouses for analysis.
Practical guidance
Three pieces of practical guidance for ERP-centric middleware. (1) Match tool tier to integration complexity. Simple use cases (5-20 flows) suit lightweight platforms (Zapier, Make, Power Automate Standard). Complex landscapes (50+ flows, real-time requirements, EDI) need enterprise iPaaS (Mulesoft, Boomi, SAP Integration Suite). (2) Invest in integration governance. Without ownership, documentation and review cycles, the integration estate grows brittle and unaccountable. Designate an integration lead, maintain a registry of flows and impose change-control rules. (3) Avoid direct database access in production. Middleware should consume APIs or events, not directly read or write ERP databases. Database-level access breaks at every ERP upgrade and creates governance gaps.
ESB or iPaaS — which should we choose today?
iPaaS for new projects. ESB was the dominant pattern in 2005-2015 but has been displaced by cloud-native iPaaS, which offers lower operational burden, faster delivery and better cloud-app coverage. Legacy ESB installations remain widespread and continue to operate; migrations to iPaaS happen incrementally rather than as big-bang replacements.
Do we need event streaming (Kafka) or is iPaaS enough?
iPaaS is enough for most mid-market integration. Event-streaming becomes valuable above a certain scale: real-time data flows requiring sub-second latency, high event volumes (millions per day), complex event-processing patterns (CEP), or microservice-based application architectures. Below those thresholds, iPaaS with built-in pub/sub features (Boomi, Mulesoft, Azure Logic Apps) typically suffices.
Can the ERP's built-in integration replace dedicated middleware?
For a small number of integrations (under 10 active flows), often yes. Modern cloud ERPs (NetSuite, Business Central, SAP S/4HANA Cloud) include connectors and orchestration tools that cover most lightweight use cases. As integration count grows, the limitations of ERP-bundled integration tooling become visible — weaker monitoring, weaker governance, vendor lock-in — pushing operations toward dedicated iPaaS.
