What is the difference between hub-and-spoke and event-driven integration?

Hub-and-spoke routes all data through a central middleware layer that orchestrates and transforms messages between systems. It offers good visibility and control but creates a single dependency on the middleware. Event-driven integration uses published events that any system can subscribe to, offering looser coupling and better scalability. Most mid-market retailers benefit from starting with hub-and-spoke for core commerce flows and introducing event-driven patterns selectively for high-volume or real-time requirements.

Should we use an iPaaS or build custom middleware?

For most mid-market retailers, an iPaaS (integration platform as a service) like Celigo, Workato, or Boomi is the right starting point. They reduce build time, provide pre-built connectors, and include monitoring out of the box. Custom middleware makes sense when you have highly specific transformation logic, extreme volume requirements, or a strong engineering team that can maintain it long term. Avoid building custom unless you have a clear reason an iPaaS cannot meet your needs.

Who should own integrations in a retail business?

Integration ownership should sit with a dedicated integration or platform team, or at minimum a named individual with clear accountability. The worst pattern is splitting ownership between the teams responsible for each connected system, as gaps between systems become nobody's problem. If you cannot justify a dedicated team, assign a single engineer or architect as the integration owner with authority to set standards, approve new connections, and manage incidents.

Building an integration strategy that does not collapse under its own weight

Introduction: Why integrations are where retail tech programmes fail

Open with the observation that most retail technology roadmaps focus on platform selection, but the real risk sits in the spaces between platforms. Explain that integrations account for the majority of budget overruns, go-live delays, and post-launch operational issues in retail technology programmes.

Set up the article as a practical guide covering architecture patterns, technology choices, and the often-neglected human and organisational factors.

The spaghetti problem: how integration debt accumulates

How it starts: a few simple connections

Describe the typical trajectory where a business starts with a handful of point-to-point integrations that work fine, then gradually adds more systems until the integration landscape becomes unmanageable. Use a realistic retail example (ERP, commerce platform, OMS, WMS, CRM, marketing tools).

The symptoms of integration debt

List the practical signs that integration debt is becoming a problem: data inconsistencies between systems, slow and brittle sync processes, nobody knowing how data flows end to end, and incidents that take days to diagnose because the root cause spans multiple systems.

The compounding effect

Explain how integration debt compounds faster than other forms of technical debt because every new system multiplies the number of potential connection points and failure modes.

Integration architecture patterns

Point-to-point: when it works and when it breaks

Describe point-to-point integration, where it is appropriate (fewer than five systems, low data volume, simple transformations), and the specific conditions under which it becomes a liability.

Hub-and-spoke: the workhorse pattern

Explain hub-and-spoke architecture with a central middleware or integration layer. Cover why this is the right default for most mid-market retailers, its advantages for visibility and maintainability, and the risk of the hub becoming a bottleneck or single point of failure.

Event-driven: decoupled and scalable

Introduce event-driven architecture using message brokers or event streams. Explain when retailers should consider this pattern (high-volume inventory updates, real-time pricing, multi-channel order routing) and the operational maturity required to run it effectively.

Choosing the right pattern for your context

Provide a practical decision guide based on system count, data volume, team capability, and real-time requirements. Emphasise that most retailers will use a combination of patterns rather than a single approach.

Middleware vs API-first: the technology layer

What middleware actually does

Demystify middleware by explaining its core functions: message routing, data transformation, error handling, retry logic, and monitoring. Argue that middleware is not overhead but essential infrastructure once your integration landscape passes a certain complexity threshold.

iPaaS, enterprise middleware, or custom-built

Compare the three main options: iPaaS platforms (Celigo, Workato, Boomi), enterprise middleware (MuleSoft, Dell Boomi at scale), and custom-built integration layers. Provide guidance on which suits different retailer profiles based on budget, team size, and complexity.

API-first thinking

Explain what API-first means in practice: designing system interfaces around well-documented, versioned APIs rather than relying on file transfers, database replication, or vendor-specific connectors. Cover how this approach reduces coupling and makes integrations more resilient to change.

Managing vendor dependencies

Vendor APIs are not all equal

Discuss the reality that vendor API quality varies enormously. Cover common issues: rate limits, missing endpoints, poor documentation, breaking changes without notice, and the gap between what was promised in the sales cycle and what the API actually delivers.

Protecting yourself from vendor API changes

Provide practical strategies for insulating your integration layer from vendor changes: abstraction layers, contract testing, version pinning, and maintaining vendor relationship channels specifically for API communication.

The vendor lock-in integration dimension

Explain how deep integrations create switching costs that go well beyond the platform itself. Argue that integration architecture should be designed with future flexibility in mind, even if you have no current plans to change vendors.

Monitoring, error handling, and operational resilience

Why error handling is not an afterthought

Make the case that most integration failures are not caused by the initial build but by inadequate handling of edge cases, timeouts, partial failures, and data quality issues that only emerge under real production conditions.

Building observable integrations

Cover practical monitoring requirements: transaction logging, alerting on failures and latency, data reconciliation checks, and dashboards that give operations teams visibility into integration health without requiring engineering support.

Retry logic, dead letter queues, and graceful degradation

Explain the core patterns for handling integration failures: idempotent operations, exponential backoff, dead letter queues for failed messages, and circuit breakers that prevent cascading failures across systems.

The human side: who owns integrations

The ownership gap

Describe the common anti-pattern where integrations fall between teams, with each team owning their system but nobody owning the connection between systems. Explain why this leads to finger-pointing during incidents and slow resolution.

Integration as a team capability

Argue for either a dedicated integration team or a named integration owner with cross-system authority. Cover what this role involves: setting standards, approving new integrations, managing the middleware layer, and coordinating incident response.

Documentation and integration contracts

Explain why every integration should have a documented contract covering data formats, frequency, error handling expectations, SLAs, and ownership. Provide a lightweight template that teams can adopt without excessive bureaucracy.

A phased approach to integration maturity

Phase 1: Inventory and stabilise

Start by mapping what exists, identifying the most fragile integration points, and adding monitoring and error handling to critical flows.

Phase 2: Introduce a broker layer

Migrate the most critical integrations to a hub-and-spoke pattern with proper middleware, reducing point-to-point dependencies.

Phase 3: Standardise and scale

Establish integration standards, API guidelines, and governance processes that allow new systems to be connected predictably and safely.

Conclusion: Integration is a capability, not a project

Reinforce that integration strategy is not something you complete and move on from. It is an ongoing operational capability that needs investment, ownership, and continuous attention. Encourage readers to treat integration health as a leading indicator of overall technology programme health.

Next steps

If your integration landscape has become a source of operational risk or delivery bottleneck, get in touch to discuss a structured assessment.