15.6. Business Process Standards Initiatives

The last few years have seen an increase of interest in standards related to business process modeling. This has been fueled partly by the growing use of process modeling by business and partly by the desire of software vendors to establish a prominent position in an expanding market. Three areas are particularly prominent in current standards activity.

Notation. Most process models use some form of diagrammatic presentation of the process design. This typically takes the form of a flow diagram showing sequencing, branching, and so on, perhaps with some additional annotation to indicate related features such as the use of resources and organizational structure. The graphical syntax (including symbols and connection rules) vary from one notation to another. Perhaps more importantly, the semantics also vary. For example, a diamond shape may look similar in two different notations but have subtly different implications in each. A common notational standard would simplify staff training, make process designs more readily understandable, and reduce the scope for semantic variation. A leading proposal in this area is the Business Process Modeling Notation (BPMN).

Metamodel. Although humans typically view a process design through some form of notation, automation of the process requires the construction of a data structure and procedures that can navigate through the structure. Transferability of process designs between tools and between organizations would be facilitated by having a common metamodel to ensure consistency. A leading proposal in this area is the Business Process Definition Metamodel (BPDM).

Execution. The rapid growth of Web services has led to a demand for a consistent way of expressing business processes in an executable form. The basic Web protocols are stateless, but business processes may require lengthy conversations between distributed participants in a process. One way of tackling this problem is to have a specialized programming language targeted at a business process execution engine. A leading proposal in this area is the Business Process Execution Language (BPEL).

We will look at BPMN, BPDM, and BPEL in more detail shortly, but it’s worth noting a few other proposals to give an idea of the scope of current activity. Table 15.4 shows a partial list of organizations active in process-related fields and the initiatives with which they are involved. The “alphabet soup” created by the large number of abbreviations and acronyms can appear daunting, but we don’t have space here for a full explanation of their relationships. The chapter notes give some additional references.

Business Process Modeling Notation

BPMN defines a graphical syntax for drawing flowchart-like process diagrams. It is intended to be primarily business facing, not a description of a technical realization. It does not specify how to execute a process on a computer: it assumes that BPMN models will be mapped to whatever execution environment is required. The BPMN specification provides a sample mapping to BPEL, and in future, mappings to various forthcoming W3C standards are anticipated. BPMN began life as part of the Business Process Modeling Initiative, but progress on the standard moved to the OMG in mid-2005. Various drafts of Version 1 of the standard have been available for some time, and work has now started on Version 2.

An activity represents work that is performed during a process, denoted in BPMN as a rectangle with rounded corners. Activities can be nested with the details of subactivi-ties hidden. Compound activities are identified by adding a “+” icon to the activity symbol. BPMN also uses the term “Task” for atomic activities that have no lower level breakdown. Various other icons can be added to the basic activity shape to indicate other types of activity, such as looping, transactional, compensating, ad hoc (the sequencing of any internal activities is not defined), multiple instance (several instances of the activity can be performed in parallel), and so on. With some restrictions, these can be combined to indicate such things as a looping ad hoc compensation activity.

Events represent something that happens during a process and are denoted by circular symbols. There are three main subtypes: start events have a single-line circle, intermediate events have a double-line circle, and end events have a thick line circle. Icons can be added within the circle to give a more precise indication of the type of event, such as message, timer, error, and so on.

Splitting and joining in flows can be shown using a diamond-shaped gateway symbol. The symbol can carry an additional icon to indicate the nature of the split or join. Variants include exclusive-or (the default if no icon is shown), and, inclusive-or, and complex (where the split or join conditions are determined by expressions).

Activities, events, and gateways are linked by connecting objects, which come in three varieties. Sequence flows show the order (sequence) in which activities will be performed during a process and are denoted as solid lines with a filled arrowhead. Sequence flows can also carry additional markings to indicate that a flow is conditional, or is a default flow. Message flows show the interchange of messages between participants in a business process and are denoted as dashed lines with unfilled arrowheads. Associations are used to connect data, text, and so on with flow objects and are denoted as dotted lines with an optional open arrowhead. One use of these is to show the inputs and outputs of activities. Figure 15.42 shows a typical BPMN process diagram.

Figure 15.42. A BPMN diagram.

[View full size image]

The process in Figure 15.42 starts with the receipt of a loan application (shown as a message). After the loan assessment activity the control flow passes to one of the three following activities. Each of these is a compound activity: the internal details are not shown here. The final exclusive-or gateway joins the split paths together and the process ends. In the referral case, there is a time event associated with the applicant review. If the review is not completed within the given period it is escalated to be dealt with by a supervisor. The escalated review process also has branching in the flow, but rather than using gateways, the subprocess uses decisions on sequence flows and implicit joining of flows. The escalated review subprocess also shows reuse of the definition of the compound activities for loan approval and loan rejection.

The current version of the BPMN standard has been criticized for a lack of clarity in some areas. Some aspects, such as the detailed rules for the processing of flow tokens at gateways, are not fully specified. In other areas, BPMN offers alternative notations for some constructs, such as splitting flows following an activity, but gives little or no guidance on when one approach should be preferred over another or whether subtle semantic differences exist between the alternatives. However, such issues will no doubt be addressed in future versions of the standard.

