I once counted the systems at a mid-size company I helped. Thirty-four separate tools. And almost none of them talked to each other.
Sales data lived in one place. Support tickets in another. Finance sat in a spreadsheet somebody guarded like treasure. Sound familiar?
That’s the problem integration technologies exist to solve. This category covers the actual tools and platforms that move data between your systems.
Update a customer record in one app and it shows up everywhere it should. No copy-paste. No 2 a.m. exports.
Below you’ll find every technology in this category, what each one does, and a link to its full page. Let’s get into it. 👇
30-Second Summary
This category groups the technologies that physically connect your systems and move data between them:
- Connective plumbing: Middleware, the Enterprise Service Bus, and cloud-native iPaaS platforms that route messages between apps.
- Modern data layers: the Data Fabric and its Data Fabric Architecture, plus a reusable Data Integration Framework to standardize how you connect.
- Structured exchange: Electronic Data Interchange for the standardized business documents that move between companies.
I’ve deployed most of these. Below is the plain tour of what each does and when it’s the right pick.
Why do integration technologies matter?
Because disconnected systems create silos. And silos quietly kill productivity.
When your CRM and your billing system don’t share data, somebody rekeys it by hand. That’s slow. It also introduces errors every single time.
Integration technology is the bridge. One system’s update flows to the others automatically. So the customer who changes their address once sees it change everywhere.
For the broader picture, here’s system integration on Wikipedia.
💡 Field note: The cheapest integration I ever built was the one I didn’t. Before wiring two tools together, I always ask: does this data really need to move, or am I just automating a bad process? Kill the busywork first, then integrate.
The connective plumbing
These are the workhorses. They sit in the middle and pass messages around.
Middleware
Middleware is the software glue between applications.
It sits in the middle, translating and passing messages. Two systems that were never designed to talk suddenly can. Almost every integration you build rests on some form of it.
Enterprise Service Bus
An enterprise service bus, or ESB, is a central hub that routes messages between many systems using shared rules.
Without one, you build a point-to-point link for every pair of apps. With one, everything plugs into the bus instead.
It shines in big on-premise environments with a lot of legacy systems. I’ve watched an ESB replace roughly forty hand-built connections at a single client.
iPaaS
iPaaS stands for integration platform as a service. It’s the cloud-native answer to the ESB.
You build and run integrations from a browser. No servers to manage. If your stack is mostly SaaS, this is usually where I start today.
The modern data layers
These newer approaches worry less about wiring individual apps. They aim at one unified view of all your data.
Data Fabric
A data fabric is a unified layer that connects data across every source, on-premise and cloud.
You reach the data as if it all lived in one place. Metadata and automation stitch it together, so most of it never physically moves.
Data Fabric Architecture
The data fabric architecture is the design pattern behind that layer: the components and rules that make a fabric work.
Think active metadata, smart integration, and a unified access layer. It’s the blueprint, not the product. Vendors sell you the product. You still have to own the blueprint.
Data Integration Framework
A data integration framework is a reusable set of standards, tools, and rules for how your team connects systems.
Without it, every engineer invents a private approach. With it, integration becomes consistent and repeatable. And you stop inheriting a drawer full of one-off scripts.
The structured exchange standard
One technology here predates the cloud by decades, and it still runs quietly under a lot of trade.
Electronic Data Interchange
Electronic data interchange, or EDI, is the long-standing format for swapping business documents between companies.
Purchase orders. Invoices. Shipping notices. All in a fixed structure both sides agreed on in advance.
It isn’t glamorous. But retail, logistics, and healthcare still run on it. Here’s EDI on Wikipedia if you want the history.
Every technology in this category, at a glance
Here’s the quick map. Skim it, then click into whatever you need to solve today.
| Technology | What it is in one line |
|---|---|
| Middleware | Software glue that passes messages between applications. |
| Enterprise Service Bus | A central hub that routes messages using shared rules. |
| iPaaS | A cloud platform for building integrations without servers. |
| Data Fabric | A unified layer connecting data across all your sources. |
| Data Fabric Architecture | The design pattern and components behind a data fabric. |
| Data Integration Framework | Reusable standards and tools for consistent integration. |
| Electronic Data Interchange | A fixed standard for swapping business documents between companies. |
🔍 Quick rule: Mostly cloud apps? Start with iPaaS. Lots of legacy, on-premise systems? An ESB fits. Need one view across everything without moving it? Look at a data fabric.
Where should you start in this category?
Start with middleware. Every other page here is a specialized version of it.
Then read iPaaS and the enterprise service bus back to back. They solve the same routing problem from two different eras, and the comparison teaches you more than either page alone.
Take the data fabric pair next. Read the fabric first, then its architecture.
Leave the data integration framework and EDI for when a real project needs them. They’re both easier to absorb with a live use case in front of you.
And if you’re still deciding on the approach rather than the tooling, our integration concepts hub covers the strategy side of the same problem.
Frequently Asked Questions
What is the difference between middleware and an ESB?
Middleware is the general category of software that connects applications. An enterprise service bus is a specific type of middleware that acts as a central routing hub for many systems at once. Every ESB is middleware, but not all middleware is an ESB.
Is iPaaS replacing the enterprise service bus?
For cloud-heavy companies, largely yes. iPaaS delivers the same routing and integration without servers to maintain. But large enterprises with deep on-premise legacy systems still rely on ESBs, and many run both side by side.
What is the difference between a data fabric and data integration?
Data integration is the broad practice of combining data from different sources. A data fabric is one modern architecture for doing it, a unified layer that uses metadata and automation to connect sources without physically moving all the data.
Is EDI still relevant?
Yes. Electronic data interchange remains the backbone of B2B document exchange in retail, logistics, healthcare, and manufacturing. Many large trading partners still require it, so companies keep it running alongside newer APIs.
Which integration technology should a small company start with?
Most small companies should start with an iPaaS platform. It connects common SaaS apps quickly, needs no servers, and lets a small team build integrations from a browser. You can add heavier technologies later if you truly need them.
Do I need a data fabric if I already have an iPaaS?
Usually not at first. An iPaaS moves data between apps, which covers most mid-size needs. A data fabric earns its place when you have many sources, heavy governance requirements, and people who need one view without waiting for a copy job.
How is a data integration framework different from a tool?
A tool executes the integration. A framework decides how your team builds every integration: naming, error handling, testing, and reuse. You can run one framework across several tools, and that consistency is the point.