The more people understand the blockchain, the more we will see a proliferation of useful cases around 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 into 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 for their users (e.g. Facebook understood really well the concept of sharing), while large enterprises have ambitious change management challenges ahead of them in order to get blockchain projects moving.

The blockchain as another kind of database is a popular analogy that has been used a lot, especially after I wrote more about two years ago, The Blockchain is the New Database, Get Ready to Rewrite Everything. In reality the blockchain doesn’t disrupt databases, but it disrupts how databases get synchronized between each other. Image two entities (e.g. 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, and 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 be messing with 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, losing track of versions, and not being in sync with the other version, 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.]]>