Process Engineering and Process Mining
A business process is a defined sequence of steps: file a request, check it, approve it, invoice it. Process engineering means modelling such sequences and executing them as software. Process mining goes the other way round: every IT system records who carried out which step and when, and from those logs the process as it actually ran can be reconstructed, including every deviation from the plan.
My focus is process-centric objects. An ordinary object has fields and methods, and those methods can be called in any order; which order makes sense is known only to the surrounding code. A process-centric object brings that order with it, as a process that belongs to it. The difference shows in what is eventually executed. Normally a piece of software is built in two steps: domain experts and developers agree on a design, and someone then translates that design into source code. What runs is the code; the design hangs next to it on the wall and goes stale with the first change made only in the code. A low-code platform drops the second step: it executes the design itself and supplies the user interface, the persistence and the task management one would otherwise have to write. Design and implementation are thus the same artifact, and modelling becomes the actual development work.
The processes, that is, when which function in the program is allowed at all, are modelled as Petri nets: as graphs that record which step is possible when and what may happen concurrently. That poses the question of good design anew: principles such as low coupling, high cohesion or a single responsibility per class are formulated for source code. I study which of them carry over to a network of cooperating process classes, which ones are missing, and which can be stated so precisely that a tool can check them.
Beyond that I am interested in the empirical side: how understandable is a process model for the person who has to read it? That can be measured rather than asserted. In studies with students I ask questions about models and evaluate hit rate and response time against properties of the model, such as the number of nodes or the degree of concurrency. The tool for this, "Petri-Dish", I built myself.