Business Process Definition Metamodel

BPDM provides a capability for representing business processes in a way that is independent of any particular notation or process modeling methodology. The concept of a metamodel is intended to provide a kind of vocabulary of concepts related to process modeling, with a clear definition of the meanings of the concepts and the ways in which one concept can relate to another.

BPDM supports two complementary views of business processes—“Orchestration” and “Choreography”. Orchestration is concerned primarily with what happens and when, and is usually defined in some flow-based notation (although the notation itself is outside the scope of BPDM). Choreography describes how business entities collaborate in a process, taking into account that the entities may be independent and may have their own internal processes. The focus is on the responsibilities of the role players in a process and the interactions between them.

BPDM is intended to separate out several potentially overlapping concerns. One is the distinction between the definition of a process and the notations that might be used to depict the process. BPDM process definitions are designed so that different tools can depict or utilize a process definition in different ways yet still be interoperable. For example, a drawing created using one vendor’s modeling tool could be opened and executed using another vendor’s business process management system. Another potential overlap is between the specification of the goals of a process and the definition of the actions required to achieve the goals. BPDM allows for the specification of process “contracts” independently of the definition of the implementations that correspond to the contracts, allowing processes to be defined at any appropriate level of detail.

Although BPDM and BPMN are now both proceeding under the auspices of the OMG, they had different origins and, for a while, were not wholly consistent. Recently, great efforts have been made to harmonize these two standards, so, for example, BPDM now uses the notation of BPMN and has some extensions to provide additional functionality that is specific to BPMN.

The BPDM Metamodel is based on the “Meta Object Facility” (MOF) that also underpins UML and some other OMG standards. As well as providing a baseline for concept definition, MOF also supports an XML syntax that can be used for transferring business process models between tools and between organizations. The specification of BPDM is split into a series of packages, each of which uses the classifier-oriented notation of MOF to show the relevant concepts and their associations. Effectively, each package forms a submodel within BPDM. Table 15.5, which is adapted from the descriptions provided in the BPDM specification, summarizes the packages and their major features.

As BPDM is not yet a fully ratified standard, experience in its use has so far been limited to a small number of companies and researchers. By its nature, it will be mostly relevant to organizations involved in process modeling technology, such as the builders of modeling tools. It is too early to tell whether the standard as defined will fully meet the needs of industry, but it clearly occupies an important position in the process modeling spectrum.

Business Process Execution Language

BPEL is intended to extend the current standards for Web services standards to add explicit support for business processes. BPEL is essentially a programming language that uses XML syntax. The original version, called BPEL4WS, was based on Microsoft’s WSFL and IBM’s XLANG approaches. The more recent version has been renamed WS-BPEL. Unless otherwise qualified, BPEL refers to both of these versions. BPEL can be used for abstract process definition, but its main application is in the definition of executable business processes.

A process description in BPEL includes elements that define the main activities in the process, correlation sets (used to correlate messages with the process), partner links, variables used in the process, and various kinds of handler for compensation, faults, and events. BPEL assumes the existence of one or more Web Service Definition Language (WSDL) files that define the Web service interfaces. WSDL is a separate standard, which is used for other purposes besides support for BPEL.

BPEL was formed by combining the previous XLANG and WSFL initiatives and includes features of both block structured languages (from XLANG) and directed graphs (from WSFL). Some examples of BPEL elements are shown in Table 15.6.

As a consequence of the mixed inheritance of BPEL, the implementer may have a choice of alternative constructs that could potentially produce the same effect. For example, a sequence could be realized using either <sequence> or <flow> with <link>. In some cases, it is necessary to use the block structured part of the language: for example, a deferred choice can only be modeled using the <pick> construct. In other cases, it is necessary to use the graph-based part of the language: for example, two parallel processes with a one-way synchronization require a <link> inside a <flow>. Some of the semantics of the constructs are very subtle, and effects can be produced that may not be entirely what the process implementer intended.

One consequence of the block structured elements of BPEL is that some process constructs that can be expressed in a graph-oriented approach cannot be expressed in BPEL, and some remodeling may be required. Figure 15.43 shows a nonstructured process flow and one possible way in which it could be remodeled. In order to get to a block structured form, it’s important that any looping constructs are arranged so that there is only one entry point into the loop and only one exit point from it.

Even trivial processes produce many lines of BPEL XML code, so we don’t show an example here. The code is also quite difficult to read for humans and is really intended for machine execution. Most process modelers are likely to prefer a tool with a user-friendly interface that has the ability to generate BPEL from a model, rather than writing BPEL code directly.

BPEL is firmly targeted at business processes and is probably the most powerful language for defining business process execution. Of course, conventional programming languages such as Java could be used in place of BPEL, but would probably require more effort and require a great deal of detailed code to produce an equivalent result. One negative aspect of BPEL is that it is syntactically quite restrictive, which causes problems when it is required to transform a non-BPEL model (for example, in BPMN) into BPEL code. BPEL has had little competition to date, but it is possible that some of the newer work based on Web services choreography and the Semantic Web may overlap with BPEL, and other approaches may emerge in the future.