A common starting point for process design and all activities related to BPM is to identify and structure organization’s processes. Regularly, users tend to represent identified processes in a visual manner in the form of a process landscape (i.e. process map) diagram.
The main purpose of a process landscape diagram is to specify organizational processes on a bird’s-eye view. With process landscapes, an organization can more easily gain an overview of its main processes and their major interdependencies. Therefore, the usage of process landscapes simplifies process-related communication and represent a starting point for detailed process discovery (i.e. AS-IS process modeling). Besides, process landscapes are a common way to represent processes-based reference models for the operation (e.g. ITIL, CMMI) and the management (e.g. COBIT) of organizational IT infrastructure and services.
There are no standardized languages for creating of process landscapes. Consequently, modelers most commonly define their own ‘overviews of processes’ by using vendor-specific notations usually by imitating value chains or proposing their own more or less intuitive representations. A common approach for BPMN experts is to represent process landscapes with a subset of BPMN elements. However, despite BPMN is an ISO and de-facto standard for process modeling, landscapes are out of its scope.
While the non-normative or non-conventional BPMN-based process landscape diagrams appear in practice, this posts reviews and analyses three common approaches on how process landscapes are commonly presented with the use of BPMN elements.
Abstract BPMN Collaboration diagrams
A common and syntactically valid BPMN representation of process landscapes is to use black-box Pools and Message flows, i.e. collaboration diagrams with hidden details. A BPMN Pool is a visual representation of a Participant, which may reference at most one business process. A Message flow represents exchange of messages between two ‘message aware’ process elements (e.g. activities, message events and black-box Pools).
The strength of such representation of a process landscape is compliance with BPMN specification and simplicity. On the other hand, there are several drawbacks. First, the visual appearance of this approach is unconventional for process landscapes (i.e. processes being represented with rectangles). Second, the relationships between processes represent information exchange, where process landscape diagrams most commonly visualize sequential relationships between processes and processes clustering. Third, there is a lack of concepts, which may be regularly used for landscape modeling, namely, sequential relationships, process hierarchy and process types, whereas there is a symbol deficit in case of representing a participant and a process (rectangle symbol is used in both cases).
BPMN Conversation diagrams
Another valid way for representing of process landscapes in BPMN is by using Conversation diagrams, which were introduced in the second major revision of BPMN. Formally, they are not a standalone type of BPMN diagrams but merely an abstract view of BPMN collaboration diagrams.
Conversation diagrams are an effective way for representing interactions between processes; however, similar to “Abstract BPMN Collaboration diagrams” approach, they are based on a small set of elements, which are inappropriate for modeling of conventional process landscapes (i.e. conversation nodes, representing correlated messages and pools, representing participants or processes).
Enterprise-wide process diagrams
As stated in the BPMN 2.0 specification, it can be used for business process modeling on any level of granularity. In accordance to this, the system of an organization’s processes may be modeled as a single process consisting of individual processes being modeled as activities, i.e. sub-processes.
By using this approach, one is able to present the majority of process landscape constructs, namely processes (i.e. with BPMN sub-processes), sequential interactions (i.e. BPMN sequence flows), groups or types of processes (i.e. BPMN group element) and participants (i.e. BPMN lanes). However, there are several major drawbacks of this approach. First, such diagrams are visually inconsistent with process landscape diagrams (e.g. processes being represented with rounded rectangles and participants with horizontal lines). Second, these diagrams are inconsistent with BPMN syntax and semantics, making them invalid (e.g., BPMN Process and BPMN Sub-process are two distinct BPMN meta-model elements).
Review of BPMN approaches for landscapes modeling
A review of the presented BPMN approaches for modeling of process landscapes reveals that all three approaches lack either of concepts, which are present in a landscapes modeling domain or there lack of visual compatibility with landscape diagrams used in practice (e.g. value chains). Besides, the third approach is non-compliant with the standard and so not advisable.
One of the solutions is to provide a valid extension of BPMN 2.0 for landscapes modeling support as was proposed in the paper BPMN-L: A BPMN extension for modeling of process landscapes.