The Unexpected Hostility Towards Hub-and-Spoke Integration Design Patterns

Written by Cameron Majidi, Solutions Architect, Prolifics

6 min. read

Introduction

With over 20 years of experience as an application integration specialist, I have had the privilege of working with various generations of integration middleware technologies, primarily those developed by IBM. Throughout my career, I have successfully navigated diverse industries, serving companies ranging from small-scale enterprises to global giants. Beyond the specific technology and project requirements, one architectural approach that I have consistently advocated is the hub-and-spoke model. Its versatility and effectiveness have proven valuable in achieving seamless integration across systems and maximizing operational efficiency.

Some people prefer the term “hub and spokes” over “hub and spoke” (with or without the hyphens). I don’t have strong feelings about it one way or the other, but that’s not what I want to talk about.

I want to address the remarkable aversion towards the hub-and-spoke approach. Throughout my extensive experience collaborating with a wide range of companies and industries, I have come across a perplexing trend: a notable number of individuals harbor a deep disdain for the hub-and-spoke approach. In this discourse, I aim to delve into the underlying causes behind this sentiment. While avoiding specific anecdotes, I will maintain a broad ‘10,000-foot’ perspective, investigating why people develop such a visceral aversion to this concept or, as I will elaborate later, to a particular facet of it.

Additionally, I’m going to speak about message exchange. This is once again a 10,000 foot approach, I don’t want to talk about specific technologies. Everything I say applies, mutatis mutandis, to integration patterns involving exposing enterprise services. Don’t be thrown off by the messaging terminology.

First, some basics on the hub-and-spoke model

In enterprise-scale systems integration, the hub-and-spoke model operates on a simple concept: applications serve as spokes while the integration middleware functions as a neutral hub. This middleware efficiently routes messages to their intended destinations, allowing the spoke systems (or nodes) to remain oblivious to the specific systems involved in message transmission. Regardless of the origin or recipient of messages, the hub-and-spoke approach ensures seamless communication among interconnected systems.

Comparing Integration Design Approaches: Hub-and-Spoke, Point-to-Point, and Sun-and-Planets

This hub and spoke approach can be contrasted with two other enterprise integration design approaches: 1) the point-to-point approach, and 2) what I call the “sun and planets” approach.

Point-to Point: In a point-to-point design every node communicates directly with every other node. This doesn’t mean that enterprise middleware is bypassed. You can use enterprise middleware to build point-to-point channels.

Sun and Planets: What I call the “sun and planets” approach is a variation on the hub-and-spoke approach. Unlike the traditional model where a neutral middleware platform acts as the hub, the “sun and planets” approach designates one application system as a super node, assuming the pivotal role of the central system that the entire enterprise revolves around. While hub-and-spoke has been historically championed by IBM and other middleware vendors, it is worth noting that a prominent enterprise software vendor has embraced the distinctive “sun and planets” perspective.

The Hub-and-Spoke Model: Unveiling the Hostility and the Data Representation Dilemma

In my encounters, I have discovered that the hostility directed towards the hub-and-spoke model is not aimed at the fundamental communication pattern itself. The basic concept is widely understood and accepted, as it offers clear advantages over the point-to-point approach when dealing with more than two nodes in a system. The hostility I’ve encountered emerges when proposing the extension of the hub-and-spoke model to encompass the data representations traversing the system.

You can build a system where the integration hub receives a message from one system, determines which other systems the message should be routed to, maps the data into whatever formats are needed by the respective target systems and sends the messages to those targets. In such a solution, each system sends messages only via the hub. Each system is communicating with the hub via its preferred protocol, and each system is using whatever data format it finds congenial. At the level of communications, this is a hub-and-spoke design.

But inside the solution, in the implementation on the middleware itself, there is still a point-to-point design lurking. Each message is being translated from a spoke-style message format directly to another spoke-style message format. The integration hub would theoretically need to know how to map from any node’s preferred data representation of any particular enterprise object to every other node’s preferred representation.

To fully embrace the hub-and-spoke approach, it is recommended to initially translate each received message into a neutral, hub-specific format before converting it into the node-specific formats needed for the given scenario.

However, here is where the objections arise.

Why do they object?

