Introduction

The Business Process Management Initiative (BPMI) has developed a standard Business Process Modeling Notation (BPMN). The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.

Another goal, but no less important, is to ensure that XML languages designed for the execution of business processes, such as BPEL4WS (Business Process Execution Language for Web Services), can be visualized with a business-oriented notation.

This specification defines the notation and semantics of a Business Process Diagram (BPD) and represents the amalgamation of best practices within the business modeling community. The intent of BPMN is to standardize a business process modeling notation in the face of many different modeling notations and viewpoints. In doing so, BPMN will provide a simple means of communicating process information to other business users, process implementers, customers, and suppliers.

The membership of the BPMI Notation Working Group has brought forth expertise and experience with many existing notations and has sought to consolidate the best ideas from these divergent notations into a single standard notation. Examples of other notations or methodologies that were reviewed are UML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains (EPCs).

The BPMN specification defines the Business Process Diagram modeling objects, their semantics, their mapping to BPEL4WS, and is comprised of the following topics:

Introduction and See BPMN Overview. provides an introduction to BPMN, its requirements, and discusses the range of modeling purposes that BPMN can convey.

See Business Process Diagrams. provides a summary of the BPMN graphical elements and their relationships.

See Business Process Diagram Graphical Objects. details the graphical representation, attributes, and semantics of the behavior of BPMN Diagram elements.

See Business Process Diagram Connecting Objects. defines the graphical objects used to connect two objects together (i.e., the connecting lines of the Diagram) and how flow progresses through a Process (i.e., through a straight sequence or through the creation of parallel or alternative paths).

See Mapping to BPEL4WS. provides the formal mechanism for converting a Business Process to a BPEL4WS document.

See BPMN by Example. provides a walkthrough of a sample Process using BPMN and its particular mapping to BPEL4WS.

See References. provides a list of normative and non-normative references.

See Open Issues. provides a list of issues that will affect the future of the BPMN specification.

See Appendix A: E-Mail Voting Process BPEL4WS. provides a full sample of BPEL4WS code based on the example business process described in the "BPMN by Example" section.

See Appendix B: BPMN Element Attributes and Types. provides the complete set of BPMN Element attributes, which are first presented in Sections 3, 4, and 5, and the definition of types that support the attributes.

See Appendix C: Glossary. presents an alphabetical index of terms that are relevant to practitioners of BPMN.

Conventions

The section introduces the conventions used in this document. This includes (text) notational conventions and notations for schema components. Also included are designated namespace definitions.

Typographical and Linguistic Conventions and Style

This specification incorporates the following conventions:

  • The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "MUST NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.
  • A term is a word or phrase that has a special meaning. When a term is defined, the term name is highlighted in bold typeface.
  • A reference to another definition, section, or specification is highlighted with underlined typeface and provides a link to the relevant location in this specification.
  • A reference to an element, attribute, or BPMN construct is highlighted with a capitalized word (e.g., Sub-Process).
  • A reference to a BPEL4WS element, attribute, or construct is highlighted with an italic lower-case word, usually preceded by the word "BPEL4WS" (e.g., BPEL4WS pick).
  • Non-normative examples are set of in boxes and accompanied by a brief explanation.
  • XML and pseudo text is highlighted with mono-spaced typeface. Different font colors may be used to highlight the different components of the XML code.

 

 

Dependency on Other Specifications

The BPMN specification supports for the following specifications is a normative part of the BPMN specification: BPEL4WS.

The following abbreviations may be used throughout this document:

This abbreviation Refers to

BPEL4WS Business Process Execution Language for Web Services (see BPEL4WS). This abbreviation refers specifically to version 1.1 of the specification, but is intended to support future versions of the BPEL4WS specification.

WSDL Web Service Description Language (see WSDL). This abbreviation refers specifically to the W3C Technical Note, 15 March 2001, but is intended to support future versions of the WSDL specification.

Conformance

A BPMN implementation is responsible to perform one or more duties, as outlined below, based on the information contained in this specification.

There are four main aspects of conformance to the BPMN Specification:

 

A conformant implementation is not required to process any non-normative extension elements or attributes, or any BPMN document that contains them.

BPMN Overview

There has been much activity in the past two or three years in developing web service-based XML execution languages for Business Process Management (BPM) systems. Languages such as BPEL4WS provide a formal mechanism for the definition of business processes. The key element of such languages is that they are optimized for the operation and inter-operation of BPM Systems. The optimization of these languages for software operations renders them less suited for direct use by humans to design, manage, and monitor business processes. BPEL4WS has both graph and block structures and utilizes the principles of formal mathematical models, such as pi-calculus1. This technical underpinning provides the foundation for business process execution to handle the complex nature of both internal and B2B interactions and take advantage of the benefits of Web services. Given the nature of BPEL4WS, a complex business process could be organized in a potentially complex, disjointed, and unintuitive format that is handled very well by a software system (or a computer programmer), but would be hard to understand by the business analysts and managers tasked to develop, manage, and monitor the process. Thus, there is a human level of "inter-operability" or "portability" that is not addressed by these web service-based XML execution languages.

