Point-Point, Hub-and-Spoke, ESB

My colleague Mark Masterson asks in his blog about the “fitness of the classical "hub and spoke" architecture in a modern enterprise systems landscape” and “what, exactly, is the purpose of an enterprise service bus (ESB)?”

As he points out there is a lot written about this, but nothing seems to be conclusive. When confronted by such situations I attack them by asking “want do we really want” and then work backwards to “what have we got”.

So, the first question is; do we want a “hub and spoke” architecture? Well, this was proposed as an answer to the point-to-point interconnection style. Continuing on with this ruthless analysis (so beloved of Dr. House) let’s ask the seemingly dumb question; do we need a point to point interconnection style?

Point to point came about because people needed to transfer data between applications. As time went on, more and more applications were written and, with them, more and more point to point interconnections were produced. This lead to a nightmare IT landscape which nobody could understand, let alone maintain (I once did an application inventory for a client in which the interfaces were also documented – the result filled four sheets of DIN A0 and made for interesting wallpaper!).

To solve this the hub-and-spoke architecture was proposed, which lead to EAI tools etc. etc.. But that was then and this is now and I think we have to ask again: why point-to-point?

In the brave new world of SOA we don’t have applications which need to pass data between themselves. Instead we have autonomous services. These are arranged in a hierarchy (although not a strict one) . Services are consumed by other services (e.g. composite services call atomic services) or, at the top nodes, by service consumers such as user interfaces. If we start building systems to implement this architectural style, we soon start to realize that certain functionality is required time and time again. We need to implement small processes which call services in predefined sequences, data needs to be aggregated from many sources or needs to be distributed to other services. The data needs to be transformed, enriched, split up. In addition we need build low level coordination between the services, so that we can implement concepts such as transactions and security. We also need to ensure that data is really transfered to the services (i.e. reliable delivery) etc..

All of this is what we really need to implement an SOA. But instead of implementing this all ourselves, we buy these things from somebody who has packaged it all together and given it a name - ESB.

Using this analysis means that the original question of fitness of a hub-and-spoke system is a question that does not need to be answered as a hub-and-spoke architecture is irrelevant for a modern systems landscape if an SOA style is used.