By Cameron Majidi, Solutions Architect, Prolifics
Hub-and-spoke integration is one of the most debated patterns in enterprise architecture. With over 20 years of experience as an application integration specialist, I have worked with multiple generations of integration middleware technologies, primarily from IBM. I’ve successfully supported organizations ranging from small enterprises to global giants.
One architectural approach I consistently advocate is the hub-and-spoke model. Its versatility makes it a reliable method for achieving seamless integration and maximizing operational efficiency.
In this article, we’ll explore what hub-and-spoke integration is, why it faces resistance, and how to approach it more effectively.
What Is the Hub-and-Spoke Model?
At its core, hub-and-spoke integration means:
- Spokes = the applications
- Hub = integration middleware that routes messages
The hub ensures each system can communicate without needing to know the details of the others. This makes it simpler to add or replace systems in the future.
Comparing Integration Design Approaches
1. Point-to-Point Integration
- Every node communicates directly with every other node.
- Middleware can still be used, but the channels are one-to-one.
2. Hub-and-Spoke Integration
- Middleware acts as a neutral hub.
- Applications connect only to the hub, reducing complexity.
3. Sun-and-Planets Approach
- A variation where one application system becomes the “super node” (the “sun”).
- Other applications orbit around it as “planets.”
- This differs from the neutral middleware hub approach.
Why Is There Hostility Towards Hub-and-Spoke?
The resistance is rarely about the communication pattern itself. Most agree it is better than point-to-point once more than two nodes are involved.
Instead, the hostility often surfaces when the model extends to data representation inside the hub.
The Data Representation Dilemma
Here’s how it usually works:
- A system sends a message to the hub.
- The hub routes the message.
- The hub converts data formats for each target system.
The Challenge
- If the hub translates directly from one system’s format to another’s, it essentially becomes point-to-point inside the hub.
- To avoid this, the hub should translate every message into a neutral, hub-specific format first.
Why Do Teams Object?
1. Perceived Inefficiency
- Each message involves two mappings per target system (to neutral format, then to target format).
- This feels like extra overhead compared to direct mapping.
Analogy: In air travel, passengers prefer direct flights. But airlines like Delta and FedEx built hub-and-spoke models because the system as a whole is more efficient.
2. Effort to Build Hub-Specific Data Representations
- Critics say it’s like building a full enterprise data model, which is time-consuming.
- But in reality, this model can evolve gradually, growing more comprehensive as the system matures.
Who Objects Most—and Why?
- Resistance often comes from application technical team leads.
- In theory, they should like the hub—no more maintaining fragile point-to-point code.
- But in practice, there’s a deeper concern:
- If all systems communicate via neutral formats, no single system is “special.”
- Teams may fear this makes their system more easily replaceable.
This underlying suspicion may explain the emotional hostility towards extending hub-and-spoke into data representation.
Key Takeaways
- The hub-and-spoke model simplifies communication and reduces system dependencies.
- Objections typically arise not from the pattern itself, but from how data is handled inside the hub.
- The efficiency tradeoff (extra mappings) is outweighed by scalability and flexibility benefits.
- Building hub-specific formats should be seen as an evolving enterprise asset, not a sunk cost.
Why This Matters Today
In a world where system replacement and modernization are constant, the hub-and-spoke model provides:
- Future-proof integration that survives vendor changes.
- Reduced complexity across growing ecosystems.
- Business resilience through neutrality and flexibility.
For enterprises exploring digital transformation, integration modernization, or middleware strategy, understanding hub-and-spoke design patterns is crucial for long-term success.
About the Author
Cameron Majidi has been with Prolifics since 1996, beginning as a key member of the technical management team overseeing software development and marketing. At the start of the new millennium, he transitioned into his current role as a Solutions Architect specializing in application integration.
Over the years, Cameron has served as the lead architect on numerous enterprise projects, implementing integration middleware for organizations of all sizes—from emerging businesses to large global enterprises. His expertise spans:
- Integration middleware design and implementation
- Solution architecture and system modernization
- Collaboration with enterprises adopting middleware-based strategies
With decades of hands-on experience, Cameron provides clients with deep technical expertise, proven integration strategies, and trusted guidance to maximize business value from their technology investments.
