"All processes must be executable," says the IT guy. "Aren't all processes working? Is there any process that doesn't work," the puzzled business manager asked.
Most of us would have no problem to grasp the concept of a "business process". However when used in conjunction with terms like "process model", "process instance" or even the word "process" itself, the conversation often get very muddy. Without giving any context, these terms are at times confusing especially where conversation is held between practitioners from different knowledge domains (perspectives). This paper illustrates the meaning of the terms when used in different perspectives and how they relate to each other.
There are many perspectives to business process and the definitions of terminologies used are not consistent across the different perspective. I will not dwell into every perspectives in this paper but focused on two of the most common ones:
- Perspective based on process automation via a process engine or a workflow engine. In this paper, let's call it process automation perspective.
- Perspective without process automation - for the rest of this paper this is referred to process documentation perspective.
Process Documentation PerspectiveIn this knowledge domain where the focus is not on automation, most of the time the key outputs depend on presentation of the findings and recommendations. Hence a focus on the process documentation. The main artefact of this perspective is the "process definition" that is used to describe "process".
|Figure 1: Process Documentation Perspective of the terms Process and Process Definition|
A "process definition" is the description, at differing levels of details, with various attributes of a "process", including the flow of activities. The "process definition" also provides the descriptions of the various scenarios that the process could run into.
In this perspective, a "process" is the actual runtime of a scenario described in the "process definition". Since it is only one of the many scenarios, a "process" can only have one outcome. The "process definition" which describes all the potential scenarios, in this case, will shows the different possible outcomes based on the scenarios.
In short, the term "process" here refers to the actual runtime of activities not the description of the activities.
Process Automation PerspectiveLike most IT terminologies, the terms are muddier in the process automation perspective. Rather than having an artefact that describes a "process", a "process model" is build to represent a process. Similar to a "process definition", a "process model" has the many attributes of a process. A "process model" also includes the different scenarios of a process. These scenarios are represented as different variations in the activities flows within a process model or the different paths of the flow.
|Figure 2: Process Automation Perspective of the terms Process and Process Instance|
The line between a "process model" and the actual "process" the model is representing gets blurrier when a "process model" is developed on a process tool. The model is now a virtual process. Since it is a virtual process, in many cases, the terms "process" and "process model" is used in synonymous when referring to this virtual process.
So if the process is also the process model, then what do you call the actual runtime of a process (virtual process)? Introducing the term "process instance" which is used to refer to the runtime execution of a virtual process represented as a process model on a process engine. A "process instance" in this perspective has the characteristic of a "process" in the process documentation perspective. So a process instance only runs one of the many scenarios described in a virtual process (process model).
Think of a physical book and a pdf file of the same book. Although the pdf file does not fit the characteristic of a book, it does have the contents of a book and also commonly referred to as a book today.
Process versus WorkflowIs it not muddier enough? Well not forgetting another common term used in this perspective is the term "workflow". A "workflow definition" is the same in concept to a "process model" but the underlying technologies for its running may be very different. The term instance is also used represent runtime of a"workflow definition", hence "workflow instance". Again a "workflow instance" is the same in concept to a "process instance".
|Figure 3: Process vs Workflow|
There is another key difference between the use of process and workflow within the process automation perspective. The term "process" is used to describe either IT system process or human activities or even combination of both. Whereas under the "workflow" approach, there are two types of workflows - IT system work flow and human workflow. Again the reason is the underlying technologies used different.
Control Flow Between ActivitiesThis is another interesting aspect that differs in the two perspective. Under the process documentation perspective, the flow from one activity to the other represents a sequence flow between activities. In layman terms, it shows the sequence between the activities. The hand off between activities are sometimes called out as a separate activity.
On the other hand, under the process automation perspective, the flow from one activity to another also represents the control flow and information flow between these activities. When an activity is completed and process moved the next activity, the underlying process engine pass the control from the previous activity to the next. this also applies to the information between the two activities.
So, where does Process/Workflow Pattern sit?According to psychological study, our brain is trained to recognize patterns or even tempting to create one when there isn't one to something we are familiar. Having said that, the term "process pattern" or "workflow pattern" is used in general to describe collection of flow patterns of activities.
|Figure 4: Process / Workflow Pattern|
Under the process documentation perspective, a process pattern can be applied to one or more "process definition". Now the catch is, two "process definitions" with the same process pattern does not mean the two "process definitions" are the same. The only similarities in them is the pattern of the flow between the activities.
Under the process automation perspective, a process pattern can be applied to one or more "process model" or "process". Again, when two "process models" or "processes" have the same process pattern, it does not mean the two "process" are the same process. This could caught up in another debate where the way IT likes to treat patterns in a specific way and confused with the concept of "reuse". But that is for another day ...
Joining the Two PerspectivesThe aim of this article is to join the two perspectives into a combined one. Figure 5 diagram illustrates how the terms relate to each other.
ConclusionAll these terminologies look simple in our day-to-day common language but it could get nasty when moving into the different knowledge domains. Without context and agreed definition, a simple term could potentially causing heated arguments. Try to understand the perspective of the other side. Put the context in place to avoid unnecessary arguments. Make sure you reach an agreed list of definitions.
Next time when someone mentions the word "process", clarify whether he/she is referring to an actual running process or a process model.