Notes on cross-company business processes

Modelling business processes intern in a company might be totally different as speaking about processes between different companies. The reason for that that companies are built up based on different departments and the major challenge of a corporate business process is to describe the information flow of the department. If we speak about cross company processes however they have a little bit different characteristics. Companies working with each other mostly based on markets, either based on general free markets or some kind of a limited market. Another important difference is that information can not free flow freely, it has very strict private characteristics. As a result, if we want to define cross-company business processes we should much more concentrate and model the markets that are connecting the different enterprises. 

Creating a simple task for an approvement workflow on the Ethereum Blockchain

Let we assume that we want to implement a simple approvement workflow, practically containing one user task with a responsible person to be approved and there are three possible outcome of the task: approves, declined or delegated. For the sake of completeness, we assume that functionalities for logging and access method control are already available, as we described them in the previous blog, The approvement process has one special information field in our example ApprovementInformation that is the information to be approved. In real case scenarios this information is best realized by an explicit smart contract. 

The implementation is pretty much straightforward. The state is stored in the workflowState variable and modified by the Approve and Reject functions. Responsible person of the workflow is stored in the WorkflowResponsible variable; in current implementation only responsible person of the task can accept or decline, however everyone with a write access is allowed to delegate the task for someone else.   

Serializing state into the Blockchain in Decentralized Business Process Management

Well serializing state for Decentralized Business Process Management (or simply DBPM) does not seem to be very complicated for the first sight If we consider Ethereum as a Blockchain solutions. Let we assume that we have custom workflow for approving a project budget, having the following properties: ProjectName, ProjectType, ProjectBudget.The first intuitive realization is a simple smart contract, called WF_ProjectBudget having the three properties as parameters and having a set get function for each: 

contract WF_ProjectBudget
{
 string ProjectName;
 string ProjectType; 
 int ProjectBudget;
 
    function setProjectName(string _ProjectName)
    {
        ProjectName = _ProjectName;
    }
    
    function getProjectName() constant returns (string)
    {   
        return ProjectName;
    }

    function setProjectType(string _ProjectType)
    {
        ProjectType = _ProjectType;
    }

    function getProjectType() constant returns (string)    {
        return ProjectType;
    }
    
    function setProjectBudget(int _ProjectBudget)
    {
        ProjectBudget = _ProjectBudget;
    }

    function getProjectBudget() constant returns (int)    {
        return ProjectBudget;
    }
}

There is a problem however with this intuitive approach. As the parameters can be set one by one, there is no guarantee that they will be set in an atomic action, meaning that either all of the values change or none of them. Supposing that atomic action is required saving the workflow state, the following code might describe the situation better:

contract WF_ProjectBudget
{
 string ProjectName;
 string ProjectType; 
 int ProjectBudget;
 
    function getProjectName() constant returns (string)    {   
        return ProjectName;
    }

    function getProjectType() constant returns (string)    {
        return ProjectType;
    }
    
    function getProjectBudget() constant returns (int)    {
        return ProjectBudget;
    }

    function setWFState(string _ProjectName, string _ProjectType, int _ProjectBudget) {
        ProjectName = _ProjectName;
        ProjectType = _ProjectType;
        ProjectBudget = _ProjectBudget;
    }
}

It is important to note that although the construct seems to be pretty simple, it guarantees that the three values are set in an atomic transaction independently of any kind of possible errors, like network outage, validation node failure or heavy cyber attack.

In real life scenarios we should consider that not always the whole state but only a part of it is saved in a transaction. As a consequence, it might make sense to explicitly define atomic groups: group of variables that should be serialized together. Another drawback is that this model assumes the one contract - one workflow model. A more general model might be to work with structs instead of individual variables, in this way one general solidity contract can contain the storage interface for several different workflows:

contract WF_State
{
    struct ST_ProjectBudget{

     string  STProjectName;
     string ProjectType;
     int ProjectBudget;

    }

    ST_ProjectBudget LatestProjectBudget;

    function WF_State(string _ProjectName, string _ProjectType, int _ProjectBudget)
    {
        LatestProjectBudget = ST_ProjectBudget(_ProjectName, _ProjectType, _ProjectBudget);
    }

    function getProjectName() constant returns (string)    { 
        return LatestProjectBudget.ProjectName;
    }

    function getProjectType() constant returns (string)    {
        return LatestProjectBudget.ProjectType;
    }

    function getProjectBudget() constant returns (int)    {
        return LatestProjectBudget.ProjectBudget;
    }

    function setWFState(string _ProjectName, string _ProjectType, int _ProjectBudget) {
        LatestProjectBudget.ProjectName = _ProjectName;
        LatestProjectBudget.ProjectType = _ProjectType;
        LatestProjectBudget.ProjectBudget = _ProjectBudget;
    }
}







  

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.  

