Skip to main content

Middleware

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. US mid-market companies typically combine 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, Walmart and eBay unified into a single ERP. Marketplace-management and feed platforms (ChannelAdvisor/Rithum, Feedonomics) or specialist iPaaS connectors. EDI for B2B: legacy X12 and EDIFACT formats plus modern API-based flows to retail and automotive customers. Managed-EDI providers (SPS Commerce, TrueCommerce, Cleo) act as integration platforms specialized 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.

Related Topics