Design by doing

Flowable Engine
1

I would like to start a discussion about design by doing approach for the process modeling.
The initial background:


Question:
Is somebody interested? :slight_smile:
Could you provide any input/feedback?

2

Hi Martin,

Thanks for writing your thoughts down, I think it’s indeed good stuff for discussing.

I really like the idea of ‘design by doing’ or ‘discovering emerging processes from data’. I think it’s closely related to process mining ( https://en.wikipedia.org/wiki/Process_mining ), with that slight benefit that we’re actually already are running in a BPM system.

I think that, to go forward, the following is needed:

  1. The current API’s need to be enriched to better support dynamic tasks. I mean, we can create standalone tasks easily today, but we can’t associate tasks to each other or define relationships or order to them. If you start out from a ‘todo list’, you need to capture that these tasks belong to the same context and maybe even define that some tasks depend (maybe even with conditions) on other tasks. What would be even more powerful is that you can assign ‘ad hoc forms’ to collect data with those tasks, instead of using the less structured comments. But people won’t like they have to create a form … so we must find an easier way to ‘generate’ such forms so that people can use them easily.

  2. I believe you’ve made the right choice for using events for this. An event store (or history / audit) data with as much contextual information as possible is crucial here. Also in this area, the current logic needs improvement to cope with this.

  3. Once there is enough data, an algorithm needs to do its magic for ‘discovering’ these processes. In reality, the data won’t be as ‘clean’ as your unit test data, but with enough data some patterns will indeed arise. As the process mining articles suggest, there are a few algorithms described already that we could use as a basis (e.g. https://en.wikipedia.org/wiki/Alpha_algorithm - i looked into this like a year ago and i seem to recall it could easily be ported to BPMN).

Anyway, I’m all for exploring this idea further and helping with implementing it :slight_smile:

3

Hi Martin,

I think it is a good idea, especially from the perspective of educating the users/employees that they are part of a process and that the process can be explicitly modeled, automatized and improved. Also it helps having the employee “buy-in” for the process and not seeing it like something imposed from the outside.

Using “Design by Doing” approach can work well for linear, mainly human oriented processes, but when we add decisions, user/group assignment based on business data, service steps, timers, etc it can get complicated for not-technical users. Besides this, I do not think there is something inherently wrong with analyzing the process. A very good book on organizing the process discovery, selecting the right people to take part, documenting, etc is “Workflow Modeling: Tools for Process Improvement and Application Development” (https://amzn.com/1596931922).

br,
Vlad

4

Thank you Vlad,
I add book to my “to read” list.

5

Very interesting read. I found this while looking to see how Flowable supports dynamic tasks.

The situation I have is that in a lot of cases a flow in my business process is static:
Start
Step 1
Step 2
Step 3
End

But then in some cases we may need to add in a dynamic task within the flow.

It seems like the only option in Flowable would be subtasks that are linked to the existing steps.

Step 1
Subtask 1
Subtask 2
etc.

This might be fine, except when we want to add in a new step (e.g. Step 4) which does not exist in the flow but must be done before the End state.

It seems that we might be able to go and grab the process definition and alter it, but that would alter it for all flows, which we do not want to do since this is a one off case.

What is the best approach (if any) of accomplishing this in Flowable?

Maybe add a “Step 4” human task in the process definition right before the end of the flow. Then if any dynamic tasks come up, add them as subtasks of Step 4. When reaching that step in the flow, if Step 4 has no subtasks, automatically complete it, otherwise wait for all these subtasks to be done before moving on. Seems like a bit of a hack, but it might work.

6

I can express only my point of view. I would recommend to use adhoc tasks e.g.
Start → User Task 1 → User Task 2
I would create adhoc tasks with User Task 2 as a parent. parentTaskId in Task entity and getSubTasks in the task service

  /** The list of subtasks for this parent task */
  List<Task> getSubTasks(String parentTaskId);

I would say that design by doing (DBD) approach is too big gun for a such small fly.
DBD is inspired by ants and their path building approach. The first ant finds a way how to get somewhere. He leaves chemical footprints on the path (our process model) and following ants just follow his path (they are optimizing, and scaling too, but it is another topic…)

Martin