Having done 13 years of BPM before starting STOIC, the last thing that I wanted to hear about when starting this new company were business processes. Having gone totally gonzo for a solid third of my life on this concept, I wanted to go as far away from them as possible. Unfortunately, they’ve been catching up on me, and today I pretty much had to surrender.
For the past two years, anything that had to do with processes has been handled with what we call Workflows. Essentially, finite-state machines attached to the records of any object, with an object-specific execution model. It’s a great abstraction for most process-related use cases that you’ll ever come across, but it breaks down whenever you need cross-object process automation.
As we’re developing STOIC Education on top of STOIC CRM, we came across the need to automate complex marketing campaigns, and no matter how many times we flipped the problem around, we could not find a way to implement this use case with standard workflows. So, after much pondering, I decided to implement a BPM engine on top of the STOIC Platform. This engine is made of the following objects:
- Processes, to define business processes
- Steps, to define the individual steps of processes
- Instances, to capture the instances of processes
- States, to capture the individual steps of instances
In other words, Instances are instanciations of Processes, and States are instantiations of Steps, while Steps are components of Processes and States are components of Instances. While it’s too early to draw any conclusions, a few observations are worth making:
First, Processes differ from Workflows in the sense that Workflows are directly attached to the records of objects, while Processes are not. That being said, it should be noted that many process instances will be created by executing a Batch against a set of records. In this case, Instances will also be tightly related to the records of objects, yet their processes will execute processors that will potentially span across the records of many different objects.
Second, Workflows are modeled as finite-state machine. As such, they do not support any notion of parallelism, and this shortcoming was one of the primary reasons why I decided to create the Processes object. As a result, Processes are modeled in a very different way compared to Workflows. While workflow steps are designed by defining their multiple next steps, process steps are designed by defining their unique previous step. Consequently, Workflows have a graph structure, while Processes have a tree structure.
Third, Workflows are quite focused on human interactions, while Processes are more interested in system automation. Even though the boundary is quite fuzzy (you can invoke a Processor from a Workflow step and you can assign a human Task from a Process step), I really believe that different priorities call for different tools and different abstractions. That being said, Workflows and Processes have been designed in such a way that one can be used with the other. And when our understanding of both will reach some critical mass, we might get the necessary inspiration to fuse them back together — who knows?…