...by Daniel Szego
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Wednesday, January 4, 2017

Ways of decentralization for Decentralised Business Process Management

Considering Decentralized Business Process Management (or simply DBPM), one of the major question is which part of the framework should be decentralized and which should be not. The system has at least three layers (Figure 1), so let we see which one should be decentralized:

- Data Layer: Data is the state of the system tha has an initial state and a final one between all transitions. That must be saved into the Blockchain, it is one of the key characteristic of the  Business Process Management solution. However, it might be considered if all state between all transitions are saved or only certain ones, working as a checkpoint of the system. As an example, it can be imagined that cross-company decentralized processes save states of transitions in the Blockchain only if they deal  with cross-company communication. Local steps that are internal for a company can be realized independently from the Blockchain. 

- Workflow and Rule Engine: Well it is the major question of only storage should be decentralized or computation as well, like workflow or business rules. Having decentralized storage only without computation provides us clearly the advantage that workflow transitions run efficient. However, if the system is hacked in a way, then perhaps a state is written into the Blockchain that is already 'hacked'. It would be certainly a tragedy. On the other hand, keeping the computation decentralized might provide an enorm computing capacity. 

- Low code editors and API-s: Low-code, no-code editors are usually user interface components that should not be considered to keep decentralized. However, it is an open question how it is possible to avoid that the system is hacked and a wrong state transition is simulated. 

Figure 1. Possibilities for decentralization.

As a conclusion, the best option should be to provide a customizable solution, in which both elements of the state and types of the transitions could be individually parametrized if they should be saved into the Blockchain and validated by a decentralized consensus or not.