Understand your organization before you architect your SOA

John Radko of GXS had an interesting blog entry about SOA versus ESB - Conflict or Collaboration where he talks about whether ESB and SOA should always be put together.  Since SOA is an architecture but an ESB is a product, deciding whether your architecture should depend on a specific product is an important question to ask yourself.

The interesting thing about this question is that answering it has little to do with technology.  In fact, the right approach has to do with the existing power structure of your organization (whether "organization" for you means project, division, or even enterprise).

In a world where one IT group (in reality, not in theory) can dictate the technology standards for the entire organization, choosing a specific product -- an ESB -- as a core SOA infrastructure for the organization makes sense. In this environment the IT group has power to dictate the standard that everyone else must use, and you can easily deploy a single technology everywhere - across the enterprise. Asymmetrical organizational power leads to a symmetric technology deployment.

On the other hand, if you work in a world where different groups within the organization are equally powerful (or are even more powerful than the central IT group), then you'll naturally end up with a model where each group chooses their own infrastructure - regardless of what "central IT" believes is best.  Symmetric organizational power leads to asymmetric technology deployment.

Of course, in a world of equal organizational power, two groups can work together to form an agreement.  That agreement typically codifies, among other things, a set of common policies and standards by which the groups will communicate.  This is one of the ways SOA management products are deployed -- to codify these policies and to act as a "gateway" between the groups (decouping each group from the technology choices of the others).

Of course, no enterprise has just one level in the organization.  Within one division, decisions may be centralized (i.e. there's asymmetric power within the division -- someone can dictate the rules), which means that use of an ESB within that division makes a lot of sense.  However, across divisions power may be symmetric (with on one division being able to dicate what another does).  In this case you would think of deploying SOA management at the boundaries between divisions to decouple them from one another.  So, in this example, you have a mix of both approaches - perhaps an ESB within the divisions and SOA management at the boundaries across divisions.

SOA What?  In your organization, is power is distributed symmetrically or asymmetrically?  Remember to ask and answer this question before you decide on your SOA architecture -- SOA won't be able to change the balance of power within your organization, but its success depends on understanding where the power lies.