BPM and ESB: pick the right one

I recently noticed, in different enterprise architectures, an overlapping between BPM (Business Process Management) and ESB (Enterprise Service Bus) technologies.
Architects tend to use one or the other based on previous choices, company partnerships, costs, know-how, rather than real technical benefits or functional reasons.
It is becoming common to come across problems solved using BPM, where an ESB solution would have been more suitable and vice versa.

 I attended different ESB seminars (online and in person) and some of the most common questions have always been:

"Will BPM replace ESB in the near future? 
Do you see BPM and ESB working together in enterprise architectures? 
How do we pick one or the other?"

Let’s try to answer to those questions  discussing BPM and ESB separately.

BPM

Business Process Management assists business analysts in optimizing processes of the organizations.

They’re generally human centric long-lived processes, lasting days, weeks, months or even years, where a certain degree of human interaction is generally expected.

BPM solutions consist of process definition, execution and monitoring, and are generally orchestrated between different systems, people and processes.

BPM does provide connectivity between different systems, but doesn’t support a large number of protocols and data transformation formats

Example of human centric business processes may be HR, payroll  or low volume, high value e-commerce transactions.

In general, we can say that BPM should be used for human centric long lasting business  processes, not real time, where performances are not a key factor and  low latency time won’t affect the process execution.

 

ESB

Enterprise Service Bus (ESB) is optimized for high volume, low latency, system-to-system  real time communication, in the order of milliseconds or seconds.

ESB is also a flexible and scalable solution, which becomes very important when transactions‘ volume is significantly high.

ESB support many different transport protocols and data transformation formats.

In general, ESB should be used in high volume transaction scenarios, not human centric, where real time and low latency are key and the orchestration occurs between different systems that support different kind of protocols and data format.

BPM and ESB together

BPM and ESb are not only complimentary, but they can be used together; there are different scenario and case studies.

A very popular scenario would be an ESB kicking off different BPM processes, orchestrating them, collecting  the results and sending those results to different systems.

Another scenario, albeit less common, could be the other way around: BPM to orchestrate a main business process and ESB to handle the single tasks of communicating with different systems, managing transactions, availability, scalability and data transformation.

In conclusion, BPM and ESB are fit for different purposes, based on business scenario, transactions volume, performances, protocols and data format. But they are not only complimentary. They can be used together in different business cases.

Antonio