Enterprise architecture patterns (Hub-and-Spoke, Point-to-Point integrations)

I’ll break down these two core patterns and how they apply in Salesforce architectures.

Point-to-Point Integration

What it is: Direct connections between systems. Salesforce talks directly to System A, System B, System C without intermediaries.

Salesforce context:

Salesforce ←→ ERP
Salesforce ←→ Marketing Cloud
Salesforce ←→ Billing System

Pros:

• Simple to understand and implement initially
• Low latency for single synchronous calls
• Minimal overhead—no middleware layer
• Easy to debug specific connections

Cons:

• Becomes a “spaghetti nightmare” as systems grow
• Each integration requires custom code/configuration
• Changes in one system ripple across all connections
• Difficult to scale—n systems = n(n-1)/2 potential connections
• No central governance or monitoring
• High maintenance cost over time

When to use:

• 2-3 systems only
• Simple, one-way data flows
• Low-volume, non-critical data
• Quick prototypes or MVPs

Hub-and-Spoke Integration

What it is: Central integration hub (usually middleware) acts as the traffic controller. All systems connect to the hub; the hub connects them to each other.

       ┌─── ERP
       │
Salesforce ←→ Hub ←→ Marketing Cloud
       │
       └─── Billing

Salesforce as the Hub: Salesforce can be the hub for smaller ecosystems (e.g., Salesforce → sync data to marketing tools, support systems, analytics).

Dedicated Middleware as Hub: MuleSoft, Boomi, Informatica, custom Node.js/Python services—common in enterprises.

Pros:

• Scales elegantly—add systems without touching existing integrations
• Centralized transformation logic (one place to handle data mapping)
• Single point of monitoring and governance
• Easier to implement patterns like retry logic, error handling, throttling
• Clear audit trail for compliance
• Decouples Salesforce from direct system dependencies

Cons:

• Added complexity and cost (middleware licensing, hosting)
• Hub becomes a critical dependency—single point of failure
• Latency from extra hop (usually negligible, but worth considering)
• Requires more sophisticated tooling and expertise
• Over-engineering for simple scenarios

When to use:

• 4+ systems
• Mixed synchronous and asynchronous needs
• Frequent changes to data flows
• Need centralized governance/audit
• Enterprise-scale compliance requirements

Hybrid Approach (Most Common)

Real enterprises rarely pick one. You typically see:

1. Hub for core data flows (Salesforce ↔ ERP, Salesforce ↔ Data warehouse)
2. Point-to-point for specialized integrations (Salesforce ↔ specific marketing tool)
3. Event-driven via Salesforce (Platform Events in Salesforce as a mini-hub)

Salesforce-Specific Considerations

If Salesforce IS the Hub:

• Use Platform Events as the event backbone
• Leverage Change Data Capture for real-time sync
• MuleSoft (Salesforce-owned) sits outside for external system coordination
• Pros: Reduces external middleware, leverages CRM as authority
• Cons: Salesforce becomes tightly coupled to business processes

If Salesforce IS a Spoke:

• Salesforce is the source of truth for customer/opportunity data
• External hub orchestrates all other systems
• Easier to replace Salesforce if needed
• Better separation of concerns

Key Evaluation Criteria

For Your Fractional Architect Role

When advising clients, the key conversation is usually:

1. Current pain: Are they managing point-to-point spaghetti? Suggest hub strategy + business case on maintenance savings
2. Growth trajectory: If they’re adding systems, hub prevents exponential complexity
3. Compliance: Industries like financial services need hub for audit/governance
4. Technical maturity: Do they have the team to manage middleware? Or should Salesforce play a larger orchestration role?

Would you like me to dive into:

• Specific implementation patterns (Mulesoft flows, Platform Events architecture)?
• Data flow design (sync vs. async trade-offs)?
• Real-world case studies or scenarios?
• How AI/Agentforce changes these patterns?