Hub Spoke And Rim

HubSpokeAndRim.jpg have a design and implementation process in a well-understood domain, and want to implement the principles of DeCoupleStages. The organization is mature and the process well-understood; it is fairly well optimized and has good partitioning in the spirit of DivideAndConquer. Mature development organizations have well-defined development stages — such as requirements acquisition, design, and coding.

✥ ✥ ✥

Some processes can almost be automated, but still require a degree of human intervention and coordination. This is particularly true for highly detailed processes.

For example, even if a process is mature enough to have well-delineated development phases, it may need additional mechanisms to integrate these stages and coordinate the interactions between them.

Process stages should be decoupled to reduce the communication associated with hand offs and promote independence between stages. Such independence creates opportunities for parallelism and increased throughput. Yet independence generally hampers information flow.


Link each role to a central role that orchestrates process activities, with the activities taking place serially. The hub plays a simple coordination and management function to ensure all steps are completed successfully, while the work is done in the rim. The "rim" carries the hand off and its associated information between roles. The "spokes" provide the link to the central coordinating agent, and are lighter links of communication than between the "rim" roles.

This organization, a front-end process for a large development project, exhibits HubSpokeAndRim:


The process supports sales and marketing activities and is highly responsive.

The hub role should be encouraged to avoid micro-managing, particularly with respect to the mechanisms individual rim roles use in achieving their tasks. The hub role should scrutinize deadlines and schedules and should be in close enough contact with the rim roles to facilitate hand offs from role to role if necessary, and to communicate the state changes to other parts of the project as necessary. In this sense, the hub role can also act as a natural FireWall for the rim roles.

✥ ✥ ✥

The rim roles still maintain a good modicum of autonomy; each can focus on its own domain-specific task. There need not be any essential domain coupling between the roles on the rim; the only coupling is with respect to sequencing. The hub can coordinate that coupling and can optimize it (juggle priorities, give different projects or customers different priority) to meet project priorities. The hub is a management role rather than a development role--a controller or sequencer. The hub role holds things together and ensures that progress ensues from state to state. Here, we want to ensure progress in the process; compare with the design pattern SomeoneAlwaysMakesProgress. HubSpokeAndRim is an implementation pattern that achieves the intent of SomeoneAlwaysMakesProgress in a limited context.

Prof. Aaron Gelman (Northwestern University) notes that in the contemporary airline market, the hub pattern contributes to congestion. Many airlines are acquiring small planes that can take small numbers of passengers directly between end destinations, acting as "hub busters" and relieving such congestion. The analog is a concern for over-application of this pattern. (WBBM Radio News, Chicago, IL, Sep. 30, 2000)

The organization must be wary of the central role becoming a bottleneck, and address such bottlenecks with other patterns (e.g., MoveResponsibilities).

This configuration has higher latency than a highly coupled process, but it is likely to be able to support higher throughput (see CouplingDecreasesLatency). However, it cannot easily support essentially creative processes that are common to design, coding, and testing. In the creative process of design, communication is more important than sequencing, since a repeatable sequence is unlikely to be found in such a creative process.

In a less mature domain, it is more appropriate to apply DeveloperControlsProcess as the alternative. Most domains in fact lack the maturity for HubSpokeAndRim to be appropriate.

Parallelism can be re-introduced if the central role pipelines activities become a bottleneck.