Friday, January 20, 2006

Splitting up the ESB


Following up on an earlier post its worth going over the difference between a business service bus and an integration service bus. There are a whole different bunch of vendors out there selling "Enterprise" Service Bus products, in reality these are normally products aimed at creating services out of existing systems (Integration) or at providing accessibility and management to more business oriented services. The problem is that people are confusing the two areas, which is very dangerous if you want a successful project. Integration products are about adapters, transformation from multiple data format and generally trying to squeeze that damned external application into a shape that the rest of the world can use. These are about managing events to and from these systems, short life processes and a real concentration on shifting data, enrichment and all the trimmings.

The otherside of the story is the business side, this is about policy, management, control and business function. This is the XML centric part of the world, mediation and minimum transformation, versioning and of course enabling connection to be done in differing ways, to me this just means reliable v non-reliable and using queues v HTTP or email rather than trying to get it out of an ERP specific format or a database.

What isn't in ANY of this is business process, that is a different thing again, in fact business process is about BUILDING services, normally high level ones its true but services none the less. Business process is an application thing, not just a layer across the enterprise. As tools begin to enable more and more to be done its getting more and more important to be clear in your architecture what is done where, otherwise you end up having one almighty blob that you christen as you "SOA ESB" and two years later you curse as Project X which gives you no clarity as to what is being done where.

So basically don't buy one ESB to fit everywhere, make sure you think about the specific challenge you are facing and separate integration tasks from business service tasks, and keep business process out of both of them.

2 comments:

Anonymous said...

Hi Steve,
I was wondering where you see BPM fitting into this? With the emergence of BPEL, clearly there are a number of tools/platforms available for system-to-system process automation and mediation. It is tempting to want to augment these capilities to include additional BPM-like functionality such as human workflow, business rules, BAM, etc. Do you believe there is an architecture layer for these higher-level business process services that is distinct from other business or integration services? And if so, would this imply that it is acceptable, and often advisable, to use different tools/platforms for these services?

thanks,
JR

Anonymous said...

Hogwash!

Quote: "...these are normally products aimed at creating services out of existing systems.."
Rebuttal: Ha!

Quote: "Integration products are about adapters..."
Rebuttal: Ha!

Quote: "...business process is about BUILDING services..."
Rebuttal: Ha!

Quote: "Business process is an application thing..."
Rebuttal: Ha!