Business people are very comfortable with visualizing business processes in a flow-chart format. There are thousands of business analysts studying the way companies work and defining business processes with simple flow charts. This creates a technical gap between the format of the initial design of business processes and the format of the languages, such as BPEL4WS, that will execute these business processes. This gap needs to be bridged with a formal mechanism that maps the appropriate visualization of the business processes (a notation) to the appropriate execution format (a BPM execution language) for these business processes.

Inter-operation of business processes at the human level, rather than the software engine level, can be solved with standardization of the Business Process Modeling Notation (BPMN). BPMN provides a Business Process Diagram (BPD), which is a Diagram designed for use by the people who design and manage business processes. BPMN also provides a formal mapping to an execution language of BPM Systems (BPEL4WS). Thus, BPMN would provide a standard visualization mechanism for business processes defined in an execution optimized business process language.

BPMN will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Currently, there are scores of process modeling tools and methodologies. Given that individuals will move from one company to another and that companies will merge and diverge, it is likely that business analysts are required to understand multiple representations of business processes--potentially different representations of the same process as it moves through its lifecycle of development, implementation, execution, monitoring, and analysis. Therefore, a standard graphical notation will facilitate the understanding of the performance collaborations and business transactions within and between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly. To do this, BPMN will follow the tradition of flowcharting notations for readability; yet still provide a mapping to the executable constructs. BPMI is using the experience of the business process notations that have preceded BPMN to create the next generation notation that combines readability, flexibility, and expandability.

BPMN will also advance the capabilities of traditional business process notations by inherently handling B2B business process concepts, such as public and private processes and choreographies, as well as advanced modeling concepts, such as exception handling, transactions, and compensation.

BPMN Scope

BPMN will be constrained to support only the concepts of modeling that are applicable to business processes. This means that other types of modeling done by organizations for business purposes will be out of scope for BPMN. For example, the modeling of the following will not be a part of BPMN:

  • Organizational structures and Resources
  • Functional breakdowns
  • Data and information models
  • Strategy
  • Business Rules

 

Since these types of high-level modeling either directly or indirectly affects business processes, the relationships between BPMN and other high-level business modeling will be defined more formally as BPMN and other specifications are advanced.

In addition, while BPMN will show the flow of data (messages), and the association of data Artifacts to activities, it is not a data flow Diagram.

Uses of BPMN

Business process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover many types of modeling and allows the creation of end-to-end business processes. The structural elements of BPMN will allow the viewer to be able to easily differentiate between sections of a BPMN Diagram.

There are three basic types of sub-models within an end-to-end BPMN model:

 

Note: The terminology used to describe the different types of processes has not been standardized. Definitions of these terms are in flux. There is work being done in the World Wide Web Consortium (W3C) and in the Organization for the Advancement of Structured Information Standards (OASIS) that will hopefully consolidate these terms.

Some BPMN specification terms regarding the use of Swimlanes (e.g., Pools and Lanes) are used in the descriptions below. See Swimlanes (Pools and Lanes). for more details on how these elements are used in a BPD.

Private (Internal) Business Processes

Private business processes are those internal to a specific organization and are the types of processes that have been generally called workflow or BPM processes (see See Example of Private Business Process.). A single private business process may be mapped to one or more BPEL4WS documents.

If Swimlanes are used then a private business process will be contained within a single Pool. The Sequence Flow of the Process is therefore contained within the Pool and cannot cross the boundaries of the Pool. Message Flow can cross the Pool boundary to show the interactions that exist between separate private business processes. Thus, a single Business Process Diagram may show multiple private business processes, each with separate mappings to BPEL4WS.

 

Example of Private Business Process

Abstract (Public) Processes

This represents the interactions between a private business process and another process or participant (see See Example of an Abstract Business Process.). Only those activities that are used to communicate outside the private business process, plus the appropriate flow control mechanisms, are included in the abstract process. All other "internal" activities of the private business process are not shown in the abstract process. Thus, the abstract process shows to the outside world the sequence of messages that are required to interact with that business process. A single abstract process may be mapped to a single BPEL4WS abstract process (however, this mapping will not be done in this version of the specification).

Abstract processes are contained within a Pool and can be modeled separately or within a larger BPMN Diagram to show the Message Flow between the abstract process activities and other entities. If the abstract process is in the same Diagram as its corresponding private business process, then the activities that are common to both processes can be associated.

 

