Modelling IOU contracts on the Bitcoin blockchain

One way to model an IOU contract on the Bitcoin Blockchain is to send them as a transaction with timelock. It practically means that the contract can not be mined if the time is earlier than the given timelock, with other words it works indirectly as a promise that I will pay a certain amount of money after a certain time. However, it does not work exactly with the same logic as a normal IOU contracts. The problem is that this transaction is not really in the blockchain itself, but only in a transaction pool, which means it can be overwritten any time with a double spending and after the given timelock it is only up to the miners when exactly the transaction will be placed into the blockchain.  

Blockchain as a management or leadership philosophy

"Agile leadership", "Agile management", "Data-driven leadership", "Lean management", "AI in leadership", "How AI will redefine the management", "Lean Leadership" .... Business and management philosophies seem sometimes lack of the original new ideas, instead they borrow ideas from the technology field and try to adapt somehow to an absolutely other field. Classical nowadays example is the Agile leadership and Agile management, which has got the original root in the software development, however it is widely used from classical project management to leadership philosophies with more or less success. Similarly lean, or 6 sigma were actually rather special techniques for production until they were adapted to a broader audience. AI (Artificial Intelligence) and machine learning have been starting to appear in the technology hype phase, however there are already initiatives to define data-driven leadership, and there is brainstorming as well to define AI in leadership.

Surely, there will be initiatives to adapt Blockchain or rather in broader aspect decentralization as a management, business or leadership philosophy. Actually, we have already seen the first initiatives, the DAO (Decentralized Autonomous Organisation) that were trying to replace some of the core management functions with smart contracts. Unfortunately the project was hacked, as a consequence the initiative did not really reach the Hype phase. However, the DAO is only one part of the spectrum. As it is possible to replace most of the core management administration and coordination with smart contracts, it is still pretty much an illusion to automate everything from leadership to doing business. On the other hand, management and leadership philosophies are simply products that are sold among the others to managers and leaders, so automating everything might not be the best selling argument for some of the target groups. 

As a consequence, I am sure that Blockchain or Decentralization will appear as a general management or leadership philosophy as well that has got the roots in the technology field itself but will adapt most of the ideas. How will this new philosophy look like ? Well, we can only guess: It will be probably prefer platform thinking, it will automate most of administration tasks with smart contracts (and hopefully rather with gamification than with some boring administrative tasks), it will be exponential, it will consider non-humans as well both and employees or as customers .... 

If it generally make sense to have decentralized management or leadership philosophy? 

That is actually a pretty good question but considering the recent Blockchain hype, the general philosophy side will appear, independently if it makes sense or not. Just as Lean, Agile and Data-driven have been already appeared on the management and leadership philosophy side. 

On the economy of a goldrush

It is interesting to analyse the economy of a gold rush considering the two fundamental different roles who were taking part in the rush: The gold hunters and the shovel sellers.

The gold hunter: is motivated to find gold, to find the big business and for that takes a big risk and works (or realizes a negative cash flow) on a long run. If the gold is found or the business is succeeded then the return can be really big. On the other hand relative few of the people really found a big amount of gold.   

The shovel seller: is selling simply shovel for the people who are hunting the gold. It produces a stable low income on a long run, without the real possibility to get a big business very fast. Certainly the shovel seller is motivated that the gold rush is 'going on', as more people think there is a possibility to find gold, the more shovel can be sold. In this sense the shovel sellers market does not depend on the actual gold market but on the expected gold market. 

Figure 1. Cash Flow model of the gold hunter and shovel seller

Figure 2. Risk - Return diagram of the gold hunter and shovel seller

How to build up consulting business based on the technology Blockchain

Considering the fact that Blockchain is in the Hype phase it is important to analyse the possibilities how consulting business can be built up based on the technology. If we consider the standard consulting business, Blockchain has more or less similar characteristics as the standard technologies:

- Infrastructure: Infrastructure consulting is relevant if we consider private or corporate Blockchain solutions. In these scenarios it is important to analyse how many P2P nodes should be set up, where should be these nodes set up considering the internal corporate networks and firewall settings. In case of a public Blockchain solution infrastructure consulting is much less relevant. 

- Development: certainly the most important part of each application is the development. It contains on the one hand implementing Blockchain Apps, like Smart Contracts on the Blockchain, on the other hand related applications like web user interfaces communicating with the Blockchain. 

- Testing - Quality Assurance: This part is much more important than with standard software development as Blockchain applications usually planned to be highly secure highly available applications usually with strong cryptography requirements.  

- Classical Consulting: As the field is pretty complex general consulting is an important element of the area as well. Typically simply choosing the necessary Blockchain platform might be a complex issues, like choosing between Proof of Work, Proof of Stake, or public private or corporate Blockchain solutions. If low-code or no-code applications will be possible for application development, importance of the general consulting will be much higher.    

