What is Business Process Management (BPM)?

Business Process Management (or BPM) can simply be thought of as a system which automates business processes. Typically, a BPM system has a graphical interface which allows you to model your business processes visually so that a business analyst or other non-programmer can easily understand them and verify that they indeed reflect the reality of your business.


Business Process Management is often a fundamental building block of many business functions. BPM solutions primarily assist business analysts in modeling and optimizing the processes of their organization. These processes are often long-lived, lasting days or weeks from initiation to completion. While they may at times be fully automated, in many cases manual intervention from a business stakeholder is required.

The ultimate goal of a BPM solution is to improve the functioning of a human-centric business process. As an example, an employee onboarding process affecting multiple systems such as HR, payroll and building security could be managed by a BPM. Another example could be a low-volume, high-value e-commerce process where manual intervention is often required to approve the completion of a transaction. The strength of a BPM solution lies in its ability to orchestrate between different systems, people and processes to improve the overall function of human-centric business activities. BPM solutions focus on process definition, execution and monitoring. In this context, BPM solutions are generally optimized for long running business processes that include manual processing steps.


Business Process Management

We often get the question: Should this integration problem be solved using an integration solution (like Mule as an ESB) or a BPM solution? There is no unique or simple answer to that question, because it depends on the use case. But in every enterprise there is definitely a place for integration solutions and a place for BPM and they can and should leverage each other. At a high level, an ESB and BPM are separate but interdependent. In other words, ESBs solve the problem of complex system integration (usually stateless, short-lived transactions), while BPM solves the problem of modeling and orchestrating business processes, integrating people and systems (usually stateful, long-running transactions).

It all comes back to the principles behind SOA. Think of SOA as a 3 layer architecture, the lowest being “service-enablement” or exposing existing systems as services, the middle being “service orchestration” allowing to create and compose coarse-grained “business services”, and the highest being “process orchestration” to create business processes.

Normally an ESB is assigned to the middle layer — orchestrating low-level services into larger service units, which will be exposed to the business for use in processes — and BPMs in the top layer. Mule not only provides value on the middle layer, but it is also a container for components and services, providing “service-enablement” therefore adding value on the bottom layer as well. The question you have to ask yourself is not when to use one or the other, but rather why or how to make them work together. In other words, to be successful with business processes you first need to have all your systems and apps exposed as services, which you can do with Anypoint Platform. However, the other way around is an important use case too. Many of our customers are using Mule as an ESB to expose a process as a service or to kick off a process instance.

How an integration solution can complement BPM

An Enterprise Service Bus (ESB) is optimized for high volume, low latency, system-to-system ‘real-time’ communication in timeframes spanning fractions of a second to a few minutes. When compared to BPM, an ESB will provide superior performance under high load or high performance requirements and architectural flexibility as a result of the breadth of its system connectivity options.

ESB architectures, like Mule as an ESB, are flexible and scalable due to their ability to support many communication transports and data transformation formats. These ‘–ilities’ become increasingly important traits as systems grow and become more complex over time.

In many cases, BPM and ESB systems co-exist and work collectively to solve business problems. In a complex e-commerce application, for example, both ESB and BPM may be required as connectivity is needed to various web services, ERP applications, CRM systems, and billing systems. Some of these may be packaged software applications while others may be custom built. Many may sit within the enterprise while others may be delivered in a software as a service (SaaS) model. While a BPM solution typically offers limited connectivity to many of these applications an ESB can provide integration to all necessary systems, simplifying the overall integration project.

In a scenario such as this, transaction volumes can be quite high. An ESB is better tuned to handle these high volumes of transactions than a BPM solution. Most transactions typically can be processed with little or no human interaction. A web app
can take a credit card number, check the number, process the financial transaction and then send the order to fulfillment. However, this does not mean BPM is not also useful in these scenarios. If orders require complex invoicing, credit checking, auditing, or other special attention, human interaction may be required. In these cases the ESB can process steps of the transaction then integrate with a BPM solution for those steps that require a unique business process.

ESB and BPM are also complementary in media and content delivery applications. In a real world example, a large media firm relied on Cordys BPM for their content publishing, approval, and syndication needs. However, as transaction volumes increased and the media business transformed from a primarily print and television environment to one involving multiple delivery vehicles, the system struggled to keep up with the large amount of metadata surrounding media files passed through the BPM solution. The firm also struggled to keep up with new delivery channels with new APIs such as mobile distribution that became increasingly critical to their business. In direct response to these challenges, the firm adopted Mule as an ESB as an integration foundation for their BPM solution, managing connectivity and automating more routine tasks. Utilizing this architecture, they increased their system performance significantly.

Best practices in selecting BPMs and ESBs

As discussed, BPM and ESB have different strengths. Consequently, the challenge becomes accurately determining system requirements and allocating the correct division of responsibilities within your chosen architecture. It is a common mistake that organizations choose either an ESB or a BPM solution without fully considering the nature of the problem they are trying to solve. While use cases vary, a good rule of thumb when selecting whether to utilize a BPM or an ESB solution is as follows:

  1. BPM (only) Use Case

    If the use case in question involves very low transaction volumes, low performance requirements, and a high degree of human interaction in the business process and the system requirements are simple and not likely to change much over time, a BPM ‘only’ solution can be an appropriate choice.

  2. ESB (only) Use Case

    If the use case in question involves medium to high transaction volumes and architectural flexibility and scalability are also important due to the size or complexity of the implementation, then an ESB ‘only’ solution is the most appropriate choice.

  3. BPM and ESB Use Case (together)

    If the use case in question involves medium to high transaction volumes, architectural flexibility and scalability is required, and a substantial portion of these transactions will involve human interaction in the business process, a combined BPM and ESB solution should be applied. In this case the BPM is responsible for the business process and human workflow interactions and executes on a high performing, flexible, scalable ESB as a complement to BPM.

Anypoint Platform, MuleSoft’s unified integration solution, is especially well suited to integrate with BPM solutions. MuleSoft provides industry leading performance that augments the weaknesses of a BPM solution. It also provides the widest range of connectivity for both on-premise applications and cloud services. Finally, Anypoint Platform is-a-best of breed solution. Unlike some vendors who try to tightly couple their BPM and ESB solutions in a way that impedes architectural flexibility and require additional products, Anypoint Platform can natively integrate with most in-market BPM products easily, robustly and with minimum time investment and cost.

Take a look at more resources on Business Process Integration and how Anypoint Platform can help your organization implement BPM solutions quickly and easily.