What is middleware: a definition for the people who have to run it
Middleware is software that sits between two or more systems and handles the exchange between them, translating formats, routing messages, queuing work and retrying failures, so neither system needs to know anything about the other. It is a layer with no business purpose of its own.
The name is old and covers a lot of ground: message brokers, enterprise service buses, integration platforms sold as iPaaS, API gateways and the ordinary bespoke service a team writes when two vendors will not meet in the middle.
What does middleware mean in practice?
Connect two systems directly and each one carries knowledge of the other. Its field names, its authentication, its quirks. That is fine for one pair. At six systems it becomes the wiring diagram nobody wants to inherit, because a change on one side can break connections you had forgotten existed.
Middleware exists to hold that knowledge in one place. Every system talks to the middle layer in its own terms, and the middle layer does the translating. The connections stop being a mesh and start being spokes.
Try Venta Capture on your own process
Build one flow for your highest-volume case type. Free, no credit card.
How does middleware work?
Strip away the product names and most middleware does the same five things:
- Accepts. Receives a message, usually as an HTTP call to an endpoint it exposes or as an event it subscribed to. The mechanics are the same REST API and webhook patterns used everywhere else.
- Transforms. Maps fields, converts formats, normalises dates and reference numbers, and enriches the message from a lookup where one system knows something the other does not.
- Routes. Decides where the message goes, often to more than one destination, sometimes conditionally on its contents.
- Queues. Holds the message when the destination is unavailable, so a downstream outage becomes a delay rather than a loss.
- Records. Logs every message and every attempt, which is what makes an argument about a missing record answerable.
The queue is the part that earns its keep. Without it, a receiving system's maintenance window is a data loss event, and someone spends a morning reconstructing what was sent.
Middleware explained: a practical example
An insurer receives claim submissions from four sources: a customer portal, a broker feed, an email intake and a guided capture tool. All four produce a case, and all four describe damage differently.
Rather than teaching the core policy system four dialects, each source posts to a middleware layer that normalises the payload to one internal claim schema, attaches the policy number from a lookup, and forwards it. Adding a fifth source later means one new mapping, not another change to the policy system.
Middleware or a direct integration: which one you actually need
Middleware is not free. It is another deployment, another set of credentials, another thing that can be down, and another place a message can sit unnoticed. Two systems and one stable handoff rarely justify it.
The layer starts paying for itself when at least one of these is true:
- More than a handful of systems exchange the same kind of record.
- One end cannot be changed, because it is a vendor product, a mainframe, or a system under a support contract that forbids it.
- Delivery has to survive an outage, so something must hold the message.
- Someone has to prove, later, that a specific message was sent and received.
- The same transformation is being written for the third time in three different places.
What middleware gets confused with
- An API gateway sits in front of your own APIs and handles authentication, rate limiting and routing for inbound traffic. Middleware sits between systems and does translation and delivery. Some products do both, which is where the confusion starts.
- A message broker is one component of middleware, the part that queues and distributes. It does no mapping on its own.
- An iPaaS is middleware sold as a hosted service with connectors and a visual builder. Same job, different operating model, and a different bill.
- An ESB is the older centralised form of the same idea, and it carries the reputation of every over centralised integration programme of the 2000s. The lesson worth keeping is that a middle layer everything depends on becomes a bottleneck if one team owns all changes to it.
- An integration platform is not an integration. Buying the layer does not answer which system owns the record, which is still the first question in any integration.
The costs that do not appear in the business case
Debugging gets one step longer, because a missing record now has three places to hide instead of two. Deployments have to be coordinated across teams that previously shipped independently. And the mapping logic becomes institutional knowledge that lives in a tool rather than in a codebase anyone reviews.
None of that is an argument against middleware. It is an argument for documenting the mappings, alerting on the dead letter queue, and giving the layer a named owner before it becomes the thing everything depends on and nobody understands.
Try Venta Capture on your own process
Build one flow for your highest-volume case type. Free, no credit card.