Hub-and-spoke works when you own everything in the graph. Point-to-point takes over when you don’t. Most enterprises end up running a hybrid model, or a completely distributed one. Here’s how to think about which pattern belongs where.
What Are Enterprise Integration Patterns
Enterprise integration patterns are the architectural models organizations use when connecting multiple systems: not just which tools talk to each other, but how those connections are structured, who controls them, and what happens when a new system joins the network.
The three most discussed patterns are point-to-point (direct connections between system pairs), hub-and-spoke (one central platform routing everything), and federated (distributed control, no single hub).
Most organizations start with one type of connection and end up running a hybrid version of all three.
This has played out enough times: the integration architecture always starts with a point-to-point, or a clean central hub with tidy lines going out to each system. But it changes dramatically over the years.
Here’s what the patterns actually are, when each one makes sense, and why the honest answer is different for each scenario.
Key Takeaways
- Own both sides → hub-and-spoke works. Own one side → it becomes a bottleneck you can’t escape.
- Point-to-point’s bad reputation comes from unscoped connections, not the pattern itself.
- Federated is the only honest option when two organizations won’t agree to share a hub.
- The real decision question isn’t “which pattern”: it’s “who owns each connection.”
What Are The Main Enterprise Integration Patterns
Point-to-point is the oldest and most common. System A connects directly to System B. Jira connects to ServiceNow. Salesforce connects to Jira. GitHub connects to Jira. Each connection is independent. There is no shared middleware, no central routing layer, no platform sitting in between.
Hub-and-spoke puts one central platform in the middle. Every system connects to the hub, and the hub routes data between them. iPaaS platforms like MuleSoft, Workato, or Azure Logic Apps are designed around this model.
The hub owns the mapping, the transformation, the routing. The systems themselves don’t know about each other.
Often, information flows only in the direction of the Hub, making it unidirectional. For instance, several Jira Service Management (JSM) instances, used for ticketing, connect to a central engineering instance, like Azure DevOps.
Federated (sometimes called “service mesh” in specific technical contexts) distributes control across each system. There is no hub.
Each system independently defines what it shares and what it accepts. The connections are still point-to-point in practice, but the governing rules live on each side separately.
For instance, a single ServiceNow instance can be connected to Salesforce, which in turn connects to Jira. The ServiceNow instance, at the same time, can also be connected to another ITSM system like Zendesk for L1-L2 support escalations.
Case Study: Learn how an MSP saves 5 hours per engineer per week with an integration pattern that suits their requirements.
When Does Hub-and-Spoke Actually Make Sense?
Hub-and-spoke is a pattern that works well under specific conditions, and fails when those conditions aren’t met.
The clearest case for hub-and-spoke: MSPs managing connections to multiple clients.
If you’re a managed service provider with 30 client environments, all of which need to sync tickets into your central ServiceNow instance, hub-and-spoke is the right call. You own the hub. You define the mappings.
Every client spoke plugs into the same central system you control. That’s exactly the architecture the pattern was designed for.
The same logic applies inside large enterprises when one team owns all the systems in the integration. A single IT ops team managing ServiceNow, Jira, Salesforce, and an HRIS system can run a hub-and-spoke model effectively, because they have the authority to set the rules for every system in the graph.
One platform, one governance layer, one place to audit what crossed where.
Hub-and-spoke also pays off when you have many systems that need to share a consistent data model.
If you’re connecting 15 systems and each one needs to understand the same definition of “customer,” “priority level,” and “resolution status,” a central hub that normalizes data before routing it is genuinely easier to maintain than 15 point-to-point connections each doing their own translation independently.
The pattern that explains most of hub-and-spoke’s reputation problem: organizations use it where they don’t own all the spokes.
Where Does Hub-and-Spoke Run Into Trouble?
The problem surfaces when teams on the other end of the spoke don’t want to cooperate with someone else’s platform.
A pattern from Exalate’s customer experience: one large enterprise runs an iPaaS platform as their integration hub for everything internal (ServiceNow, Salesforce, internal engineering systems).
But for connections that cross company boundaries (external vendors whose Jira instances need to talk to the internal Jira), they use a separate point-to-point connector instead.
The hub works for internal routing where one team controls both sides. It doesn’t hold ground when an outside vendor isn’t going to agree to route through someone else’s hub.
The other failure mode is internal governance friction.
Hub-and-spoke creates a platform that multiple teams have to share. The dev team doesn’t want the ServiceNow admin changing how data arrives in Jira. The ServiceNow team doesn’t want their internal fields exposed to whatever the hub is doing with them.
As soon as two teams have different priorities for the same connection, the shared hub becomes a negotiation problem rather than a technical solution.
Why Do Most Enterprises End Up Running Point-to-Point
Point-to-point has a reputation for creating unmanageable spaghetti. This is true if connections aren’t scoped. But point-to-point has one advantage hub-and-spoke doesn’t: each connection is owned by the teams actually using it.
The most common enterprise integration architecture we see in practice isn’t hub-and-spoke.
It’s several point-to-point connections, built team by team, as the need arose.
Support is in ServiceNow. Engineering is in Jira. An integration is built so incident escalations flow to Jira automatically.
Later, a vendor needed to see certain Jira tickets, so another connection went up. Later still, Salesforce started feeding cases into Jira through a third connection.
None of these were “designed” as a unified architecture. They accumulated.
And as long as each connection is scoped correctly (explicit trigger conditions, defined field mapping, clear direction of authority), accumulated point-to-point connections are often easier to maintain than a hub everyone has to agree on.
The friction in point-to-point isn’t the connections themselves. It’s when connections aren’t scoped.
When every update in System A triggers a sync to System B, regardless of whether it’s relevant.
A pattern that comes up consistently in Exalate’s discovery calls: teams that set up unconditional sync end up with a firehose of data crossing systems, and the teams on the receiving end start ignoring it.
One user explicitly said they didn’t want every ServiceNow incident auto-pushed into Jira. They wanted their teams to choose when a record was worth tracking in both systems. Selective sync is what makes point-to-point sustainable at scale.
What Does “Beyond” Look Like In Enterprise Integration Architecture
There is a third pattern that doesn’t get named enough: federated point-to-point.
Instead of a central hub or a central governance layer, each system independently defines what it shares and what it accepts.
No middleware enforces centralization. Each connection is still direct, but the rules for that connection live on each side separately, not in shared configuration.
This is what enterprise integration looks like when the connected systems belong to different organizations.
Vendor connects to customer. Two companies in an M&A manage their tool stacks independently through the transition. An MSP maintains separate connections to each client’s system. Nobody is going to agree to let the other party’s hub control their side of the routing.
Federated architecture is politically easier than asking everyone to use the same hub, because each team keeps control of their own configuration.
It’s technically harder than centralized mapping, because the two sides have to agree on what gets exchanged without a shared platform to enforce consistency.
What works: treating each connection as a contract. These fields cross. These don’t. This system has final authority on status. This system has final authority on assignment. The contract lives in the connection configuration on each side, not in a shared document that gets outdated.
How To Choose Your Enterprise Integration Pattern
The decision isn’t “hub-and-spoke vs. point-to-point.” It’s a sequence of more specific questions.
Do you own both sides of the connection, or just one?
You own all the systems (or manage them on behalf of clients): hub-and-spoke is the right call. MSPs with multiple client environments, internal IT teams with full system ownership. This is the architecture’s home territory.
You’re connecting to systems you don’t control: point-to-point or federated.
Are you connecting systems inside one organization, or across organizational boundaries?
Internal, with consistent governance: hub-and-spoke is viable if you have the authority to enforce it.
Cross-company, or cross-team with conflicting authority: point-to-point or federated.
How many systems need to be connected?
Two or three: point-to-point almost always wins on simplicity.
Dozens, with consistent data model requirements: hub-and-spoke starts to pay off.
The normalization benefit compounds at scale.
Do the teams on each side trust each other enough to share a hub?
If the answer is no, you need a federated approach regardless of what the architecture deck says.
Is this ongoing sync or a one-time migration?
Migration: you’re moving data once, so what matters is completeness: history, attachments, field mapping accuracy. The integration pattern is almost secondary to getting the data right.
Dedicated migration tools often make more sense than your ongoing sync layer.
Ongoing: you’re maintaining a live connection indefinitely, so pick the pattern your team can actually own and update as workflows change.
For teams evaluating enterprise application integration services, the most useful frame isn’t “which pattern do we choose.” It’s “which connections need to exist, and who owns each side of each connection.” That question usually answers the architecture question by default.
| Question | Hub-and-spoke | Point-to-point | Federated |
|---|---|---|---|
| Who owns both sides? | You own all systems | You own one side only | Neither side owns the other |
| Governance | Centralized, one rulebook | Owned per-connection by each team | Rules live on each side separately |
| Scales best at | Dozens of systems, shared data model | Two or three systems | Cross-company, no shared authority |
| Fails when | You don’t own every spoke | Sync conditions aren’t scoped | Both sides won’t agree on a contract |
| Home turf | MSPs, centralized IT | Team-by-team internal builds | Vendor/customer, M&A, MSP-to-client |
The Enterprise Integration Pattern You Can Actually Govern
The best integration architecture is the one your team can actually own and maintain.
Hub-and-spoke is the right answer when you own the hub and the spokes. MSPs, centralized IT teams, internal platforms with full governance authority: the pattern was designed for exactly this situation. If that’s your context, build the hub and don’t let anyone talk you out of it.
Hub-and-spoke runs into trouble when you only own one side. The complexity doesn’t disappear. It transfers into the hub, and whoever owns it becomes a bottleneck for every team that needs to change their configuration.
Point-to-point looks like it creates a mess. In practice, well-scoped connections with explicit trigger conditions are easier to manage than a shared platform that requires everyone’s agreement to change, as long as each team owns their own side.
The most functional enterprise integration architectures are the ones where each team owns their own side of each connection, trigger conditions are selective (not “sync everything”), and proper governance is in place for reviewing the configurations when workflows change.
Exalate is a purpose-built connector for bidirectional sync between Jira, ServiceNow, Azure DevOps, Salesforce, and Zendesk. It works on a federated model by design: each side configures what it shares independently, without requiring access to the other side’s system.
That’s not an abstract design choice. One bank customer’s Jira admin didn’t have super-admin access to their Azure DevOps instance, and corporate policy blocked getting it. That’s the exact governance wall this article describes.
If you’re working through what a point-to-point or federated architecture looks like at the connection level, reach out to our experts to discuss the specifics, or try Exalate directly.
Recommended Reads:
