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.    

The dawn of Robo-Lawyers

Next target of the digital distribution might be the legal system especially consulting services of the legal systems. These systems are sometimes unnecessary over-complicated and required years of learning to get even the basic competence. It is currently in discussion rather with the  cryptocurrency regulations. However, apart from this field it is an interesting area to provide automated legal advisory services to everyone on affordable price.

Creating a simple job shop smart contract on the Ethereum Blockchain

Let we create a simple job shop smart contract. For the first run, let we create a smart contract called Job having some variables like description, responsible for the job, an internal jobID and a state of the job.

On the other hand, let we create a JobShop smart contract that practically uses a mapping for storing the different jobs mapped to a fictive primary key called jobID and having two functions for creating and assigning jobs for an account. 

  

After having the job task or job address, the job status can be set to done. In real life scenarios certainly this simplified functionality can be extended with for instance more variables, events raised if a job has been finished or with delegation and reporting functionalities.  

Analysing optimal technology choice for a project based on agile technology curve

Considering a usual enterprise software architecture, we can usually consider three phases: There is usually a setup phase of the technology that is pretty slow and expensive despite covers not too many use cases (Q1). Most software development frameworks have an agile part in the middle that provides the possibility to cover uses cases very fast very agile on a low cost basis. At the end, there is usually an architecture limit of the technology where the basic framework has to be further developed (Q2). A relative big effort is usually required to implement uses cases after the technology limit implying slow and costly delivery (Figure 1). 

Figure1. Agile technology curve and the performance of a project.

Let we consider the above curve from another perspective, let we consider a P project with a set of uses cases and let we analyse the question if a given T technology is an optimal choice for the project. We can say: 

- A technology is under performing for a given project or a set of use-cases if only a small part of the agile part is used. In this case the technology is simply not used enough, considering the pretty expensive set up phase. In this case another technology is perhaps a better choice.

- A technology is optimal performing for a given project or a set of use-cases if a large part of the agile phase is used to cover the use-cases, meaning simple that setting up cost at the beginning pays off. This case is the optimal technology choice,

- A technology is over performing for a given project or a set of use-cases if  many use cases are implemented outside the technology limit, meaning that the project will be probably unnecessary expensive and slowly delivered because of the use-cases outside the technology limit. In this case another technology is perhaps a better choice

- A technology is not performing for a given project or a set of use-cases if we do not use anything from the agile middle phase of the technology, meaning that after setting up the software framework, use-cases only outside the technology limit are implemented. In this case another technology is surely a better choice   

Creating a simple order process on the Ethereum Blockchain

Let we create a simple order workflow on the Ethereum Blockchain. The workflow imitates an order request, containing information on which material was ordered, how many items and on the order price. We define two smart contracts, on the one hand similarly to our previous example we define an ApprovementActivity. The activity realizes the usual Approve, Reject and Delegate functionalities as in our previous example, However the functionalities are extended with a callback function, that informs the original workflow as soon as the internal state has been changed. Additionally, there is an event that is raised to the client side, as soon as a new Approval set.

Code of ApprovementActivity is the following:

Workflow itself is realized by another smart contract, called OrderWF. The workflow is pretty simple, it is initiated with the necessary input parameters, sets the initial state and creates an activity to be approved. Communication regarding the state changed is realized by the callback function. As a second possible communication way a reference for the original workflow has been given over to the Activity, however this functionality is currently not used.

Certainly the process just an over simplified prototype version.  For a real scale solution additional functionalities should be built up, like reading the order details from the ApprovementActivity smart contract, working rather with groups than with individual addresses, fine tuning permissions and so on...   

Communicating with external datasource on the Ethereum Blockchain

Calling external API from a Solidity smart contract is basically not possible. However there is an indirect way to communicate with external data sources via internal variables, functions and events. Let we assume that we want to call an external API with three string parameters, parameter_1, parameter_2 and parameter_3 and expecting returning a ReturnValue string.  The only way to do it is to raise an event, implement and event handler on the client side to make the necessary call for the event and write the resulting variable back to the smart contract. 

A simple smart contract for the implementation can be seen int the followings:

 Certainly the template realizes efficiently only one call. If several calls are executed paralleled than further considerations are required.  

Several considerations have to be done however regarding security. One of the main idea behind Solidity is that everything is controlled by a decentralized consensus. If external data is used by a Blockchain application it is something that is not part of the decentralized consensus, implying a way for cheating or hacking the whole application. As a consequence extensive use of external data is surely not proposed for a Blockchain application. 

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.   

Combining data governance and permissions on the Ethereum Blockchain - a basic approach

As we have seen in the previous couple of blogs, there is a possibility both creating permissions on the Ethereum Blockchain and implementing basic data governance protocolls as well. Now we try to combine the two approaches into an inheritance hierarchy to cover both approaches. 

The simplest way is to define an inheritance hierarchy starting with the basic logging - governance functionalities. 

As a second smart contract let we define a descendant of the Governance smart that implements only the access modifiers. 

As the next descendant we define the administrative functions for giving access to a user. It is important to note that this functionality must already be set by the modifiers making sure that only accounts with the necessary right can set further rights. Considering governance, there is the possibility to monitor both the attempts of access and the succeed of access. It is realized by the AdminAccessRole input parameter in our example. 

Last but not least, custom functions can be set by the necessary modifiers, both ensuring that only the account with a necessary right can access to the functionality and to make sure that both the access attempts and the successfully attempts are logged. 

Notes on paper based business cards

Paper based business cards must extinct. 

They do not have any function, they do not have any usage. 

After getting the card you usually get the contact on LinkedIn and throw away the card.   

People meet, they have mobile phones they should be able to exchange business information simply by two clicking on the mobile phone. 

Paper is not required.
It is only a waste of resources,     

Basic data governance on the Ethereum Blockchain

Let we assume that we have several information on the Ethereum Blockchain and we want to realize some kind of a governance. For the first run, we want to collect and monitor the information who had access to some of the critical data and when. The easiest way is to implement an event type for logging. It provides both the possibility to log into a specific storage area and the possibility that the event is raised online on the client side (for instance in a javascript UI).

Triggering the events can be done the best by modifiers, like one for read and one for write.

Lat but not least, the functions that are critical, like access to the critical variable in this example can be extended by the modifiers. 

Certainly, the pattern works much better with inheritance, like implementing the modifiers in an ancestor smart contract and simply using them in a descendant contract. It is important to note that Ethereum is a public Blockchain. As a consequence, in this example even if getVariable is explicitly logged, there is a little bit hacking way to read out the information from the ledger itself without using getVariable.