Business Process Model and Notation (BPMN) is the widely accepted standard for business process modeling and provides a graphical notation for specifying business processes in a Business Process Diagram (BPD). It is based on a flowcharting technique very similar to the activity diagrams of Unified Modeling Language (UML). BPMN is maintained by Object Management Group (OMG), and the current version is 2.0 (released in March 2011).
The primary goal of BPMN is to provide a standard notation readily understandable by business stakeholders. These include business analysts who create and refine the processes, technical developers responsible for implementing these processes, and operation managers who monitor and manage the processes. Consequently, BPMN serves as a common language, bridging the communication gap that frequently occurs between business process design and implementation. BPMN also serves as a communication medium between organizations who partner for achieving common business goals, to share functional processes and procedures.
One of the main differences between BPMN and other process definition standards such as Business Process Execution Language (BPEL) is that BPMN supports human interaction. Human interaction support provides completeness to business process modeling, as humans are the primary actors in any business organization. Being a specification of visual programming notations, BPMN places considerable emphasis on diagrammatic representations of the elements of the business process model. So, a reader of a BPMN diagram can easily recognize the basic type of elements and understand the business process. BPMN conformance ensures a common visual representation, although it allows variations without dramatically changing the basic look and feel of the diagram.
The detailed explanation of the BPMN 2.0 specification can be found in the specification document.
BPMN specification documents can be found at http://www.bpmn.org/.
Conformance to standard BPMN specification defines four types of conformance:
Choreography modeling conformance: Tools claiming conformance must support choreography diagrams and their elements. Choreography diagrams focus on the collaboration of different groups in activities and the message flow between them.
A jBPM implementation partially claims the first two types of conformance, namely process modeling conformance and process execution conformance. Although jBPM supports all core elements in process modeling, it does not support all the elements described in the specification.
Events: An event is something that happens in the course of a business process. These events affect the flow of the model and usually have a trigger for and an impact on the business process. Some examples of events are Start, Stop, and Error. A Start event triggers the start of a process instance and is triggered using an explicit trigger, a message, or a timer. Events can be either signaled from a process (thrown) or can be waited upon (catch).
Activities: Activities are actions performed within a business process. They can be either atomic (called Tasks) or compound (Sub-processes). An example of an activity is a user task or a service task. A user task indicates a human interaction and the action has to be taken manually to complete this task. A task can be complete upon being triggered or can wait for completion (a wait state); for example, a service task is triggered and completed, while a human task is triggered and waited upon for a user to complete the action.
Gateways: Gateways are used as controllers for the branching, merging, forking, and joining of execution paths within a business process. An example is the parallel gateway, which can be used to split the execution path into multiple outgoing branches, with all outgoing branches activated simultaneously. Parallel gateways can also be used to merge branches; they wait for the completion of all incoming branches to complete before triggering the outgoing flow.
Business process execution results in the production of data; for example, in the banking transaction process, the transaction details are data provided by the user regarding the transaction. This data would have to be saved or transferred to another activity for further processing. The following elements are the core of data modeling in BPMN.
Data Input: Data inputs specify the input needed for an activity for its completion. For example, an OTP sending task in the banking transaction process would need the details of the customer to send the SMS. So, the input of this activity is mapped from the output of the previous activity or from data that is globally associated with the process instance.
Swimlanes are a visual mechanism for organizing and categorizing activities and form the basis of cross-functional charts using BPMN. They represent an organization, a role or, a system. They are basically of the following two types:
Pools: A pool represents the higher-level categorization of activities. For example, an organization can be represented as a pool. A pool consists of multiple lanes. An example of lanes would be the departments within an organization.
Artifacts are graphical representations that provide supporting information about the process or elements within the process. They don't interfere with the process flow; in other words, we can say that they are opaque from the perspective of process execution. The basic types of artifacts stated in the BPMN specification are as follows:
The banking transaction process is illustrated in the following diagram with the core elements of event, activity, data object, lane, and gateway annotated: