What does KuFlow offer?

If you agree that the model presented in this document is an adequate model to represent the nature of business processes and interactions with different agents, the next question is: what does KuFlow offer you?

Humans

KuFlow provides humans with a user interface (UI) that allows humans to interact with processes. Below we review how KuFlow supports the different human interaction patterns we have defined above.

• If a workflow decides that I need to perform a task, it should create a human task and assign it to me. I will be able to access the UI to see what I have to do and proceed to complete it when necessary.

• If the workflow decides that I need to know certain information, it will send it to me so that I can consult it through the KuFlow UI. There are two mechanisms for this: create an information task, which is a container of information that the workflow creates to locate relevant information for the users of the process; or create a notification, which is a container of information that is addressed to a specific user, and which requires the user to confirm that he/she has read it.

• How can I, as a human being, know what tasks I have assigned to me? By means of a screen in the UI that allows me to consult the tasks assigned to me.

How can a workflow create a human task, an information task, or a notification? Through a Rest API provided by KuFlow.

Workflows

When it comes to defining processes, there are several approaches. In the following we will make a general classification that will serve to locate each of the solutions:

• Some tools, especially those that come from workflows and that have been adapted, offer the possibility of defining processes by drawing a workflow or state machine. Each node is a task and some small conditions can be associated to the transitions to give intelligence to the process. These are tools that allow workflows to be defined very simply. But their weakness is that they are not very expressive and do not support more complex processes.

• The most widespread solution of all is to use BPMN (Business Process Model and Notation). This is a standard for defining workflows where, in addition to tasks, different elements can be specified, such as branches, junctions, events, etc. It is a more complete solution than a state machine diagram and its main advantage is that it is a more powerful tool and at the same time it is still intuitive enough to be easily understood by non-technical personnel.

• In recent years there has been a boom in tools defined as no-code or low-code. These are generally graphical tools that allow you to "draw" a flow, but give you the possibility of defining some logic through intuitive screens. As in the case of workflows, they are tools that allow processes to be defined easily but become more complicated when it comes to complex processes. For complex processes, they offer lower-level solutions that are embedded in the graph. In a way, BPMN tools can be classified in this category as long as they allow to express some logic in the visual components offered by the notation.

KuFlow's approach is different

Graphical tools are often very convenient for simple processes. They allow non-technical people to create and update their processes. The low-code and no-code movement is trying to democratize this type of tools so that anyone can use them. However, when processes become more complicated and when many business rules have to be developed, these types of tools become complex. The ways to define these particularities are tedious and end up being impractical.

Experience suggests that when processes become more complex, organizations end up requesting that the processes be designed by software engineers. In the end, it is necessary to define expressions, statements, and a whole set of constructs related to computer engineering. What happens is that software engineers do not like no-code and low-code tools. And their arguments are quite strong because such tools do not make use of all the best practices and solutions that have been created over time for dealing with complexity in software. Therefore, the management, maintenance, and sustainability of workflows become complicated and what was a solution becomes a problem.

To better understand the arguments of software engineers, let's give some examples:

• To work collaboratively, engineers use tools such as a git repository that allows a team to work efficiently on the same codebase. Separate branches with code modifications can be created, code review protocols can be defined, modifications can be mixed, and so on. All these tools are not usually available in existing solutions.

• Workflows need to be tested and debugged. Software engineering has been developing tools for decades to perform these tasks in traditional programming languages. In existing solutions, these possibilities are much more limited and less powerful.

• The expressiveness achieved with a programming language is significantly higher than that achieved with a user interface designed for non-technical people. BPMN has a more powerful expressiveness, but it is still a solution limited to the definition of business rules, conditions, and more complex expressions.

In short, at KuFlow we believe that workflows should be defined through source code. And for this, we have found the perfect workflow engine: temporal.io (we suggest reading carefully the temporal conceptual documentation).

What are the advantages of using Temporal as our workflow engine? According to Temporal's creators:

Temporal provides a holistic approach for implementing long-running Workflows. Workflow execution is paused and resumed by the runtime as required. Developers no longer have to focus on edge cases and boilerplate code that handles long periods of inactivity, and can instead concentrate exclusively on business logic.

Temporal has direct support for asynchronous events (aka signals). Temporal's simple programming model handles a lot of complexity around state persistence and ensures external action execution through built-in retries.

A sophisticated Workflow may have a few different paths that branch out, that you want to execute in parallel, but then join them back together, even if each track might take days to run. With Temporal, it's straightforward to express complicated decision paths since everything is represented as code rather than via a GUI or JSON configuration.

Therefore, within KuFlow, each workflow will be implemented as a workflow worker.

Workers

To implement the interactions between a workflow and a system (command and query interactions) involved in the process, we have chosen to create an intermediate system that is responsible for receiving the tasks and ensuring that the target system executes them correctly. In our model, we call this intermediate system a worker.

Each worker is responsible for the following:

1. Receive the activities assigned to it (from the source systems).
2. Act on the target system to carry out the task.
3. Report the result of the task execution.

Once we have decided to go with Temporal, it is obvious that the workers in KuFlow will be implemented by Temporal Activity Workers. This means that magically we have SDKs in different programming languages to create the workers (there are SDKs for Java, Go, PHP, Node, Python and .Net).

In the case that a system needs to inform the workflow of an event, the chosen mechanism is to make use of Signals in the Temporal workflow workers.

In the case that a workflow needs to inform a system of events that are occurring in the process, the chosen mechanism is to create Webhooks within KuFlow. Through this mechanism, KuFlow issues notifications to external systems.

Processes

So, what does KuFlow allow you to do? It allows you to define workflow-based processes that are responsible for creating and assigning tasks to humans, informing humans of relevant information, and interacting with other systems. All this in a resilient, scalable, and sustainable way.