Example of an Abstract Business Process

Collaboration (Global) Processes

A collaboration process depicts the interactions between two or more business entities. These interactions are defined as a sequence of activities that represent the message exchange patterns between the entities involved. A single collaboration process may be mapped to various collaboration languages, such as ebXML BPSS, RosettaNet, or the resultant specification from the W3C Choreography Working Group (however, these mappings are considered as future directions for BPMN).

The collaboration process can be shown as two or more abstract processes communicating with each other (see See Example of a Collaboration Business Process.). With an abstract process, the activities for the collaboration participants can be considered the "touch-points" between the participants. The actual (executable) processes are likely to have much more activity and detail than what is shown in the abstract processes.

 

Example of a Collaboration Business Process

Types of BPD Diagrams

Within and between these three BPMN sub-models, many types of Diagrams can be created. The following are the types of business processes that can be modeled with BPMN (those with asterisks may not map to an executable language):

 

BPMN is designed to allow all the above types of Diagrams. However, it should be cautioned that if too many types of sub-models are combined, such as three or more private processes with message flow between each of them, then the Diagram may become too hard for someone to understand. Thus, we recommend that the modeler pick a focused purpose for the BPD, such as a private process, or a collaboration process.

BPMN mappings

Since BPMN covers such a wide range of usage, it will map to more than one lower-level specification language:

  • BPEL4WS are the primary languages that BPMN will map to, but they only cover a single executable private business process. If a BPMN Diagram depicts more than one internal business process, then there will a separate mapping for each on the internal business processes.
  • The abstract sections of a BPMN Diagram will be mapped to Web service interfaces specifications, such as the abstract processes of BPEL4WS.
  • The Collaboration model sections of a BPMN may be mapped Collaboration models such as ebXML BPSS, RosettaNet, and the W3C Choreography Working Group Specification (when it is completed).

 

This specification will only cover a mapping to BPEL4WS. Mappings to other specifications will have to be a separate effort, or perhaps a future direction of BPMN (beyond Version 1.0 of the BPMN specification). It is hard to predict which mappings will be applied to BPMN at this point, since process language specifications is a volatile area of work, with many new offerings and mergings.

A BPD is not designed to graphically convey all the information required to execute a business process. Thus, the graphic elements of BPMN will be supported by attributes that will supply the additional information required to enable a mapping to BPEL4WS. A complete list of all the element attributes can be found in Appendix B.

 

Diagram Point of View

Since a BPMN Diagram may depict the Processes of different Participants, each Participant may view the Diagram differently. That is, the Participants have different points of view regarding how the Processes will behave. Some of the activities will be internal to the Participant (meaning performed by or under control of the Participant) and other activities will be external to the Participant. Each Participant will have a different perspective as to which are internal and external. At runtime, the difference between internal and external activities is important in how a Participant can view the status of the activities or trouble-shoot any problems. However, the Diagram itself remains the same. See Example of a Collaboration Business Process., above, displays a Business Process that has two points of view. One point of view is of a Patient, the other is of the Doctor's office. The Diagram shows the activities of both participants in the Process, but when the Process is actually being performed, each Participant will really have control over their own activities.

Although the Diagram point of view is important for a viewer of the Diagram to understand how the behavior of the Process will relate to that viewer, BPMN will not currently specify any graphical mechanisms to highlight the point of view. It is open to the modeler or modeling tool vendor to provide any visual cues to emphasize this characteristic of a Diagram.

Extensibility of BPMN and Vertical Domains

BPMN is intended to be extensible by modelers and modeling tools. This extensibility allows modelers to add non-standard elements or Artifacts to satisfy a specific need, such as the unique requirements of a vertical domain. While extensible, BPMN Diagrams should still have the basic look-and-feel so that a Diagram by any modeler should be easily understood by any viewer of the Diagram. Thus the footprint of the basic flow elements (Events, activities, and Gateways) should not be altered. Nor should any new flow elements be added to a BPD, since there is no specification as to how Sequence and Message Flow will connect to any new Flow Object. In addition, mappings to execution languages may be affected if new flow elements are added. To satisfy additional modeling concepts that are not part of the basic set of flow elements, BPMN provides the concept of Artifacts that can be linked to the existing Flow Objects through Associations. Thus, Artifacts do not affect the basic Sequence or Message Flow, nor do they affect mappings to execution languages.

The graphical elements of BPMN are designed to be open to allow specialized markers to convey specialized information. For example, the three types of Events all have open centers for the markers that BPMN standardizes as well as user-defined markers.


1. See Milner, 1999, "Communicating and Mobile Systems: the -Calculus," Cambridge University Press. ISBN 0 521 64320 1 (hc.) ISBN 0 521 65869 1 (pbk.)