They argue that it’s inefficient. Instead of a single middleware component handling the mapping and routing, there are typically multiple components involved. One component receives the message and converts it to the hub-specific format, another component routes the message to relevant target systems, and additional components perform mapping to node-specific formats and deliver the message to each target system. Furthermore, each interaction requires two data mappings per target system, doubling the complexity.

The inefficiency observed here bears resemblance to the inefficiency found in classic examples of hub-and-spoke architectures in transportation systems. When discussing the hub-and-spoke approach, it’s common to refer to the pioneering hub-and-spoke models introduced by Delta Airlines and Federal Express in the 1970s.

The example of FedEx is particularly illustrative. Passengers always prefer a direct flight. In delivering a particular package, a direct route is always going to be quickest. But from the system’s perspective, the efficiencies of a hub-and-spoke approach make the most sense. Maintaining numerous point-to-point routes proves more costly than establishing a central hub and routing almost all the traffic through it.

Another objection raised is the perceived effort involved in establishing hub-specific data representations for every enterprise business object traversing the network, which is akin to constructing an enterprise data model. While this objection holds some validity, building the enterprise data model doesn’t necessarily need to be a prerequisite. By adopting a strategic approach, the hub-specific data formats, as a collective, can gradually evolve to resemble a comprehensive enterprise data model over time. It does not have to be an immediate requirement to launch the integration hub. Rather, the development of an enterprise data model can be an ongoing process that unfolds as the system matures and more interactions occur throughout the enterprise, ensuring it is not viewed as a sunk cost but as an organic evolution.

Despite outlining the parallel efficiencies observed in both communication channels and data mappings as the system scales with increased nodes, and the flexibility of not immediately embarking on the endeavor of constructing an enterprise data model, these explanations may not always succeed in addressing objections raised against extending the hub-and-spoke approach to data models. Surprisingly, some individuals hold a deep aversion towards this extension of the hub-and-spoke design.

Which people? In my role as an integration specialist, I often collaborate with various stakeholders such as enterprise architects, network administrators, and technical leads responsible for maintaining the enterprise systems that act as the spokes in the integration solution. Interestingly, it is within this group of application technical team leads that I frequently encounter a strong aversion towards extending the hub-and-spoke design to the data level.

Why is this? In theory, one would expect the application technical team leads to embrace the idea of communicating solely with the integration hub instead of multiple systems. Transitioning to an integration hub often entails replacing existing batch-style point-to-point data exchanges. While the individuals responsible for maintaining the individual systems might express some reluctance in retiring their meticulously crafted code, they should ultimately appreciate the prospect of no longer having to maintain those mechanisms.

Unveiling the Source of Resentment: The Intricate Dynamics of the Hub-and-Spoke Model

Although they rarely articulate their objections, I have developed my own suspicions over the years regarding why they harbor such strong resentment towards the hub-and-spoke approach. In addition to the anticipated benefits in terms of communication channels and data mapping efficiencies, the hub-and-spoke architecture also reduces dependencies within the entire enterprise on specific systems. Theoretically, if all communication occurs through the hub and all data exchanges utilize neutral hub-specific formats, the replacement of a single system should have minimal impact on other systems. Only the integration hub would need to be updated to accommodate the introduction of a new system that directly replaces an old one.

If the data mappings within the integration hub remain point-to-point, each application team lead may perceive their system as exceptional. They may envision their system as the central figure in a sun-and-planets integration architecture, with the middleware platform playing a subordinate role as a mere communications infrastructure. Once they realize that the middleware treats all data structures equally without favoring any specific system, they may suspect that the enterprise architects have ulterior motives to make every system replaceable, including their own. This unexplained hostility I have encountered towards extending the hub-and-spoke approach to encompass the data models likely stems from this underlying suspicion.

Cameron has been with Prolifics since 1996, initially serving as a key member of the technical management team responsible for overseeing software development and marketing. As the new millennium began, he transitioned to the role of a solution architect specializing in application integration. Throughout his career, Cameron has played a pivotal role as the lead architect on numerous projects, implementing integration middleware for companies of varying sizes. His expertise extends to solution design, having collaborated with organizations that possessed well-established middleware-based integration strategies. With his extensive experience, Cameron brings a wealth of knowledge and insight to every project he undertakes.