The question this module answers: When many systems need to talk to each other, should each one connect directly, or should they all go through something in the middle?
So far, we’ve mostly talked about one client talking to one server. That’s typically not how we work. We’re going to get a lot more.
Salesforce talks to the accounting system to get the customer balances. And the accounting system might want to tell Salesforce when an account balance is overdrawn, so it calls back. Salesforce calls the ERP to submit an order, and an hour later the ERP pushes back the completed order. The ERP pushes something to accounting, and goes and updates inventory. Before long, everything is talking to everything.
Let me show you what happens, one system at a time. Three systems down the left, three down the right, and each one may need to talk to every other one, in both directions. Watch the count at the top, and the blue arrows: they’re what each new system adds.
Two systems: Salesforce and the ERP. Salesforce sends the order; the ERP sends back the completed order. Two arrows, one each way.
That’s hub and spoke. Each system talks to the middleware, and the middleware talks to each system. Add a seventh system, and you add two arrows, not twelve.
Now the math behind the picture. Between any two systems, there are two potential flows: A can call B, and B can call A. I’m talking potential flows, not real flows: every pair that might need to talk, in each direction.
So it starts out simple. Two systems, two potential flows. Three systems, six. Four systems, twelve. Five systems, twenty. The math is n × (n − 1), where n is the number of systems. It looks simple, and then it gets crazy.
And every one of those arrows needs something. To call another system, you need its address, its port and its protocol, and the credentials to sign in. Would you give the accounting system, Salesforce and inventory the same username and password to call the ERP? Never. So each caller gets its own. Five systems, twenty sets of credentials, stored all over the estate.
Now one of those systems gets breached, and you need to reset its credentials. Who do you have to talk to? Every system that calls it. That’s a nightmare of maintenance. You get tight interconnections, where every system knows about every other one.
Through the middleware, every system talks to the middleware, and the middleware talks to every system. That’s about two potential flows per system: four for two systems, six for three, eight for four, ten for five. And the system that calls doesn’t need anyone else’s username and password. It just talks to the middleware.
How the arrows grow: point to point against hub and spoke.
The two shapes have names. Systems wired directly to each other are point to point. Systems that all go through one thing in the middle are hub and spoke: the middleware is the hub, and each connection is a spoke. You’ll also hear older names for the hub, like the enterprise service bus, or ESB. And it’s not a new idea: there were object request brokers in the middle long before REST. Chapter 16 tells that story.
The arithmetic is one reason. But a good hub does more than cut down the arrows. Here’s what it can give you.
Routing and orchestration. Say Salesforce wants to submit an order to the ERP, but it should check the customer’s balance first, and not submit if they’re overdrawn. Salesforce could call accounting, come all the way back, decide, and then call the ERP: two round trips, coordinated by Salesforce, the client. Or Salesforce makes one call to the middleware. The middleware checks the balance, submits the order, and goes and updates inventory. To Salesforce, it appears to be one transaction.
Frame 2 of 2: one call; the middleware coordinates the rest.
Central security. Salesforce’s credentials aren’t stored in systems B, C and D. Each system connects to the middleware, and the middleware is the vault of the credentials going out. Fewer places to store secrets means fewer places to leak them. And when a system has to be taken offline, you tell the middleware, and it can account for it.
Data transformation. Salesforce sends out an Account, with an account ID. In the ERP, it’s called a customer. Salesforce has one billing address and one shipping address; the ERP has a separate address table, with as many as it needs. Something has to turn one shape into the other, and the middleware is a good place to do it. Chapter 3’s Schemas and Transformation is about that mapping, and who owns it.
Protocol transformation. Data can come out of Salesforce as a REST call, and the middleware can call the next system as a SOAP web service. It can come in as a JSON payload and go out as XML. The middleware does the translation, and neither side has to learn the other’s language.
You’ve already seen this at Steve Trucking. Its three Retail Partners send their manifests in three different ways: Redrock through a REST API, Keystone as a CSV file over SFTP, Brightwave as EDI through a third-party network. Salesforce doesn’t speak all three. The integration layer does, and turns each one into the same thing on the way in.
Routing, orchestration, central security, data and protocol transformation: that’s what middleware can offer. It’s on the exam, and it’s in real life.
There’s a catch, and you need to say it out loud. With a hub, you’re putting all your eggs in one basket: everything depends on one system. So you’d better have a really strong basket.
Secure it. The middleware holds the credentials to everything. Keep them in its own secure credential store, and guard who can reach it.
Size it. Make sure it can handle your traffic volumes, today and at your busiest.
Plan for it going down. If the hub stops, every spoke stops with it. What happens then?
But notice: without the middleware, you still need to think about all of the same things. If Salesforce calls accounting, then the ERP, then inventory, Salesforce has to handle the logic. What if accounting is down but the ERP is up? What if accounting is up and the ERP is down? What do you tell the users? Orchestration means planning for when things succeed, and for when things start to go wrong, wherever the orchestration lives.
If you only have one or two interconnections, middleware may not be worth it. It’s one more system to buy, run, secure and staff. Two systems talking point to point, with a named credential on one side and an integration user on the other, is often the right answer.
But when you start to get to three, four, five systems, the middleware can be a lifesaver.
There are many middleware products. Salesforce has two of its own now, MuleSoft and Informatica (Salesforce completed its acquisition of Informatica on November 18, 2025: Salesforce Completes Acquisition of Informatica (opens in a new tab), Salesforce, 2025-11-18). Others you’ll meet include Boomi and Jitterbit, and there are many more, from large enterprise platforms to small tools on AppExchange. Which one fits depends on your volumes, your skills, what you already own and your budget. Chapter 17 is about choosing.
How many systems need to talk, and how many potential flows that makes, point to point and through a hub.
Point to point or hub and spoke: and if it’s a hub, which integrations go through it and which don’t.
Where orchestration lives: in the caller, or in the middle. And who plans for each partial failure.
Where each mapping and each protocol translation happens, and who owns it.
How the hub is secured, sized, monitored, and kept running.
Beyond the exam: what AI changes. Every AI agent that calls your systems adds arrows, and agents can multiply them fast: one agent, many tools, many systems. The same arithmetic applies. Let every agent connect to every system directly, and you’re back to n × (n − 1), with credentials everywhere. Put the agents’ calls through one place in the middle, and you get the same benefits: one place for the credentials, one place to see what was called, one place to stop it. Chapter 21 looks at how that’s being built today.
