Häufig gestellte Fragen
What is the difference between middleware and an API?
An API is a specific access point of a single system through which other programs can retrieve its data and functions. Middleware is the overarching mediation layer that sits between multiple systems, coordinating their API calls, translating data formats and monitoring the message flow. You can use an API without deploying middleware, but as soon as many systems are connected to one another, middleware takes over the orchestration of these interfaces. Put simply, the API is a system's door, while middleware is the traffic control centre between many such doors.
Do I need middleware with cloud ERPs?
As soon as three or more cloud applications need to exchange data with each other, an intermediary integration layer generally makes sense, because the maintenance effort of direct point-to-point connections grows sharply with each additional application. In the cloud environment this role is nowadays usually taken by an iPaaS platform (Integration Platform as a Service), which provides ready-made connectors and mapping tools as a service. With only two systems and a stable, well-documented interface, a direct connection can be sufficient. The exact setup always depends on the industry, company size and depth of customisation of the specific ERP environment.
What is the difference between an ESB and iPaaS?
An Enterprise Service Bus (ESB) is a classic integration architecture, usually operated on-premises, in which all messages pass through a central bus and which accordingly entails high operating and maintenance overhead. iPaaS (Integration Platform as a Service) is the cloud-based, newer variant of the same basic idea and provides connectors and low-code tools as a subscription service. Both are forms of middleware, but they differ markedly in operating model and cost structure: iPaaS is typically billed as a predictable subscription, whereas an ESB can incur high infrastructure and staffing costs. In practice, companies with deep legacy landscapes and strict compliance requirements sometimes still choose an ESB, while the mid-market more often gravitates towards iPaaS.
What does a middleware or integration solution cost in the mid-market?
There are no reliable blanket figures, as the costs depend heavily on the number and complexity of the connections, the data volume and the chosen operating model. Cloud-based iPaaS solutions are usually billed as an annual subscription, whose range in the mid-market can roughly span from the low to the mid five-figure euro range per year, plus implementation and consulting services of a similar magnitude. Classic on-premises middleware additionally incurs costs for hardware, licences and internal operations, which can turn out considerably higher over its lifetime. For a serious cost estimate, an individual quote based on the specific system landscape is therefore always advisable.
What is message-oriented middleware and what is a message broker for?
Message-oriented middleware (MOM) is a specific form of middleware in which systems do not talk to each other directly but exchange messages via a mediating component, the message broker. The broker accepts messages, holds them in a queue if necessary and delivers them once the target system is available, decoupling sender and receiver both in time and technically. Well-known representatives include RabbitMQ, which is designed for reliable task and background processing, and Apache Kafka, which is conceived as a streaming platform for very high throughput and the durable storage of event streams. In the ERP context this principle ensures that orders or stock movements, for example, are not lost even if a connected system is briefly unreachable.
Which data protection aspects need to be considered with middleware?
Since middleware mediates data flows between systems and in doing so frequently also transports personal data such as customer or employee master data, its operation falls within the scope of the GDPR. If a cloud-based iPaaS or middleware solution from a service provider is used, this generally constitutes processing on behalf of a controller, for which a data processing agreement must be concluded. Also important are appropriate technical and organisational measures such as encrypted transmission and storage, as well as clarifying in which country the data is processed, since processing outside the EU can trigger additional requirements such as EU standard contractual clauses. Responsibility for legal compliance remains with the company acting as data controller, which is why vendor selection and contractual safeguards should be handled with care.