Chapter 4. Seven Key Insights in BP Modeling & Simulation
The seven key insights to be discussed are:
- Key Insight #1: DES and BPM Should Learn from Each Other
- Key Insight #2: DES Tools Lack a Scientific Foundation
- Key Insight #3: Event Graphs Are the Most Fundamental M&S Approach
- Key Insight #4: Business Processes are not Petri Nets, but Event Graphs!
- Key Insight #5: There Are Two Kinds of Business Process Models
- Key Insight #6: Declarative versus Procedural Resource Modeling
- Key Insight #7: Agent-Based M&S Is a Natural Refinement of DES
Key Insight #1: DES and BPM Should Learn from Each Other
The Discrete Event Simulation (DES) community/area and the Business Process Modeling (BPM) community/area do not communicate or interact much with each other. Unfortunately, both of them tend to ignore the work being done by the other one.
A business process is a special type of discrete process, and therefore BPM is based on DES. As a discrete process (instance), a business process is a set of events that is partially ordered by their occurrence times, allowing for simultaneous events.
Strengths of DES
- General forms of resource modeling: an activity can be associated with any number of required resource objects, resource pools may be shared among two or more activities.
- Advanced forms of resource modeling: alternative resource pools, resource allocation priorities, resource preemption, etc.
- DES has a formal/operational semantics that is ontologically well-founded. For its most basic forms, Event-Based Simulation and Object Event Simulation, the semantics is provided by Event Graphs (Schruben 1983) and by Object Event Graphs and the Abstract State Machine semantics proposed in (Wagner 2017a), while for more general forms, such as BPMN-style Activity Networks and GPSS/Arena-style Processing Networks, the semantics is provided by a reduction to Object Event Graphs.
Weaknesses of DES
- All DES tools still use the (60 years old) Seize-Delay-Release pattern, either explicitly or implicitly, for modeling resource-constrained processing activities. This modeling pattern, introduced by the simulation language GPSS (Gordon 1961), represents a procedural modeling approach. Compare this to the declarative resource modeling approach of BPMN/DPMN, where activities have resource roles (special properties for referencing the used resources), which are defined together with resource multiplicity constraints.
- Over the last 30 years, DES tool vendors (Arena, Simio, AnyLogic, ExtendSim, etc.) have been coining their own proprietary terminologies and diagram languages, thus creating a Tower-of-Babel-like situation.
- The two main scientific disciplines involved in DES research, Operations Research and Computer Science, did not yet manage to establish the theoretical foundations (concepts and algorithms) for DES allowing to harmonize/unify the different DES approaches/paradigms.
Strengths of BPM
- A standardized and intuitive diagram language (BPMN).
- Declarative resource modeling with the help of BPMN resource roles.
Weaknesses of BPM
- Only limited forms of resource modeling are supported by BPMN.
- Typically, in BPM, especially in the area of Petri-Net-based workflow modeling, a limited concept of business processes as isolated "case" handling processes identified by a "case" ID (such as an order number) has been assumed. This limitation has been recognized meanwhile, e.g., by Wil van der Aalst (2021) who concedes that this approach does not allow considering interrelated processes with multiple participating objects. Notice, however, that, unlike claimed in van der Aalst (2021), BPMN does not require such a notion of "cases" for identifying a process (instance). Rather, the identity of a process is provided by its start event(s) as its causal trigger(s).
- No convincing formal semantics.
Conclusions
- DES should adopt a BPMN-like process diagram language and the declarative resource modeling style of BPMN.
- BPMN should adopt the more general and more advanced resource modeling features from DES.
- BPMN should adopt the ontologically well-founded semantics of Event Graphs.
Key Insight #2: DES Tools Lack a Scientific Foundation
The first modern DES tool, Arena, came out in 1992. Its user-interface-based high-level "process modeling" approach was later adopted/extended/improved by more than 20 different vendors, including Simul8, ProModel, AutoMod, FlexSim, GoldSim, ExtendSim, Simio and AnyLogic. This "process modeling" approach was, in fact, a Processing Network modeling approach that had been pioneered by GPSS in 1962, generalizing the Operations Research concept of Queuing Networks.
The term Processing Network (PN) has been proposed in a 1998 article by Christoph H. Loch [1]. In a PN simulation model, processing objects (representing, e.g., customers or manufacturing parts) enter a system via arrival events at an entry node and then flow along a chain of processing nodes (representing, e.g., sevice desks or manufacturing machines) where they are subject to processing activities involving various resource objects before they leave the system at an exit node via a departure event.
While Operations Research (OR) has developed quite some mathematical theory for many types of Queuing Networks, they did not care about defining a conceptual and algorithmic framework that would provide precise definitions of Queuing Networks simulation. For the more general formalism of Processing Networks, the situation is even worse: there is neither a mathematical theory, nor an implementation-agnostic (and, hence, vendor-neutral) precise conceptual and algorithmic framework!
The two main scientific disciplines involved in DES research, Operations Research and Computer Science, did not yet manage to establish the theoretical foundations (concepts and algorithms) for DES, allowing to harmonize/unify the different DES approaches/paradigms/tools.
ORMS Today, the membership magazine of the OR Society, has published biennial surveys of simulation software for DES for many years (see, e.g. their 2019 Simulation Software Survey). However, their surveys are merely a listing of vendor-provided answers to rather superficial comparison criteria, which does hardly allow a real comparison of these tools. Apparently, the survey authors have not been able to provide a critical evaluation of them, e.g., by comparing their modeling concepts. Given the lack of a unified conceptual framework for Processing Networks, this is not surprising.
This lack of a scientific foundation allowed the DES tool vendors mentioned above coining their own modeling concepts and introducing their own proprietary terminologies (and diagram languages). For instance, processing objects have been called "transactions" in GPSS, "entities" in Arena, "work items" in Simul8, "tokens" in Simio and "agents" in AnyLogic. Isn't this crazy? This is like different statistics tool vendors using their own names for standard concepts like the exponential probability distribution. They wouldn't dare!
These largely incompatible concepts and terminologies used by Arena & Co may have been good for their marketing purposes and for locking in their customers, but certainly not in the best interest of the field of DES. In fact, this Tower-of-Babel-like situation in DES hampers scientific progress in the field.