What Middleware (or iPaaS) Actually Does, Explained Without the Jargon.
Somewhere in the process of buying business software, a vendor will tell you that you need “middleware,” or an “iPaaS” (the name most people know it by now), or an “integration layer,” usually right before quoting a number for it. Most people nod along, because asking what it means feels like admitting you do not belong in the room. I run one of these for a living, Boomi, sitting between NetSuite and everything else a fuel distributor depends on, so let me explain it the way I wish someone had explained it to me. No jargon, no sales angle.
The problem it solves
Your business runs on more than one system. There is the one that does accounting, the one that does sales, and then the website, the warehouse, the payroll, the tax engine, and the trading partners who send purchase orders as files. Each is good at its job. None of them was built to talk to the others.
So when a customer places an order, that order has to get into accounting, into inventory, and into shipping. When a large customer sends a purchase order as an electronic document instead of a phone call, someone has to turn it into an order your system understands. If nothing connects those systems, a person does it. They read the order off one screen and type it into another. That works when you are small. It falls apart when you are not, because people are slow, people make typos, and people are not at their desk at 2 a.m. when the orders are still arriving.
Middleware is the software that does the passing-along for you. It sits in the middle, watches for something to happen in one system, translates it, and makes the right thing happen in the others. That is the whole idea. It is the translator and the messenger between systems that do not speak the same language.
What that looks like on an ordinary Tuesday
Here is a real one from my side of the desk. A trading partner sends a purchase order as an EDI document, which is a file in a rigid format their system produces and ours has never seen. The middleware picks it up, reads it, and creates a sales order in NetSuite with the right customer, items, and terms. The warehouse fills it. When the invoice is created, the same layer turns it back into the partner’s format and sends it. Nobody retyped anything. When a field does not line up, a good setup parks the document and tells someone, instead of guessing.
Same layer, different job. The tax engine we use returns excise-tax lines on every fuel invoice. Rate data flows in through the middleware, and a set of NetSuite scripts decides where every line posts. The middleware moved the data. The scripts made the decision. Keeping those two jobs separate is a big part of what makes the whole thing maintainable a year later.
Why not just connect them directly?
Fair question, and sometimes you can. Two systems, one simple handoff, and a prebuilt connector between them may be all you need. A connector is a ready-made bridge between two specific applications.
The trouble starts when you have more than a couple of systems. If you wire each one directly to each other, the number of connections grows faster than the number of systems. Four systems that all need to talk is six separate bridges to build and maintain. Five is ten. Six is fifteen. Every one of those is custom, a little fragile, and yours to fix when it breaks. This is the wiring that grows behind a lot of companies without anyone deciding it should, and it is where most integration debt lives.
Middleware, the real integration-platform kind, fixes that by being the hub. Each system connects once, to the hub, and the hub handles the routing. Adding a sixth system is one new connection instead of five. When we absorbed an acquired company, every one of its connections and EDI maps had to be re-pointed or rebuilt. Because ours ran through a hub, that was a list to work through rather than an archaeology dig. That difference is most of what you are paying for when the price goes up.
What “iPaaS” means, since they will say it
iPaaS stands for Integration Platform as a Service, and you can decode it in pieces. “Integration platform” is the hub. “As a service” means you rent it in the cloud instead of installing and running it yourself, the same way you rent email or accounting software now instead of running a server in a closet.
So when someone says iPaaS, they mean a subscription to a cloud-based integration hub. Celigo, Boomi, Workato, and MuleSoft are the names you will hear most in the NetSuite world, and I compared them in a separate post. That is the whole term. You now know it better than half the people using it in the meeting.
What middleware will not do
This is the part the sales call skips.
- It will not fix bad data. If two systems disagree about what a customer is called, the hub will faithfully carry the disagreement everywhere. Cleaning the data is a separate project, and it comes first.
- It will not fix a bad process. Automating a handoff that should not exist gets you a faster version of the wrong thing.
- It will not raise the ceiling of the systems it connects. In NetSuite the limit is often how many requests the account can handle at once, and no middleware subscription changes that number.
- It will not watch itself. An integration nobody owns will eventually break quietly, and you will find out from a customer instead of a dashboard.
Connector or platform: a short decision
| You have | Reach for | Watch out for |
|---|---|---|
| Two systems, one simple handoff | A prebuilt connector | Paying platform money for a bridge-sized job |
| Three or more systems, data moving both ways | An integration platform (iPaaS) | Buying it before anyone owns it |
| Trading partners who send documents (EDI) | A platform with EDI built in | Testing with sample files instead of real partner documents |
| An acquisition on the horizon | A hub you already trust | Point-to-point wiring you will have to redo twice |
Whichever row you are in, the cost is ongoing rather than one-time. Middleware is a subscription, plus the work to build each connection, plus a person whose job includes watching it. Budget for all three.
The software is the easy part. The value, and the risk, is in whether each connection was mapped carefully and whether anyone is watching it. Deciding what genuinely needs connecting, building it so it holds, and keeping it that way through growth and an acquisition is a big part of what I do. Once you can picture the hub in the middle doing the passing-along, the jargon stops being intimidating and becomes a decision you can make with a straight face.