Middleware is usually chosen early in a project and thought about again only when a message goes missing. It sits on the boundary between applications and handles translation, routing and security, which means that when it fails quietly, orders stop moving and nobody is paged. Being precise about what the layer is responsible for makes both the choice of product and the monitoring afterwards much easier.
The boundary middleware sits on
Every application has a boundary: the set of things it accepts from the outside world and the set of things it offers to it. When two applications are connected directly, each one has to understand the other's boundary, its field names, its authentication and its failure modes. Middleware is a separate piece of software placed between those boundaries so that each application has to understand only one thing, the layer itself.
The analogy I find useful is a railway junction. Trains from several lines arrive, are checked, are switched onto the right track and leave in an order that the timetable allows. The junction does not own the trains or decide what they carry. It owns the switching rules and the signals, and when those are wrong, every line that passes through it is affected at once.
That last point is the one people underestimate. A middleware layer concentrates risk as well as convenience, so it needs an owner, monitoring and a release process of its own, in the same way that an application does.
Four jobs the layer takes on
In concrete terms, middleware does four jobs. It translates formats, protocols and field names, so each system receives data in the shape it expects, down to details such as whether a GSTIN lives in its own column or in a notes field. It routes and orchestrates, sending an order through CRM, ERP, inventory and shipping in the right sequence. It enforces authentication, encryption and access control for data in transit. And it gives a new application one place to connect, in place of a new link to each existing system.
- 01Order receivedFrom the web shop
- 02Validate and translateTo each system's format
- 03Publish to queueHeld until consumed
- 04Inventory and shippingEach takes what it needs
The queue lets inventory be briefly unavailable without the order being lost.
What the layer does not do is equally important. It does not own the data that passes through it, and it cannot decide which of two conflicting records is correct. It converts a dealer record from one format to another faithfully, including when the record is wrong. Data cleaning and ownership rules belong to the systems and people on either side.
Brokers, gateways, buses and iPaaS
Four kinds of product cover most of the market, and they solve different parts of the problem.
| Type | Role | Examples |
|---|---|---|
| Enterprise service bus | Central bus that routes and transforms messages | Commercial and open-source ESBs |
| Message broker | Asynchronous messaging between applications | RabbitMQ, Kafka |
| API gateway | Manages and secures system-to-system APIs | Gateways in front of internal and partner APIs |
| iPaaS | Hosted integration platform with prebuilt connectors | Dell Boomi, MuleSoft, Workato |
Real setups combine them. A broker moves the events, a gateway protects the APIs that other teams call, and an iPaaS handles the connections to SaaS tools such as the HR platform and the payment gateway dashboard. We prefer to start with a broker and a gateway and add an iPaaS only when the number of SaaS connectors justifies the licence. How these categories are changing with hosted platforms and event streaming is the subject of our piece on iPaaS, event-driven design and AI in integration.
How middleware goes wrong
The first failure is business rules drifting into the layer. Pricing, approval limits and eligibility checks get written into transformation steps, where the people who own those rules cannot see them. Six months later nobody can say why orders above two lakh go to a different queue, and the answer lives in a mapping that one developer wrote.
The second is that nothing watches it, because a working integration is invisible. A queue backs up or a connector token expires on a Sunday, and the first signal is a customer. A logistics firm whose booking system stops sending shipments to the warehouse will usually hear about it from the consignee before its own operations team notices.
The third group concerns messages that cannot be delivered. Without a dead-letter queue, a bad record is either dropped or retried indefinitely. Retries create their own problem, because a message resent after a timeout is processed twice unless the receiving system can recognise it as a repeat. Designing receivers so that handling the same message twice does no harm is cheap at the start and expensive to add later.
The last is the bus becoming a bottleneck. One central component, owned by one team, ends up on the critical path of every project in the company, and every change waits for that team's capacity.
Operating the layer after go-live
Monitoring should be specific to each flow. Track how many messages arrive, how many fail, how long the oldest one has been waiting, and when each credential or certificate expires. Alerts go to a named person or team on a channel they actually read. A shared mailbox is read by nobody; a small group with the on-call engineer in it is read when the mailbox is not.
Versioning is the other quiet problem. When one application changes its API or renames a field, every flow through the layer that touches it is affected. Keep transformation rules in source control, test them against sample messages, and release changes the way you release application code, with a review and a way back. The rules are code, whatever the vendor's editor makes them look like.
Ownership of the rules themselves deserves a line in the operating plan. In practice the transformation logic is owned by the integration team, while the business rules it encodes are owned by finance, sales or operations. Both parties need to be able to read the mappings, or the layer becomes the only place where the business's rules are written down.
Questions before you commit
- Fast to build for one flow
- Every app needs its own translation
- Failures show up in the apps themselves
- One place for translation and security
- New apps connect once
- Needs monitoring and an owner
Middleware moves the complexity to one place, and someone has to look after that place.
Before choosing a product, you should be able to answer three questions for your own flows. Which flows need an immediate answer, and which can wait in a queue? Where do failed messages go, and who sees them? Can each receiving system handle the same message twice without harm?
The first question decides most of the architecture, because it tells you whether you need a broker at all. If you are still at the stage of deciding which systems should connect, our beginner's guide to enterprise application integration covers that step, and our enterprise application integration practice works through the same questions with clients. Answer them now, while the layer is small. When it carries forty flows, every unanswered question becomes an incident that someone has to diagnose at night.
