The more people understand the blockchain, the more we will see a proliferation of useful cases for it.
Just like any technology, those who invent it have not necessarily thought of all of its applications, which is why I believe that the best use cases are yet to come from a growing number of entrepreneurs and subject-matter experts that have deep expertise in a particular field or domain.
But, the first step is to have a fundamental understanding of how blockchain technology is different from what we are currently doing today.
Almost everything in life is about taking evolutionary steps.
Even the brightest startups need to understand the behavioral switching psychology of their users (eg Facebook understood the concept of sharing), while large enterprises need to prepare for the ambitious management challenges they'll need to navigate to get blockchain projects moving.
The 'new database'
The idea that the blockchain is another kind of database is a popular analogy that has been used a lot (I wrote about this subject almost two years ago). In reality, the blockchain doesn't disrupt databases, but it disrupts how databases get synchronized between each other.
Imagine two entities (eg banks) that need to update their own user account balances when there is a request to transfer money from one customer to another. They need to spend a tremendous (and costly) amount of time and effort for coordination, synchronization, messaging and checking to ensure that each transaction happens exactly as it should.
Typically, the money being transferred is held by the originator until it can be confirmed that it was received by the recipient.
With the blockchain, a single ledger of transaction entries that both parties have access to can simplify the coordination and validation efforts because there is always a single version of records, not two disparate databases.
Let's take that analogy further into the shared documents domain, and think about what happens when we share a document where two or more users need to make changes to it.
The traditional way of sharing documents with collaboration is to send a Microsoft Word document to another recipient, and ask them to make revisions to it.
The problem with that scenario is that you need to wait until receiving a return copy before you can see or make other changes, because you are locked out of editing it until the other person is done with it.
That's how databases work today. Two owners can't update the same record at once. That's how banks maintain money balances and transfers; they briefly lock access (or decrease the balance) while they make a transfer, then update the other side, then re-open access (or update again).
With Google Docs (or Google Sheets), both parties have access to the same document at the same time, and the single version of that document is always visible to both of them. It is like a shared ledger, but it is a shared document. The distributed part comes into play when sharing involves a number of people.
Imagine the number of legal documents that should be used that way.
Instead of passing them to each other and losing track of versions, why can't all business documents become shared instead of transferred back and forth? So many types of legal contracts would be ideal for that kind of workflow.
You don't need a blockchain to share documents, but the shared documents analogy is a powerful one.
This article previously appeared on Startup Management and has been reproduced with the author's permission.
Old way of sharing image via Shutterstock