Business Processes are ubiquitous in companies and the business world in general. Using the OMG Standard BPMN (Business Process Model and Notation) for modelling business processes and running them on a process engine creates the opportunity to monitor time, cost, and quality.
However, in current business process management approaches, reducing the carbon intensity of processes is not an optimization focus.
For the execution of BPMN models, process engines like Camunda are used. For every process instance, the Camunda process engine drives the execution of the model by creating jobs for each activity following the order of their appearance in the process model. The jobs are completed by external applications called Job Workers. After finishing their work, the job worker completes the job so that the process engine can move forward in the process model.
In a real example process which is used at NASA, images from the Mars Rover are sent to Earth (Camunda used at NASA) and analyzed in computationally and energy intensive jobs. Analysis starts the moment the footage arrives in Houston, regardless how green or dirty the energy happens to be.
The question arises, why not move the computationally and energy intensive tasks to a time window where energy is less carbon intense? In our NASA example, it might be feasible to move the execution of the very intensive image processing work to a time window where less carbon is emitted.
Prior to the intensive processing, our Carbon Reductor is inserted and configured into the process model so that the process continues to run on time but emits less carbon. The Carbon Reductor makes use of the process engine’s control of order and timing of tasks to shift the execution of upcoming tasks to a time window with less carbon emissions.
The Carbon Reductor is a reusable modeling element that can be configured to reduce emissions based on Service Level Agreements (SLA) for the process like the maximum cycle time for a process instance. Information about the SLA is entered along with a forecast of how long the remaining tasks will take. The configuration allows the Carbon Reductor to independently optimize execution by time shifting the remaining tasks without violating the SLA for maximum cycle time.
When the execution of a process instance arrives at the Carbon Reductor a job is created that contains the configuration. Our Carbon Reductor Job Worker picks up the job and uses the configuration to query the carbon-aware-sdk for a prediction of the current location to find the optimal time window for the process to proceed. This time window is then passed back to the process engine that shifts the execution accordingly.
Since process engines are able to monitor the process instances run, it is possible to visualize data on a dashboard like the average carbon saving per instance as well as KPIs like the number of instances that saved more than 10% of carbon.
We developed our solution with Camunda’s process engine. Based on Camunda’s process instance volume data, there are 1 billion active instances per day (based on 125.000.000 instances per day and assuming 10 to 15% use telemetry). This means that there is great potential for carbon reduction, even if a single time shifted process instance does not save much carbon.
Using Carbon Reductor is as simple as modeling an additional element into your process model while running our corresponding standalone job worker. This means that integrating our solution into an already running system is simple.
Camunda has a very alive and active community that is open to change and adapts new ideas. At envite, we host several community events and have already created community assets that are used by others. So, we have the visibility and reach to promote our solution to the relevant group of existing Camunda users. After our announcement on LinkedIn, we have already received encouraging feedback from the community.
While our solution is already in a stage where it could save some carbon in a production environment, we would like to incorporate feedback from real world use-cases and improve its effectiveness, e.g., by caching carbon-aware-sdk’s responses. On top of that, we want to spread the word about our solution in the Camunda community.
Currently, the location where the process is running must be entered into the Carbon Reductor configuration. While this is feasible in some scenarios in which the process and all workers are running in the same region, we would like to enable process engineers to use the Carbon Reductor for multiple regions, allowing for location shifting as well.
Right now, the Carbon Reductor takes a duration for the rest of the process as input. In the future we would like to use predictive analysis to determine the remaining time by considering the remaining duration of the instance based on the input data, which in turn will allow us to find an even more appropriate time window for the process execution and makes the usage of the carbon reductor even easier.
While the Carbon Reductor has to be modeled explicitly into the process model, we want to research how to implement the functionality for the whole process model without an additional modeling object in the future. The vision is that you can toggle on the carbon reduction for the process model and specify the configuration for the time shifting.
Finally, an interesting topic we would like to explore is the possibility to save carbon in the bigger picture of an end-to-end-process. In our NASA example above, the model ends with the processing of the Mars Rover’s footage. The upcoming journey of the processed material is not included but may also provide the opportunity to save carbon. For this, the concept of the Carbon Reductor could be applied to other process engines that handle business processes differently from Camunda.