What Is Middleware?

Middleware is one of those words that describes something by where it sits rather than what it does. It roughly means in-between software, software in the middle, and that captures the point: middleware is the glue between systems that would otherwise struggle to talk to each other. For anyone trying to understand how a system landscape fits together, it’s a key concept. Here’s the explanation.

The analogy: the interpreter

Picture two people who need to do business but don’t speak the same language. They could struggle along with gestures and scattered words, but that’s slow and full of misunderstandings. Put an interpreter between them instead, and it works out. Each speaks their own language to the interpreter, who translates both ways. The parties never need to learn each other’s language – they just need to talk to the interpreter.

Middleware is that interpreter between systems. Two systems can be built in completely different ways, speak different formats, and run at different speeds. Instead of forcing them to understand each other directly, a middle layer is placed between them. Each system talks to the middleware in its own way, and it translates and relays. The systems don’t need to know each other’s insides.

What middleware actually does

Behind the interpreter image are a few concrete tasks. Middleware typically does three things, often in combination:

• Translates. Different systems describe the same thing in different ways. The middleware converts data from one format to another, so the receiver understands what the sender means.
• Queues. If the receiver is busy or temporarily down, the middleware can hold the messages in a queue and deliver them when it can, instead of them being lost. The flow survives one party not being ready right now.
• Relays. It makes sure the right data takes the right path to the right system, and routes messages where they need to go when many systems are involved.

Together they let the systems collaborate without being tightly coupled. Each does its own job, and the middle layer holds it together.

Concrete forms

Middleware is an umbrella term rather than a single product, and it takes several forms:

• Message queues. They receive messages and hold them until the receiver is ready. Nothing gets lost that way if one side is busy, and systems working at different speeds can still cooperate.
• Integration engines. They translate and route data between many systems, and are the hub when an entire landscape needs to fit together.
• API gateways. The shared entrance in front of several services also counts as a form of middleware, since it sits between the consumers and the services and relays.

Common to all of them: they sit in the middle and handle the relaying, so the systems on each side can be kept independent of each other.

The benefit during system changes

This might be the strongest reason to care about middleware, even as a decision-maker. When systems talk directly to each other, they become tightly intertwined. If you replace one, you’re often forced to change everything that was connected to it, since the dependencies run every which way. A system change then becomes a large, risky project that sprawls far beyond the system itself.

With middleware in between, that dependency is broken. The systems talk to the middle layer, not directly to each other. If you need to replace one, it’s largely enough to adjust its connection to the middleware – the other side can be left untouched, since it only knows the middle layer. You can swap one side without touching the other.

That makes the system landscape more flexible and future-proof. Systems will get replaced over time, and a middle layer makes every such change less painful.

A concrete way to see it: say you replace your ERP system, something most organizations do sooner or later. Without middleware, where the website, warehouse, and finance systems talk directly to the old ERP, each of those connections has to be rebuilt against the new one. With a middle layer in between, they instead talk to the middleware, and only its one connection – to the ERP – needs to be replaced. The other systems barely notice the change. That’s the difference between touching everything and touching one point.

At Weapp we build integrations with the right amount of middle layer – enough to keep systems independent, without unnecessary complexity. Check out our services or get in touch.