I am often asked for tips regarding project planning with blockchains. Translating from my safe zone, relational databases, to blockchain helped me immensely because there are differences in terminology and cost structures. The rest of this post presents some top-of-mind suggestions.

Estimating Costs

An important element of project planning is estimating the cost to operate the solution. With databases, the major costs are licensing and storage. Cloud-based services have made these costs easy to obtain. If you host the database in-house, there is still a cost to service the storage unit including operating maintenance such as backups and upgrades. Open-source products do not have a licensing fee but need to meet corporate production requirements.

Blockchains have a different cost profile than databases and there are two types of blockchains, each having different cost profiles. Public blockchains operate with tokens like a vending machine. Permissioned blockchains are supported by a consortium of companies who each agree to bear costs.

Although there is no storage cost for public blockchains, there are costs associated with deploying smart contracts and writing information to the blockchain. Both operations change the blockchain and “miners” are compensated for the math needed to ensure data integrity. Until recently, there has been no cost to reading blockchain data. With cost-recovery models, this is changing as data owners begin to control their data. Because the costs are paid with cryptocurrency, you will need to determine how wallets fit into the project. All costs are usage-based and are no monthly fees.

Permissioned blockchains allow a group of companies to collaborate and the cost structure is closer to database projects because each participant needs to support a “node” of the blockchain. There are maintenance operations for each node and changes require all participants to make changes at the same time. It would be unusual to have more than a dozen entities collaborating in one of these blockchains due to maintenece complexities.

Design Considerations

When I first started my corporate life, spreadsheets and databases were new. Because they share a “row and column” orientation, I could understand requirements quickly, especially if the business user could show me examples in a spreadsheet. I am still amazed at the results that advanced spreadsheet users achieve with “wired-up” spreadsheet-based applications. Finished applications include data integrity checks and handling for unexpected conditions, but the heart of the approach often comes from users.

Systems that react to stimuli or have complex, multi-step operations are good blockchain candidates. Workflow diagrams are more important than data diagrams because all interactions with smart contracts are made with function calls. Adopting an easy-to-use diagramming tool helps capture flow from the users. Be mindful to capture the semantics of the problem with the function names similar to the approach used for database stored procedures.

Data items in a blockchain do not have to have the same number of fields. Although this allows flexibility to capture different kinds of data, it makes query operations cumbersome. Exposure to NoSQL databases is helpful for this point. Arrays and other collection strategies compensate for the lack of a query language. I chuckle when I think that collections were part of my original coding exposure many years ago. SQL makes life easier on this point. If your application is query-heavy, then you might not want to use a blockchain in the first place. Blockchains are poor databases.

Timelines

A complicating factor for permission-based blockchain projects is that they always involve multi-company cooperation. The upfront investment in a governance document that identifies roles and responsibilities unifies the consortium towards common goals. There are technical tasks specified in the document but the tone is more at the business or legal level. A good tip would be to make large sections of work on the project dependent on having all parties agree on the governance document.

Public blockchains need to account for a longer implementation period because of the need to drive the system with real-time payments. If users do not have tokens, they cannot be serviced. This is less of a problem in business-to-business scenarios.

If the project has private on-chain data, the selection of blockchain is very important. The traditional blockchains (it sounds funny to say this) do not support private data, so you will be working with one of the newer blockchains.