You may have been reading a lot about Business Process Management. What is it? BPM is a discipline that focuses on process modeling, design, automation, management, and continuous improvement. It is not a technology or a product. It covers the full range of application-to-application, inter-application, workflow, and person-to-person process management, including process modeling, design, automation, monitoring, management, and continuous improvement. The core and basic components of BPM include (but are not limited to):

Businesses very well understand that their core (and differentiating) business processes will have to be automated (post integration) and be able to externalize these from end applications. Process-driven integration is about bringing people, processes, information, and systems together using the Business Process management (BPM) approach enabled by an SOA approach. This approach requires a solid technology platform and of course an over-arching methodology that will offer you prescriptive guidance on how to deliver solutions. So what are these core building blocks? They include:

Now let's look briefly at each of these core building blocks/capabilities that are needed for achieving success in a business process-driven integration provided, as shown in the following figure:

This is the starting point where you discover and document the various other business process(s) (using a modeling notation such as Business Process Modeling Notation BPMN) that might exist on paper or even in the minds of some subject matter experts and document it with business modeling. Also, once the processes are modeled, you will have the ability to run model simulations and try out various 'what-if' scenarios to forecast what would happen if you altered the process. Based on these simulations, you arrive at an optimal process design. The process modeling exercise also helps to identify the SOA services that will have to be specified, realized, and also in many cases, reused.

Once the business processes have been modeled, they will have defined in an executable format (such as Business Process Execution Language (BPEL)) and deployed on a standard-based process execution platform that supports both the business process execution environment and the packaging of business tasks as services. The assembly, sequencing, orchestration, and choreography of existing services and new services results in the realization of a deployable process model. This assembly should be based on industry standards such as Service Component Architecture (SCA). The execution platform must also support human interaction for both participants in the business process and administrators of the business process. The runtime should also provide a variety of administrative capabilities required to configure the environment for the applications that are installed.

Enterprise Service Bus (ESB) provides the underlying connectivity and backbone infrastructure for SOA to connect applications. An ESB is essentially an architecture pattern that provides capabilities including connectivity, communications, message queuing, message routing, message transformation, reliable messaging, protocol transformation and binding, event handling, fault handling, message level security, and so on. It enables loose coupling between service consumers and service providers, and thus enhances the ability to rapidly change and introduce new Business Services into the environment. An ESB typically would leverage a service registry and repository to provide information about service endpoints.

Policies and rules can make the business processes highly flexible and responsive. A business policy represents a key piece of domain knowledge, externalized from a business process and is applied when a particular request context is met. An example could be, all purchase orders that include order items such as Oxygen Canisters are deemed critical orders, order amount worth over $1000 has to be shipped overnight, and so on. Metadata elements such as "order item" and "order amount" are deemed as the business domain vocabulary and values of which can change (you can add "Defibrillator" along to the critical items list), which will have to be externalized from the business process.

A business rule is a statement that defines or constrains some aspect of the business. They are typically atomic and cannot be broken down further. An example would be, say, in a loan origination business process, at each step of the process, business analysts identify rules that must be met by the loan staff and underlying systems. In traditional banking systems, these rules reside within the loan origination system itself, so changing the rules means modifying the application. When the rules are abstracted from the loan origination systems, they reside in a business rules engine. As a result, bank management can identify those activities that change rapidly, such as decisions relating to FICO® scores, and then, instead of changing the process and its underlying application, they change only the decision point within the business process, which in turn resides in a business rules engine (external to the process itself). This capability adds agility to the process by reducing the time, costs, and resources necessary to respond to changing conditions.

While the business processes are deployed and are executing, data must be captured that provides information about the processes. This data can be analyzed to determine if the business processes are performing as expected. Both business-related information and IT-related information can be captured for monitoring. You should also be able to visually define dashboards based on Key Performance Indicators (KPI), which are based on the monitor model deployed for the business process, providing a visual display of the business process status.

For a process-driven integration approach coupled with SOA to succeed, a common and enterprise level information model is required, which becomes the basis for the messages exchanged between processes and services, and also serves as the glossary for the business policies and rules. When dealing with applications that have disparate data and information models, use of this common information model shields the business processes away from the gory details of each and every individual system. The ESB provides capabilities to transform from this Canonical Data Model to the target system's format. The Canonical data model minimizes dependencies between integrated applications that use different data formats. Typically, one could leverage industry standards such as Tele Management Forum's Shared Information/Data Model (SID) and so on to define the information models.

A mind map, as shown in the following figure, sums up all the previous concepts.