What is middleware, and does a small business need it?
Key takeaways
Middleware sounds like it belongs in a large IT department. The idea is simpler than the name. What it is, when a small business needs it, when it does not, and what a good one looks like.
Middleware is one of those words that sounds like it belongs in a large company's IT department and has nothing to do with a business of twenty people. It does, and the idea is simpler than the name.
Here is what it is, when a small business needs it, when it does not, and what to watch for if somebody proposes it.
What it is
Middleware is software that sits between two or more other systems and passes information between them. That is the whole definition.
It does not have a screen your staff use. It does not replace anything. It runs quietly in the background, notices when something happens in one system, an order placed, an invoice raised, a customer added, and makes the matching thing happen in another.
You can think of it as the person who currently copies orders from the website into the accounts package, except it does not get bored, does not mistype, and works at three in the morning.
Why not connect the two systems directly?
Sometimes you can, and when you can, you should. Plenty of shop platforms and accounts packages have a ready-made link between them, and if it does what you need, it is the cheapest answer there is.
Middleware earns its place when the direct link does not exist, or exists but does not do the job:
The two systems disagree about what things are. Your shop thinks of a customer as an email address. Your accounts package thinks of a customer as a company with a credit limit. Something has to decide how one becomes the other, and that something is middleware.
There are rules in between. Orders over a certain value need approving. Trade customers get a different tax treatment. Some products never go to the accounts package at all. A direct link rarely knows your rules.
There are more than two systems. Once three or four systems need to share information, connecting each one to every other one becomes a tangle. A single piece of middleware in the middle, with each system connected to it, is far easier to understand and to change.
One of them is old. An older system might only produce an export file once a night. Middleware can collect that file, make sense of it, and pass it on as if the old system were modern.
When a small business does not need it
When a ready-made connection between your two systems already does what you need. Use it.
When the volume is tiny and nothing goes wrong. Ten records a week copied accurately by hand is cheaper than any software.
When one of the systems is about to be replaced. Build the connection to the new one, not the old one.
What a good one looks like
You can see it working. Somewhere you can look and see that yesterday's orders went across, and a clear, specific message when one did not. A connection that fails silently is worse than none, because everyone has stopped checking.
It is boring. The best middleware is a small program that does one job and is easy to read. If the proposal involves a platform with a monthly fee per connection and a vocabulary of its own, ask what it does that a small program would not.
It runs in accounts in your name. The hosting it runs on and the credentials it uses to reach your systems should belong to your business. If the supplier who built it disappears, it should keep running and anybody competent should be able to take it over. You own your accounts, you licence the code, and you can leave whenever you like.
It is written down. Which systems it connects, what it moves, what rules it applies and what happens when something fails. One page is usually enough.
What it usually costs
Less than people expect, because most of the work is understanding your rules rather than writing code. A one-way connection between two well-documented modern systems is a modest job. Two-way connections, older systems, and messy existing data all add to it, and each of those is a known quantity rather than a mystery.
The useful number to have before you ask anybody is what the copying costs you now, in hours and in mistakes. That is what any price should be compared against.
What we do
Middleware is ordinary work here, and each connection is priced as a job in its own right. You tell us which systems and what has to move. You get a price in writing before anything starts, and nothing begins until you approve it.
If a ready-made link already does what you need, we will tell you to use it.
The price changes with the size of the job. The standard never does.