Competitive Analysis for Decentralised Business Process Management

Competitor landscape has been analysed with the help of two frameworks. Figure 1 uses the classical ambition matrix positioning Decentrlised Business Process Management or simply DBPM as a rather further out than closer in innovation. We positioned multiply version of DBPM on the market segment, because creating a cross-company business process between two companies should not necessarily be regarded as a new market, perhaps not even emerging. However creating business processes between companies, individuals and IoT devices surely manifests as a new market segment.

Figure 1. Industry and competitive analysis with ambition matrix

Figure 2 summarises the competitors on a rather architectural way concentrating on two dimensions:

1.  At the dimension of high trust architecture the question is if the technology is based on Blockchain, providing a scalable high-trust architecture by design, or on a classical client-server framework (or perhaps old fashioned mainframe).

2. The diversity of actors analyses how many different parties should be considered for a business process, ranging from a one-company process to the processes of multiply companies, individuals or intelligent gadgets.

Figure 3. Solution segmentation

Based on the two orientation diagrams as well, we would argue that enterprise ready classical Business Process solutions should be regarded as direct competitors of DBPM. They do not necessarily focus directly on a cross-actor market, apart from some examples like Kofax, but enterprise ready basically means that they can be extended with some further development on a cross-company or even cross-intelligent gadget scale. For example some of the ‘big players’, like Oracle, IBM, or SAP implement cross-company functionalities as well. However on the one hand they are not based on Blockchain solutions on the other hand they require that the same solution is installed and licensed in all of the trusted companies, like SAP processes between subsidiaries of a company. Enterprise business process solutions can clearly compete on a markets where processes between a few previously trusted companies should be implemented, but they will have the weakness as soon as processes between a larger numbers of untrusted actors should be set up.

As indirect competitors we regard the whole smart contract market, including general platforms, like Ethereum, Counterparty (Bitcoin based smart contract system) and systems like Hyperledger. These platforms clearly provide the possibility to set up trust between different untrusted actors based on smart contracts and Blockchain, however they have rather a general focus and not a BPM specific one. As an example a specific decentralised business process can surely be implemented as a set of hard-coded smart contracts, but hard-coding one such a company cooperation is completely different from providing a whole platform on which such processes can be practically clicked together. Nevertheless the risk that someone develops a competing solution on top of these frameworks is surely bigger than zero.

Companies who do something in the direction of multi-party trust system or business rules can be regarded as potential competitors. The range is here pretty big, starting from business rule engines like Decision, through digital business logic platforms like Drools, to general IoT solutions, like Ritc. They seem to be pretty far from DBPM at the first sight however they have a similar and strong technology basis that can be further developed in the direction of decentralised business process management without too much effort.

Based on the previous analysis our competitive strategy is based on two major building blocks:

1.  Decentralised processes among large number of possibly different kind of untrusted parties, including companies, individuals and intelligent gadgets.

2.  Low code solution in cooperation with local consulting companies of different industrial fields, making possible that decentralised processes are set up directly by the local experts of a certain field or even by end-customers in a self-service way.

We see that the market is pretty much in the emerging phase, hence the strategy is based on segments, like IoT communication that are emerging markets themselves. As a consequence we see the market and our competitive strategy as a blue ocean one.

Financial Framework for Decentralised Business Process Management

Setting up a financial framework for analysing DBPM (Decentralised Business Process Management) we are going to use the following considerations: 

From a unit economical point of view the most important element that directly carries the cost and indirectly generates revenue is an atomic t transaction. A p process is set up as executing and validating a sequence of t transactions.

In the business model, we distinguish two levels of the business. Core platform is responsible for executing decentralised transactions and processes. On the top of the core platform industry specific solutions can be delivered with the help of partner companies. On a long run industry specific solutions could be implemented directly by partner companies, however it is probably not realistic on a short run. As a consequence initial financial models consider both the development of the core platform and some of the industry specific solutions.
Costs structure is based on the following elements [Figure 1]:

1.    Variable cost:

a.  CoGS is mostly based on executing and validating the transactions on a decentralised consensus. It can be easily scale up or down depending on the customer needs. As opposed to a general Turing complete Blockchain system where executing a transaction might be pretty expensive due to the possibility of the infinite loops, at DBPM runtime of the atomic transactions are always limited from above, implying O(|T|) execution cost for a set of T transactions. The exact cost pretty much depends on the consensus mechanism, implying different numbers at proof of work, at proof of stake or at majority voting.

