From EduTechWiki - Reading time: 14 min
Business Process Modeling Notation (BPMN) is a graphical representation for specifying business processes in a workflow. Business process modeling is an important part of enterprise architecture modeling. BPMN 1.0 was developed by the Business Process Management Initiative (BPMI) and then was/is further developed by the Object Management Group (OMG).
In this article we provide a short high-level overview, plus links and references. See the BPMN 1.2 tutorial and the BPMN 2 tutorial for more detailed technical information.
Let's have a look at a few definitions found in the literature and on the web:
“The Business Process Modelling Notation (BPMN) is a standard notation for capturing business processes, especially at the level of domain analysis and high-level systems design. The notation inherits and combines elements from a number of previously proposed notations for business process modelling, including the XML Process Definition Language (XPDL) and the Activity Diagrams component of the Unified Modelling Notation (UML). BPMN process models are composed of: (i) activity nodes, denoting business events or items of work performed by humans or by software applications and (ii) control nodes capturing the flow of control between activities. Activity nodes and control nodes can be connected by means of a flow relation in almost arbitrary ways.” (Diijkman et al., 2008).
“Business process models (BPM) are graphical representation of current or to-be business processes in an organisation. They play an important role not only in the field of business process management but also as an artifact in the analysis stage of the software development cycle. Often domain experts, business analysts and information system developers use graphical BPM when communicating with each others. The models help to bridge the well-known "language-barrier" between domain and IT-experts.” (Gruhn and Laue, 2009).
“The Business Process Modeling Notation (BPMN) specification provides a graphical notation for specifying business processes in a Business Process Diagram (BPD). The objective of BPMN is to support business process management for both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly BPEL4WS. (Business Process Modeling Notation, Wikipedia, retrieved jan 6 2009).”
BPMN 1.2 diagrams don't have a formal XML serialization, BPMN 2 do. Often, BPMN 1.2 diagrams can be translated into Business Process Execution Language (BPEL), an executable XML language for business processes. It seems that while a BPEL process can be represented using BPMN, some BPMN models cannot be represented using BPEL. “BPEL is an XML-based language for describing a business process in which most of the tasks represent interactions between the process and external Web services. The BPEL process itself is represented as a Web service, and is realized by a BPEL engine which executes the process description. BPMN is a standard set of diagramming conventions for describing business processes. It is designed to visualize a rich set of process flow semantics within a process and the communication between independent processes. It is intended to support capture of sufficient detail to allow it to be the source of an executable process description. Since BPEL is currently considered the most important standard for execution languages, a translation to BPEL is specified in the BPMN standard. By design there are some limitations on the process topologies that can be described in BPEL, so it is possible to represent processes in BPMN that cannot be mapped to BPEL.” (FAQ, retrieved 17:30, 22 June 2010 (UTC))
Some BPMN tools can compile diagrams into other XML formats. An alternative to BPEL is XPDL (XML Process Definition Language) developed by the Workflow Management Coalition. As we mentioned before, BPMN 2 is in principle an executable format, although we don't think that it is complete. E.g. we do not understand how it could represent all the information that would be needed for a "single click solution".
See also:
Other loosely related subjects:
The BPMN 1.x specification defines the notation and semantics of a Business Process Diagram language. This version does not specify any underlying (serialization) format.
The differences between BPMN 1.0, 1.1 and 1.2 are relatively minor.
See BPMN 1.2 tutorial (in progress as of July 2010)
The (future) BPMN version (in beta as of 2010) adds other modeling elements plus a layered specification. In addition, it provides a formal serialization format. We couldn't find any ETA for the final version, i.e. the final release can be month or years away. However, some companies already offer partial implementations .... - Daniel K. Schneider 11:52, 21 July 2010 (UTC)
See BPMN 2 tutorial (stub)
BPMN has three main components: flow objects, connecting objects, and artifacts. Read BPMN 1.2 tutorial for more details.
Activities
Gateways
Events
Sequence Flows
Message Flows
Associations
Data objects
Annotations
Groups
BPMN is probably today's most widespread PBM workflow and collaboration notation language. (Gruhn and Laue, 2009). According to Recker (2010), “The Business Process Modeling Notation is an increasingly important standard for process modeling and has enjoyed high levels of attention in business practice.”
According to Recker (2010), “A growing body of research has been conducted - and continues to do so [...]. For instance, research has been published that examines BPMN's capacity to support workflow technology and domain representations (Recker et al., 2007b), to facilitate semantic script analysis (Dijkman et al., 2008), and how to generate process (Ouyang et al., 2008a) and software code (Ouyang et al., 2008b) from BPMN. The fundamental question of how BPMN is actually being used, however, has not yet been fully examined. In fact, only a few studies have recently been published that begin to shed light into actual application and usage patterns concerning BPMN, mostly in the form of case studies (e.g., Recker et al., 2007a, Recker et al., 2006, zur Muehlen and Ho, 2008)”
The Recker (2010) meta-study points out that “End users mostly apply BPMN for purposes similar to what analysts did ten, twenty years ago with flowcharting techniques - they want to describe their operations in simple, graphical terms. The process modeling efforts in most organizations at this stage are simply not at such an advanced or mature stage where they could fully benefit from the full expressiveness of BPMN”. A corollary is that “the large number of autodidacts and the small share of adequately trained BPMN modelers imply a dearth of advanced BPMN process modeling skills. Such skills, however, are key to ensuring quality and overall success of BPM initiatives.”. Therefore, the authors argue that both education and continuous training is a critical issue.
Since most vendors do not support the full set of BPMN constructs, Recker (2010) the suggests “that tool vendors should or could rely more on empirical information about BPMN use when having to make trade-off decisions in BPMN support.”
Dijkman et al (2008) argue that “BPMN standard specification is relatively detailed when it comes to specifying syntactic constraints on BPMN models, but it is unsystematic and sometimes inconsistent when it comes to defining their semantics.”. Recker (2010) asks “the question whether a highly expressive but also very complex notation is a desirable result of a standardization process. More than 120 people participated in more than 120 interactions as part of the development effort that went into BPMN 1.0. Unfortunately, very little effort was dedicated to understanding the end user perspective of standards making.”
Based on expert's mapping of BPMN to the BWW representation model (Wand & Weber, 1995) - a construct developed to analyze ontologies - Recker et al. (2006) derived nine propositions that demonstrate how some lack of ontological completeness and clarity in the BPMN 1.x notation may lead to problems. These propositions then were submitted to experts through an interview protocol. These propositions are grouped in four topics which we summarize below (including some quotations):
(1) Construct deficits:
(2) Construct redundancies
(3) Construct excess
(4) Construct overload
An “empirical investigation conducted through semi-structured interviews with BPM(N) experts, however, revealed that not all the theoretical predictions will constitute critical problems in process modelling practice” (p. 10). In particular, only P1, P7, P8 and P9 were identified as critical issues. P2, P4, P7 as somewhat limiting.
Wohed et al (2006) used Workflow Patterns from a collection of patterns developed for assessing control-flow, data and resource capabilities in the area of Process Aware Information Systems (PAISs) to examine the suitability of the Business Process Modelling Notation (BPMN) 1.0 for business process modelling. In the conclusion, the authors first state that “There are inherent difficulties in applying the Workflow Patterns Framework for assessing a language that does not have a commonly agreed-upon formal semantics nor an execution environment”. In other words, their analysis ought to be reconducted with the upcoming BPMN 2.0 version.
With respect to execution, mapping to BPEL is judged to be “only partial, leaving aside models with unstructured topologies as well as constructs such as OR-join and complex gateways. Moreover, since the mapping is described in prose, it is subject to interpretations”. However, BPMN 1.2 does include a more formal annex for mapping to BPEL.
With respect to expressive power “BPMN provides direct support for the majority of the control-flow patterns and for nearly half of the data patterns, while support for the resource patterns is scant”. In particular, “Workflow and Environment data patterns are not supported. Data interaction to and from a Multiple Instances task is not supported because any instance-specific data for a task or sub-process with a multiple instance marker can not be specified. Also support for the external data interaction patterns is limited.”. “BPMN's support for the Resource perspective is minimal. It is acknowledged in the specification (p. 22) that the modelling of organizational structures and resources is outside the scope of BPMN. However, the presence of the concepts Lane and Pool for representing parties and roles gives a contradictory impression.”
Wohed et al. also point out that many patterns have multiple representations, a remark also addressed by Recker et al (2006) and finally they found strong overlaps with UML activity diagrams.
Besides criticism that relate to construct excess and overload as in the Recker et al., (2006) study we introduced above, there is are other usability issues: How easy is it to learn understanding BPMN (and other language) diagrams, and how difficult is it to be learn creating a model.
Since BPMN and other visual design languages like UML allow for many different solutions to a given problem, we also have to figure out what minimal design guidelines are needed. According to Gruhn and Laue (2009), “there are several good guidelines on how to create BPM that are correct and understandable (Ambler, 2003; Becker et al. 2000; Mendling et al., 2008) as well as useful compilations of common patterns for bad modelling (Koehler and Vanhatalo, 2007; Smith, 2008). However, there is not much related work on actually identifying understandability problems in existing models. As already mentioned, most work on formal analysis of business process models focus on the correct behaviour of the model.”
Gruhn and Laue (2009) make several suggestions to reduce the complexity of models, e.g.:
In conclusion, BPMN 1.x may lack certain constructs that are needed to model typical workflows found in the workflow patterns literature and it may not to suitable to model large processes across organizations. In addition, there are usability issues both due to excess/redundancies of constructs and lack of precision due to overload of certain elements of the language. Usability can be approved when users are trained to adopt good practice, e.g. learn to aim for the most simple solution.
One of the biggest issues that may affect use of BPMN for educational workflows may be BPMN's weakness in both data and resource modeling. However, currently, our own experience with BPMN is much too limited in order to make any well informed claims.
We also would like to remind that the upcoming BPMN 2.0 specification did address many issues raised. Firstly, the serialization issue may be solved with its own XML representation. Inter-organizational workflow can be modeled with conversations and choreographies, two new constructs that complete the "Swimlane" model which is now called a "collaboration diagram" - Daniel K. Schneider 18:09, 27 July 2010 (UTC).
PBMN is mentioned in the literature about educational design languages as an alternative to specifically developed languages. However, as of 2012, there don't seem to be many in-depth investigations about its potential.
Adesina and Molloy (2012) present a Virtual Learning Process Environment (VLPE) based on the Business Process Management (BPM) conceptual framework, where course designers use the BPMN notational design language. Since a BPN system implements workflows, it allows “behavioural learning processes of the cohort of students – right from the inception of the teaching and learning process – to be continuously monitored and analysed until completion” (page 429). Julien DaCosta presented a master thesis in Feb 2014 about the educational use of BPMN (should be online sometimes soon).