Recently a colleague and I shared a Dell Technologies' Blockchain point of view to a group of financial services companies. One of the key pieces of feedback we received was the concerning lack of standards when it comes to building a distributed ledger.
Should we use Ethereum? Hyperledger? Corda? Chain? Multi-chain? What are the performance implications of each? How will we interact with different chains? How are smart contracts deployed? How do applications call these smart contracts? Do we consume Blockchain-as-a-service? Should we build our own?
The permutations are numerous.
One of Dell's partners in this area is the MIT Digital Currency Initiative. I recently had an engaging conversation with Director Neha Narula, during which she stated that the answer is a truly interoperable platform that is not controlled or pushed by one company. She believes that the current state of Blockchain is equivalent to the pre-web 1980s internet. We need Blockchain protocols to emerge that are the equivalent of HTTP and TCP/IP.
These views seem diametrically opposed. Should companies dive into first-mover Blockchain implementations or should they wait until the standards evolve?
My opinion at this point is to ask a different question: what business advantage are you seeking by interacting with a shared ledger? When we ask this question we see three different responses:
- We believe interaction with a shared ledger can increase our revenues.
- We believe interaction with a shared ledger can cut our costs.
- We believe interaction with a shared ledger can reduce our risks.
For example, one company we spoke with mentioned that when they accepted Bitcoin payments they saw a bump in revenue (item #1) along with an increase in new customers. They had modified their ordering platform to interact with the Bitcoin Blockchain and this resulted in business advantages.
When considering the introduction of "shared ledger business logic", I believe the best starting point is highlighted by the diagram below.
The first step is not to figure out which ledger to use, or whether to build it on-site.
The first step is to figure out how to write and deploy the business logic in a way that (a) most quickly realizes the business advantage (e.g. revenues, cost, risk), while (b) future-proofing the code against potential ledger changes.
Once a coding and deployment approach has been decided, a logical next step would be to consider how to best program the ledger to the needs of the business logic.
During the next few posts I'll dive deeper into this top-down approach. What we'll find is that the specifics of the business logic will dictate whether or not to be aggressive in the use of Blockchain technologies or to be patient and leverage existing (non-Blockchain) approaches. If the Blockchain approach seems most prudent then there are an interesting set of questions worth answering about the business logic:
- Are there emerging technologies and standards that normalize Blockchain implementations? [there are]
- What is the interplay between the business logic and smart contracts? Are they both deployed as part of the same framework? [they should be]
- Are there emerging technologies and standards that facilitate interaction between multiple Blockchains, and how can the business logic access this functionality?
- How is identity management (e.g. the use of private keys) leveraged by the business logic?
- How does the business logic handle references to off-chain data assets? [which are typically not stored on the ledger itself]
All of these questions must be considered as part of the application design. Even if the business chooses to go all-in with one Blockchain platform (e.g. Ethereum), all of the questions above should be considered.
More importantly, no matter what choice is made, the business logic should be delivered using cloud-native principles (e.g. test-driven development and continuous delivery). In an upcoming post I will touch on many of these points and also discuss a layered architecture for shared ledger business logic.
Steve
Comments