1. Initial Situation

What is the background/contextual frame of this thesis?

1.1 Introduction

Processes are ubiquitous. We encounter them in nature, technology, and even in everyday life when following structured steps, such as cooking a meal. In a modern society driven by efficiency, automation, and continuous improvement, modeling and discussing process models is crucial for innovation and iterative enhancement. It is also a key aspect of process management, which enables “high-performance processes that operate with much lower costs, faster speeds, greater accuracy, reduced assets, and enhanced flexibility” (Michael Hammer, 2010, p. 7).

In such a complex environment, establishing a common understanding among business stakeholders despite their diverse backgrounds in business, technology, and other areas is essential (Weske, 2019, pp. 4–5). The most widely used standard for formal process modeling, BPMN 2.0, “With over 100 symbols, BPMN is a fairly complex language“ (Dumas et al., 2018, p. 75). This creates a significant entry barrier for beginners learning to model processes, as well as for stakeholders attempting to interpret BPMN models.

One possible solution is a modeling syntax so intuitive that it can be fully learned within a few hours and used to create meaningful, correct models. Ideally, it should also be simple enough that even non-experts can understand the resulting diagrams. To meet this objective, subject-oriented modeling was introduced, with PASS serving as the de facto standard in this domain (Elstermann, 2020, p. 83).

However, in today’s business process management landscape, processes no longer stand alone, instead they are one of many tools applied across different stages of the process life cycle.

1.2 Problem Definition

The key challenge PASS faces are its limited applicability beyond modeling and communication. Unlike BPMN 2.0, which is supported by numerous workflow engines such as Camunda, Activiti, and Flowable, PASS currently lacks an engine for direct model execution. This puts PASS at a significant disadvantage, since modern process management relies on more than just diagrams (Dumas et al., 2018, pp. 19-20)

A workflow engine is a computer program capable of loading and interpreting digital process models written in a formal language (Elstermann, 2020, p. 73). It generates tangible value by directly executing these models: the engine issues instructions, makes decisions according to model rules, and manages individual process instances. This direct execution eliminates the error-prone human translation step.

To compete with BPMN 2.0’s dominant position in process modeling, PASS requires a strong open-source ecosystem for developing, sharing, and executing models. The most promising improvement is therefore the development of an open-source PASS workflow engine that enables testing and execution of PASS-compliant models.

During the project seminar Anwendungsentwicklung in the summer term of 2025, a prototypical subject-oriented workflow engine was developed as a first step toward such an application. While the prototype is still far from being a production-ready solution, it provides an excellent opportunity to evaluate past technical decisions and the requirements for building a robust PASS workflow engine.

The next logical step is to analyze the existing prototype in depth, identify its technical requirements, and explore alternative approaches through extensive research. This will help refine current decisions and guide future development efforts.

Although an architectural model of a PASS workflow engine already exists, the complexity of implementing it makes further analysis essential. Careful consideration of possible technical solutions is required to validate Elstermann’s model and to extend and improve the existing prototype.

 

2. Research Goal/Research Questions

What is the general goal?

What are at least 3 (better 6-10) questions or sub-questions to be answered by the theses (formulated as a question!)?

The overall aim is to explore the development of a fully-fledged PASS workflow engine by experimenting with different solutions to the challenges that arise during its creation. This work is intended to generate insights that support and guide future developers in making informed decisions for PASS workflow engine development. Since the project requires concrete choices regarding programming and technical implementation, the thesis takes a hands-on approach, validating various options through the development of proof-of-concepts (POCs).

What are the weak points of the already existing Prototype?

• How do these weak points limit the capabilities, performance, maintainability, etc. of the Software?
• Are there potential vulnerabilities that could lead to data breaches or misuse?
• What important features or functionalities are completely missing?

What technical decisions/problems have to be made/solved, and what are the best-fitting technologies to do that?

• How should data persist in the workflow engine?
• What programming language would be the best fit to achieve the technical requirements of the workflow engine e.g. performance, maintainability, ecosystem, etc.?
• What are the requirements for a programming language that is being used to develop a workflow engine and what languages are used for other engines?

What user Stories are fitting for a PASS workflow engine and how do potential users differ in their requirements? 

 

How could the software architecture for a PASS workflow engine look like?

 

3. Planned Method + Planned structure  

What are some steps planned to answer the research questions? (A rough concept is sufficient)

1. Introduction (2–3 pages)

• Motivation and problem statement
• Research objectives and questions
• Thesis structure

2. Foundations (10–12 pages)
2.1. Workflow Engines: Concepts and Definitions
2.2. Methodology (4–5 pages)
2.3. Technical Requirements for Workflow Engines
2.4. Overview of Existing Workflow Engines and Architectures

3. Analysis (12–15 pages)
3.1. Prototype: Design and Key Technical Decisions
3.2. Weak Points of the Prototype
3.3. Alternative Technical Choices
  • Tech-stack analysis
  • Communication protocols and information flow
  • Software architecture options

4. Proof of Concept (POC) (6–8 pages)
4.1. POC Design and Implementation
4.2. Comparison with the Prototype

5. Results (8–10 pages)

• Key findings from analysis and POC
• Derived architectural recommendations

6. Discussion (10–15 pages)
6.1. Interpretation of Results
6.2. Limitations
6.3. Further Research

7. Conclusion (2–3 pages)