Moving your business onto blockchain. A brief of the IBM guide
As some of you know, I offer different types of consulting services. One of the most widespread questions that I get asked, is how on earth to transfer your business onto blockchain?
Is it difficult? Is there a step-by-step guide?
Well, there is and there isn't.
First of all, a small disclaimer for the text below:
I personally have a vision, where only open-source, non-permissioned projects will evolve. However, I do believe in the need for educating people about blockchain, and that means that one needs to know, that there are many types of blockchains that exist, including permissioned blockchains.
I would also like to add, that in the correct hands, the below information can (and should) be applied to all types of businesses, willing to move their business onto blockchain (regardless of access type needed).
The information below is my interpretation (and a pick of the top points from the book) of an IBM handbook for moving your business onto blockchain.
The vast majority of the information is based on the research that IBM has already published, and should not be viewed as my own. I rather would like to give people a short brief of what is pointed out in that handbook.
First thing is first, one should understand the purpose of a ledger for a business:
- To reduce costs
- To reduce complexity
To understand what you need in a blockchain for your business, you should understand the following:
- What access type will be required?
- What accountability will you need?
- What level of privacy is required?
- What scalability level would you need to operate?
- What security issues might arise?
When you have the answers to the questions above, it's time to prepare the following things before you are able to launch your project to the public:
- Your idea (documentation)
- MVP
- MVE (E is for ecosystem here)
- Your team (and how you to motivate them)
- The total number of participants of the project is GREATER than its parts (From my experience, this is by far the best piece of advice ever)
In order to prepare the above, one needs to have more understanding of the following parts:
Identifying the problem:
- The real problem (not the one that is only local to you)
To do that, answer those questions: What? Who? Why? Repeat each time you feel the problem is not tackled enough - Draw a scenario map
- Think of the core components:
The type of your ledger \ How will you tackle asset transfer \ What will be the privacy level \ Is the trust level for all participants equal - Think out the TX process: from consensus to finality issues:
What if you need to reverse a transaction? How will you manage that? Will there be enough trust to solve this? Do you need to solve this?
Building the ecosystem
- You are solving the same problem within for all of the network's participants?
Does the solution bring equal value to all of the participants? - Get all the participants in 1 room. Discuss
- Decide who gets access to what information. Who are the actors and the players involved?
- Understand your shared value:
What are your costs \ user experience \ future opportunities? - PILOT - test it! In order to run the pilot, be prepared to answer the following:
Value - what is it you testing? \ Organization - how is the testing process organized? \ Standards - are there any? \ Usability (can everyone within the network use it? \ Future - where are you heading from here?
Мonetezation often comes as the biggest issue of any network. The irony is, that in order to find a solution, you first need to eliminate the need for it.
This means, that during early testing, where monetization doesn't exist yet, you can actually find and understand future monetization, based first of all, on cooperation and problem solving, rather than on “chasing after the money”.
Business model
(This is a difficult part to grasp without really diving into economic theory)
- Think of 3 types of models:
A public park, where rules apply but admission is global \ A nightclub, where permission might be required \ A membership club, for approved members only - Smart contracts:
Who is responsible for signing a contract? When? What level of trust is required? What are they needed for? - Token:
Access type for the tokens (what kind of tokens will you have)? Liquidity (how will you tackle it)? Ownership (do they provide you with something you own)? Security (is it a security)? Risk level (are participants risking anything when buying or selling, from an economic point of view)? - Understanding your own investment case & your own business model:
Map out the following: the costs of creating a network \ the needed fees to run it \ the profits that may arise
Always think of the possible ROI. This will justify the investment for your business and for the ecosystem - Going back to the 3 models above, keep the following aspects in mind:
A park is required a network growth, in order to succeed. A nightclub is pretty much the same but might require some additional costs, like building extra space. A members-only club usually works best with a fee-based model.
Keeping that in mind, also refer to the following:
Combinations of different types of business models will work best
Your network data costs money - when it's ready of course
Interoperability is vital for future growth
Governance
- What is the incentive for actors to govern? What mechanisms of coordination will be used?
- Try to answer who will govern the following parts:
Your data - its ownership & security. The marketplace - who will control revenue & network growth. Onboarding other members onto the network. Who governs the technology? Is it open source? Is it private?
Keep in mind that more control = more problems.
Who validates transactions (rather no one should do that)? Who governs the business logic? - What happens in case of system failures?
- Keep in mind that the less the ownership is centralized, the more dynamics the network will be
Legal
- Hire a lawyer
- Location, location, location - your business should be located where there are fit regulatory rules for it (if you need it of course)
- Encryption keys - who has access to what parts of sensitive information?
- What data should be kept on chain & off chain?
- Antitrust law.
If your network is permissioned are you price fixing? Can someone else fix results? - Intellectual property - who owns it?
- Use liability statements and waivers
