Some of our customers are process-driven. These processes must be mapped in their software. Projects often become unnecessarily complicated or protracted because the specialist department and IT speak a different language. How can business departments and IT cooperate such that both understand what is meant?
A common language is needed so that business processes can be optimally implemented in software applications. Over the years, BPMN (Business Process Model and Notation) has proven to be an ideal tool for our projects with clients whose structure is strongly process-bound. BPMN offers a common language and a visual approach for describing, analysing and optimising business processes.
What is BPMN?
BPMN is a standard for modelling business processes. An important aspect of BPMN is that models can be represented graphically. This visualisation is used to better understand the processes themselves, to communicate with affected stakeholders and to optimise the workflow.
The basic elements of the standard include:
- Events (e.g. the receipt of an email).
- Automated tasks (e.g. entering data into an internal system)
- Manual tasks (e.g. making decisions)
- Gateways (splitting the programme flow)
- Connectors (linking the other BPMN elements)
Case study application process
To illustrate the advantages of working with a structured process, we have developed a simple case study: In a company, the initial contact with job applicants is to be mapped by an IT system.
Normally, the HR department would discuss requirements with the development department and commission the implementation.
A common understanding of the application process must be developed. A requirements document will probably be interpreted a little differently by everyone involved and it is questionable whether the implementation will correspond to the real requirements.
BPMN as a requirements specification
BPMN can help here to develop a central document for requirements and implementation. It explicitly serves not only for documentation, but can also be the basis for concrete implementation through the use of a process engine.
Even this simple example shows that even without special knowledge about the details of the standard, it is clear how the process works on a basic level.
In addition, all stakeholders (human resources, project management, product owners, designers, developers, etc.) can refine and improve the process through a constant exchange. BPMN-driven work is thus an ideal compliment to agile process models, which are practised in our company.
The following BPMN 2.0 elements are used in the above graphic:
| Element | Description |
|---|---|
| Start Event | A process is started via this event. As soon as a process is started, an instance of the process is created. This instance then contains the current status of the processing, all associated data and other additional information |
| Connectors | Connectors regulate the control flow and define the next controlled BPMN elements after processing the current element |
| Activity | Activities or tasks are all those things that have to be carried out (manually or automatically) during a process. Here, external systems can be addressed or data manipulated |
| Gateways | Gateways separate the control flow and define which elements are then executed on the basis of the available data |
| End Event | As soon as an End Event is reached, the processing of the current process instance is completed |
In addition, there is a multitude of other elements that support a fine-grained modelling of processes of any kind.
A more detailed specification of the elements can be found in:
- https://www.omg.org/spec/BPMN/2.0/
- https://de.wikipedia.org/wiki/Business_Process_Model_and_Notation
BPMN as the basis for implementation (Camunda)
As mentioned above, the created graphic is not only a specification, but also acts as the basis for the technical implementation.
In BPMN-driven software implementations, a process engine is now required. There is a whole range of these for different application purposes. We have had the best experiences in our projects with Camunda.
Camunda has a large community, is a mature software product and can still be used free of charge. It also offers various on-premise and cloud solutions.
We currently use Camunda 7 as an on-premise solution in combination with Java and Spring Boot.
Architecture
A great advantage of the implementation solution BPMN with process engine is that the architectural decisions are comparatively uncomplicated. It makes sense to create a separate application for each activity (task) and another application for the process engine itself. In this way, the system architecture can be roughly derived from the BPMN process description.
As can be seen in the illustration, a separate service is built for each activity. This connects automatically to the central process engine through the Camunda libraries. It should be noted, however, that such a procedure is not absolutely necessary. All code could also be located in a central service, but this would undermine a major advantage of our architecture. Each individual task handler service is freely scalable. This means that applications can also be developed that process very large amounts of data. Camunda ensures that only one task (linked to a process instance) is ever forwarded to to a single service instance.
The task handlers regularly ask the process engine for new tasks and Camunda guarantees exclusive processing. The communication is therefore polling-based rather than a push of the individual tasks.
A task handler processes the given task and reports the response back to the process engine. During processing, the respective task handler can access variables that are provided to the start event or are changed or created by other task handlers during the run.
The variables and other data are automatically stored in the database connected to the process engine and are completely abstracted from the user's point of view.
Code example of how a task handler connects to the engine:
The supplied libraries allow easy implementation of the respective task handlers, as they take care of the entire logic of connecting to the process engine by themselves. In addition, many parameters can be configured, such as polling or lock intervals, which determine the maximum processing time.
Advantages of this approach
As mentioned earlier, using BPMN as a requirements specification offers a number of benefits, including:
- Improved understanding of the process: the visual model helps all stakeholders to get a clear picture of the process.
- Improved communication: the model can be used as a communication tool between the different stakeholders.
- Facilitated implementation: The model can be used as a basis for the concrete implementation of the process. Furthermore, Camunda can also be used as a software-as-a-service, thus eliminating additional effort for data management as well as setup of the process engine.
Restrictions
- Usage in the right context: For the development of a system based on business processes, the use of BPMN and Camunda is an excellent solution. This is also reflected in the practice of our work with the mentioned systems.
- Initial (learning) effort: BPMN and Camunda have a relatively steep learning curve, which might make it difficult to get started and gain acceptance from stakeholders. However, there are enough resources to solve a variety of problems.
Conclusion
The use of BPMN facilitates the modelling of an existing business processes and also provides good services for the development of new processes. The standard serves as a working tool and documentation at the same time and is thus a good basis for achieving a common understanding of technical knowledge. Once created, the process is a perfect basis for the technical implementation of the current business processes with the help of process engines such as Camunda. Process modelling, an agile approach to development and a focus on technical aspects go hand in hand here to find optimal solutions for different customers and use cases.
