When You Need Middleware — and When You Do Not

The term middleware sounds like grand architecture but means something very tangible: a layer that sits between two or more systems and brokers the data traffic between them. Instead of the inventory management system writing directly into the shipping program's database, it hands the case over to the broker. The broker accepts, checks, translates, remembers the case and passes it on to the target system. If the target system is unreachable at that moment, the broker waits and tries again later instead of losing the record.

The intermediate layer thus takes on four tasks that would otherwise have to be rebuilt inside every single connection: translation between different formats, buffering so that sender and receiver need not be available at the same moment, retrying failed transfers without creating duplicate postings, and logging in one place. The last point is often skipped over in quotations and is the decisive one in daily work. Anyone wanting to know why an order never reached the warehouse then looks in one place instead of five systems.

The distinction matters: middleware is neither a specific product nor a specific technology. It can be a standalone service on your own server, a queueing system, an integration service from a provider, or a self-written program that collects files at night, reshapes them and passes them on. What counts is not the construction but the question of whether data traffic converges at a defined point where it is visible, repeatable and traceable.

The boundary lies less in a particular number of systems than in the number of connections between them. If all systems are to be able to exchange data with one another, that number grows by the formula n times (n minus 1) divided by two. Three systems produce 3 connections, five systems 10, eight systems already 28 (worked example). In practice not every system exchanges data with every other, so the actual number is lower. The direction remains the same, though: each additional system brings more new connections with it than there are systems.

The practical tipping point usually arrives earlier than the formula suggests. It comes the moment the same data is needed by more than two systems. As soon as a customer address has to exist in inventory management, in the order system, in the shipping program and in accounting, point-to-point connections create a web in which one change in one place affects four others. Anyone replacing a system then has to touch every single connection.

The second typical trigger is troubleshooting. As long as every connection keeps its own log — one in a text file, one in a database table, one not at all — answering the question of where an order got stuck takes longer than fixing it. In our experience this is the point at which companies ask for an intermediate layer of their own accord: not because of architecture, but because searching costs too much time (project experience).

An intermediate layer transports and translates, but it does not repair poor data. If the order system holds three spellings of the same customer, a broker produces three records in the target system instead of two — faster and more reliably than before, but just as wrong. Master data maintenance and clarifying which system leads for which field remain tasks of data integration and belong before the technical implementation.

Nor does a broker replace business decisions. Whether an order may go to shipping without a credit check, whether an invoice is created immediately after a partial delivery, whether cancellations may be posted retroactively: these are rules of the business, not questions of transfer technology. If they are pushed unresolved into the intermediate layer, a second, undocumented layer of business logic grows there over time alongside the actual systems — and that is harder to change later than any interface.

The decision for or against an intermediate layer can be made considerably more objective with a handful of questions. They should be answered in writing before technology is discussed — as part of a process analysis or in a separate session with the people who carry out the affected workflows every day.

The answers to questions one to four show whether the need exists. The answers to five and six decide whether the solution will hold up in operation. A project in which the last two questions remain open should be postponed until they are answered.

The benefit of an intermediate layer arises in operation, not at rollout. Two things are needed for that: a log that a person with business responsibility can read, and a notification that reaches someone before the customer calls. A usable log carries an unambiguous identifier per case so that a transfer can be traced across several systems.

The example makes the difference between the three relevant states visible: "ok" needs no attention, "error" is retried automatically and only raises an alert once the retries are exhausted, "rejected" needs a person because the data itself is incomplete. This distinction decides whether monitoring stays useful or gets ignored after two weeks.

Equally important is the planned restart. After an outage of the broker it must be clear whether open cases catch up automatically or have to be triggered manually, and how it is detected if something was delivered twice in the process. These questions belong to ongoing IT operations and should be answered in writing before the first incident, not during it.