Enterprise Service Bus vs BPM

Question

Both ESB and BPM tools that I have worked on take in some input , call multiple steps to fulfill a task. The difference that I have seen is that in ESB everything is automated - the process is automatically triggered and involves a number of external calls / data is transformed and sent to appropriate system for consumption. In case of BPM system , the process is either started manually or automatically and it involved series of decision steps some of which involve manual decision steps.Once the steps are done , the task is marked as complete. Is it possible to explain the clear distinction between BPM and ESB?

Answer 1

I think you are right that anything achievable with a BPM can be achieved just fine with an ESB and some Web UI that enables invocation of manual steps. But this is true if you are only looking strictly from the technical point of view. In a more mature SOA, where a lot of different parties and roles are involved, both ESB and BPM have their distinct place.

The distinction you're looking for is more "fuzzy" and it is about the focus of these tools, their intended end-users and the type of logic they compose. Here is my humble attempt at explaining the difference between ESB and BPM:

Focus and goals

• ESB is more focused on enablement of interoperability, separation of concerns, and abstraction of technical details. It has much more of an infrastructural role, it also cares about monitoring, scalability performance, availability, state deferral. In the ESB your goal is to enable the creation of a federated interoperable layer, by abstracting all technical details and to exposing reusable functionality.

• BPM is more business-focused and in a perfect world scenario it is managed by business people and business analysts themselves that modify processes without having any idea about any technical details. The BPMN language is all about workflows and is designed to be business-friendly. In the BPM your goal is to implement real business processes by using these building blocks.

Intended users

• ESB services will be governed by architects and custodians (still, in accordance to requirements by business analysts).

• BPM workflows will ideally be managed and modified by business people, business analysts and the like.

Composed logic

• In a BPM the compositions (workflows) consist of business-oriented tasks (e.g. check customer loyalty level and give him a discount if user X approves and his level is gold).

• In the ESB the compositions generally consist of more technical services (e.g. retrieve this from the database, combine with that from this component, transform with xslt). It is possible to have an orchestrated task that implements an entire workflow the way a BPM does, that is entirely business-centric and without any reusability whatsoever, but you don't have the handy tools and visualisation to be able to easily delegate the management of this business logic to business people.

Having said all the above, ideally if you have a mature SOA, you'll have a BPM layer on top of one or multiple ESBs and corresponding Service Inventories that have:

• Entity and Utility services on the bottom (implemented in the ESBs)
• Task, and in some cases Orchestrated Task services that compose said entity and utility services (implemented in the ESBs)
• Workflows that use and reuse all these services in the BPM layer on top of the ESBs.

I hope this gave you a good initial idea of the differences. Feel free to ask if you need more information.

Answer 2

Plamen's answer is already very good. I disagree with the introduction

anything achievable with a BPM can be achieved just fine with an ESB and some Web UI that enables invocation of manual steps

His later explanation puts this into perspective though.

From the top of my head some aspects a modern Business Process Management Suite (BPMS) handles (better) in comparison to an ESB:

• Graphical modelling of the business process suitable for domain experts
• No technical detail required, e.g. without service composition
• the right granularity is reached when the task performer can be specific automated (system) vs manual (Human, possibly with system support).Below this granularity level the service composition start (ESB)
• Simulation of the workflow (without or without services connectivity), based on assumptions or real-life audit data
• Dashboard and Reporting features for operational control, tactical analysis and strategic continuous process improvement (all on business level / KPIs)
• Organizational modeling, management of authorizations
• task routing and assignment based on the business process model (e.g. roles) or dynamic based on conditions, business rules, decision tables, real-time analysis of user skills, workload and capacities, etc.
• Management of the context of the business process, e.g. business objects, documents,references to data in external systems, references to other workflows belonging to the same business entity
• Keeping an Audit Trail of all activities on business level (not a log file)
• Comprehensive worklist management and search features
• Features to operational management like definition and monitoring of business SLAs, priorities, benchmarks, criticalities, automated or manual task delegation
• Organizational aspect like deputy management, business calendar
• initiation of or changes to existing workflows based on defined internal or external technical or business events

BPMS and ESBs are complementary systems. The BPMS is the business layer which orchestrates the composite business services defined in the underlying ESB layer. The ESB layer is a technical mitigation layer which supports the definition of basics services, their aggregation into composite services and other aspects like transformation and standardization of data formats. Since the layers are close the products in both areas have adopted more and more features from the the other layer. The overlaps are increasing as the vendors extend their feature sets.

Depending on the complexity of the system landscape a comprehensive BPMS which covers many ESB features can make an ESB obsolete. An ESB which extends into the business layer is unlikely to reach the feature set and ease of use required by business users. If an ESB reached this business level then it would likely be rebranded and offered as a BPMS.

If you compare the website of ESB's like Mule and BPMS like Eclipse Stardust then the different focus (technical integration platform vs business process management: modeling, simulation, execution, reporting, analysis & improvement) should become evident.