b.  CoGS is also influenced by storing the states of the validated transactions of a p process. It is manifested as a general storage cost that will be increased as the process itself is used. It requires further considerations if the whole state between two transactions is directly and fully stored in the Blockchain itself or rather off-chain solution might be used and only hash of the state is stored in the Blockchain.

c.  Supporting the system to partner companies or end-users is manifested as an additional variable cost.           

2.   Fix cost factors are mainly the SG&A expenses for running the company itself. As the primary focus is on the partner business, the most important is the professional business development as CAC.

3.    Investment: For a successfully start both the core framework and the first two or three industry specific solutions must be ready. They requires a certain amount of development and initial investment.

Revenue structure has the following factors [Figure 1]:

1.   Core services: customers get the value of using a certain business process itself. As executing a business process practically means executing a set of state changing transactions, it makes sense to charge money after transactions.

2.     Extended services might be possible as well, as providing training or consulting. It might be however a possibility that the company concentrates only core functionalities and every extended service is provided only by partner companies.

Figure 5. General cash-flow schema.

Business Model for Decentralised Business Process Management

Decentralised Business process management or simply DBPM is intended to be a strong infrastructure oriented solution, business model is based on an intensive partner network. The platform is not planned to be sold directly to the end-customer, instead partner companies having the industry specific know-how set up solutions on the top of DBPM [Figure 1]. A more detailed description of the ten types of innovation is covered in chapter plan as general operation model.

Figure 1. Business Model with Ten types of innovation

As DBPM is based on a Blockchain protocol, both cost drivers and profit should be based on transactions. It is certainly a question which digital consensus is applied, at Poof of Work model each transaction or block validation cost directly a certain amount of energy and money called the mining. At Proof of Stake or at general consensus mechanism like voting at Ripple rather a general hosting and participation cost is manifested. In any case profit model should be based on charging the customers after usage for individual or branch of transactions.          

From the network perspective DBPM solution would not be offered directly to the end-customers, instead the service would be sold with the help of strong B2B cooperation via partner companies. Examples can be:

-   consulting companies for setting up cross-company contracts and processes
-   IoT solution providers for setting up decentralised processes between hardware devices, for example for smart-homes.

Structure and process of the DBPM company would be pretty much similar to the classical enterprise software vendors. The core solution is continuously developed; based on the core solution industry specific features are developed. Instead of internal development, a possible way is to work with a strong open source community and develop the framework either with freelancers or with partner companies, just as at Ethereum Foundation. Another aspect that must be taken into consideration is the Network of hosters or miners who actually run the whole system. Depending on the Blockchain solution miners and hosters are paid in either by an internal cryptocurrency system or directly based on revenue.

In the middle of the product performance the core platform can be found: A decentralised P2P process management platform, in which each workflow state transition is validated by a consensus of the whole network. Apart from the core, the product system will contain industry and branch specific solutions and features.

One of the most important feature from a customer point of view is that DBPM is a no-code solution. It means that business processes can be ‘clicked’ together; in most of the cases no software developer is required. It makes a strong impact both on the service and on the customer engagement side. As a consequence of no-code development, distributed business processes can be directly built and modified by the knowledge workers of a specific industry. In this way rapid solution development and continues process improvement can be realised, instead of having long-running development life cycles. 

As a consequence of no-code development, sales channels are the best to realise in cooperation with local consulting companies. As an example on of the Big Four or Big Three companies can be an excellent candidate to use DBPM with local consultants realising indirectly common sales channels as well.

Branding must suggest the core business idea in a way and must suggest a strong and stability. From a technology point of view, name of the core technology can remain DBPM however it is adequate only for strong technical audiences.

Decentralised Business Process Management

Reaching slowly to the second machine age, cooperation and trust between different actors will be an always increasing problem. We did have previously difficulties as well as processes had to be set up including several companies but the situation will be much more challenging as several million more or less intelligent IoT devices start to communicate with each other.

Decentralised Business Process Management (or briefly DBPM) is a customisable process management platform to set up workflows among different untrusted parties, independently if these parties are companies, end-users, end-customers or intelligent gadgets of the IoT revolution. The processes are set up on the top of a Blockchain, as a consequence trust is evaluated by the decentralised consensus itself, making possible to implement complex trust scenarios among many fundamentally different actors. DBPM provides a no-code or low-code way of configuring processes, meaning that most workflows can be clicked together with the help of a web based tool. It implies on the one hand that end-customers without prior development or deep IT knowledge are able to customize processes on their own. On the other hand, consulting companies of different industrial fields are able to set up industry specific process solutions as well; again without the need of coding or deep IT know-how. 

Considering current achievements and technological platforms of the Blockchain Revolution , setting up a DBPM framework and the full business around can be feasible from a couple of million dollar financing.   .