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.

Designing Interfaces and REST

I've blogged in the past about how the design of interfaces in distributed systems is an important, but often overlooked topic. Instead the current debate seems to be around the technology used - SOAP, REST - rather that the interface design itself.

I was therefore interested to come across this blog entry from Joe Gregorio in which he applies REST technology to the design of the Apache DayTrader benchmark. What I find striking about this entry is how much care he has given to the interface design, reducing the original, and somewhat ad-hoc interface specification, to simpler principles based on a few entities and operations.

Tools for Globally Distributed Development (GDD)

Working for a company that routinely spreads its development out through the world I was interested to come across this report from Ryan Bagueros on how a small software development company can set up the tool support for GDD on the cheap by using tools available on the web. As he says:

"With some careful setup, any group of developers can compete with the budgets used by multinational software development firms to distribute their application engineering ..."

Of course, these tools do not need to be used on the scale of global development, but can be used on smaller scale developments where the developers do not all sit together.

Using BPMN

As an architect I often have to sketch the processes to see how everything goes together. Over the last year I been increasingly using BPMN to do this, either on paper or with Visio. Unfortunately there doesn't seem to be much out there in the way of books which explain how BPMN should be used . Instead, I use a couple of tutorials written by Stephen White from IBM. Those with patience can use the textual version, for the impatient the slide show is the best.

As to sketching processes in Visio a number of stencils (with various levels of completeness and features) are available on the bpmn.org site.