7 Things Businesses Should Consider Before Starting A Blockchain Project
Blockchain has come into the radar of many businesses due to its distributed ledger, immutable records, transparency offered with utmost security and extensibility. Even though the adoption of blockchain has picked up pace, businesses are still skeptical to start a blockchain project, initiative or practice. So, what is the reason for this hesitancy? What are the factors that need to be considered by the businesses before embarking on Blockchain initiatives?
- Use case: The truth is most businesses look for a good and valid use case that can be implemented in a private, permissioned blockchain. A use case is a scenario that the business is currently seeing in their daily flow of activities, which when transported to a blockchain will return them a better ROI, by leveraging most of the benefits that the blockchain has to offer. Hence businesses should analyze the blockchain worthiness of the use case before implementing.
- Partners: In pretty much all scenarios a blockchain project cannot be successful without partners. These partners could be external to the enterprise or internal. Each Partner and their users become players in the blockchain use case. Usually, partners who want a use case to be implemented across their enterprises (external) or departments(internal) join together to form a consortium and implement the use case. The data stored in distributed ledgers of such blockchain projects is shared across all the partners.
- Security and Privacy of the Blockchain Platform: Blockchain infrastructure and data should be secure. Privacy of data should be maintained. Any platform which does not offer these 2 important goals would be a failure. Data from the partner nodes should be able to reach the distributed ledgers of each node of each other partner without any hacks or security breaches. So, both the external blockchain network that connect the partner nodes and the internal network that connects the partner node to the distributed ledger database should both have airtight security with no gaps. Data itself needs to be properly encrypted and stored in distributed ledgers.
- Deployment architecture: The blockchain network should be able to connect partner nodes across various clouds and on-premises network topologies. This is because each partner can deploy their blockchain node in any deployment environment of their choosing like private cloud (own data centers, contracted data centers), public cloud (AWS, Azure, GCP, IBM, Oracle etc.), on-premises. A blockchain platform as a service that can accommodate all these deployments across all partner organizations would be the ideal choice that businesses would want to go with.
- Interoperability with Smart Contract, APIs and Distributed Ledgers: The next big factor are the Smart Contracts and Distributed Ledgers. Smart contracts need to be logically structured so they can interact with Distributed Ledger at one end and the distributed applications (dApps)/APIs on the other end seamlessly with proper validations. Each partner can have their own smart contract interacting with the blockchain network for a use case that was agreed upon between the partners. The data resulting from the use case transaction executed by each partner’s user agent or API, via the Smart Contract gets stored as transaction data in blockchain distributed ledgers.
- Distributed Applications (dApps): This leads us to the creation, deployment and integration of distributed application (dApps). These apps are going to call the smart contracts in order to push data into or pull data from blockchain ledgers. Normally these are extensions of existing applications. A well-orchestrated extensible mechanism needs to be thought of by each business before they try to alter their existing application to make a robust distributed application module (dApp Module).
- Availability, Performance and Auto-scaling: This factor is critically important for the long-term prospects of the blockchain use case in question. If a proper Disaster Recovery strategy and container-based (Kubernetes or equivalent) performance and autoscaling strategy is not devised from the beginning of the project, the blockchain network cannot sustain especially when more nodes get added to the project. Each partner should be looking at making their blockchain assets available always to the network as much as possible.(The author is CTO, SecureKloud Technologies Limited and the views expressed in the article are his own)
add a comment