Towards unmanned software development and delivery

In the good old days custom software projects were simply. there were some kind of an initial interaction with the customer called as specification or analysis then developing and architecting a solution and at the end some kind of a delivery. Independently if the project was running in a classical waterfall style or something more fancy agile style  software projects had the following roles:

- Business Analyst / Industry Business Consultant: to help for the customer to create / update / finalize the specification.

- Software Architekt / Developer : to implement the software itself.

- Infrastructure expert: to deal with special infrastructure oriented questions.

- Tester: to quarante software quality.

- Project Manager / Scrum Master: to coordinate the whole process.

- Sales: selling the software.

In the meantime complex development frameworks appeared as well making a custom software development from the end customer point of view simpler, usually reducing the development efforts and making possible a much faster agiler and bug-free software delivery. Typical examples for these frameworks:

- Rapid application development frameworks: these are practically rather development oriented frameworks that make the coding much faster, implying in less coding resources. Examples were for instance the Enterprise Library for .NET framework.

- Complex Business Solutions: There are a lot of initiative to provide a framework with many use cases out of the box, starting from the most common user and identity services to complex business applications or apps implying reduced again the need for reduced resources in the classical technical coding - testing fields. Example is Odoo Business Apps.

- Self-Service Solutions: Last but not least there are many solutions that work in a self-service manner, providing the possibility for end-customers without prior development or even IT knowledge to build up software applications themself. Examples are elements in the Azure cloud, like PowerApps or PowerBI.

Certainly there is a catch using these frameworks. Even if they are theoretical self-service or providing a lot of functionality out-of-the-box, they reach in real life a highly increased technical complexity. So configuring these frameworks usually require pretty much know-how, as a consequence delivering solutions with such frameworks require highly increased IT consulting (Figure 1).

Figure 1. Roles and resources in different IT projects.

So the question is in which direction can we imagine the further development of custom software development and delivery, I think there are three major factors that should be considered:

- Sharing economy: As software are not necessarily developed from the zero but rather half-ready parts are configured together sharing parts of the software will play an always increasing role. Something similar is already happening on the cloud backend side, instead of individual software, everyone try to concentrate on creating and sharing (or selling) micro-services. On the other hand, certain software configuration frameworks like Azure PowerApps already contain built-in feature to share part or the whole application. It is important to note that sharing does not only make an application available, but the collected domain and industry know how as well. As an example supposing that I spent 20 years in the logistics field and I create and publish my custom logistics application then indirectly part of my collected domain know-how will be shared as well.

- Electronic Markets: Electronic markets are similar to sharing economy, making possible that the collected knowledge is used by someone else. Direct applications of the market can be selling and reselling building blocks of a software or whole ready to go solutions.

- Machine Intelligence: Despite machine intelligence is pretty much in an over-hype-cycle at the moment, it can be used to analyzing or refining specification of a software. Creating the first requirement analysis with machine intelligence is certainly difficult, although there are some attempts for that like in process mining. If a version of a software set up however it is simple to monitor the usage of the software itself, analyzing the data with machine learning and proposing a new better version of the software automatically. Example for such a framework is the Gird, fully automated web pages based on machine learning of web traffic.

- Robo advisors: To decrease the complexity of a configuration framework from an end-customer perspective and eliminate the need of IT consultancy Robo-advisors can be used. Although such advisors are more typical in the fintech field at the moment, it is not illusory to imagine that similar technology can be implemented in the software development branch.

So as a conclusion let we imagine perhaps in the not far future a classical software development example as an end-customer needs some kind of a custom software for supporting his business processes. Let we investigate which human resources and roles do we need for that:

- Do we need Business Analyst - Software Architekt - Business Consultants for creating and delivering a custom software solution ? Well, not necessarily, firstly ready-to-go software solutions can be bought via online markets or simply used via sharing platforms. If the end-customer does not find a ready ready solution, custom software solution configurations can be used in a self-service manner with the help of robo-advisors and machine learning to create the necessarily solution.

- Do we need Developers - Software Architects or Testers for creating and delivering a custom software solution ? Well, not necessarily, If we work with configurable software solution frameworks, most software is produced on a self-service manner. Certainly such frameworks have to be implemented first in a classical way, however if they are created already, concrete software solution development can be realized without developers, software architects or testers.

- Do we need Infrastructure experts for creating and delivering a custom software solution ? Well, not necessarily, if everything is hosted in the cloud than minimal infrastructure expertise is required.

- Do we need sales people for selling a custom software solution ? Well, not necessarily. if everything is sold via online markets and application stores than further sales support can be avoided.

- Do we need Project Manager for creating and delivering a custom software solution? Well, not necessarily, if we consider the previous points the only human in the software delivery process is the customer, so project management is not required.

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.   .