Avoiding blockchain for blockchain’s sake: Three real use case criteria

2016 was the year of creating frameworks and filters to determine if a business problem was worthy of a blockchain-based solution.  Often, the frameworks would declare inappropriate potential use cases as ripe for blockchaining, as the frameworks were often designed by blockchain vendors or consultants to let as much through as possible.  However, many of the proofs of concepts built in 2016-17 have not become industrial solutions.  Why?

Two main reasons are:

1. The technology didn’t meet the requirements of the use case
2. The use cases themselves were selected badly

This post discusses what went wrong with use case selection, and presents two new and better questions for use case selection.

2016: Poor use case selection

Here are some common questions I saw in 2016, used to identify potential blockchain use cases:

• Do you have lots of participants?
• Is there data sharing?
• Does data need to be “validated”?
• Are there contracts?
• etc

However, these were poor selection criteria and were often based on a cursory look at the properties of Bitcoin’s blockchain and network, and then misapplied to other business scenarios.  For example:

Do you have lots of participants?

Bitcoin’s blockchain has lots of participants – about 5,000 validators called nodes, and about 10-15 miners who create blocks. The decentralisation is there because the Bitcoin network is designed to not have any known entity in control.  However for industry distributed ledgers where parties are identified and known, you don’t need lots of validators: efficiencies can be created immediately just with a distributed ledger between two participants.  You don’t need lots of participants for a distributed ledger to improve things.

Is there data sharing?

I have written about this before.  Data sharing is a solved problem: use a web-portal.

Does data need to be “validated”?

In Bitcoin, validation is narrowly defined: it means mathematically validating digital signatures and validating that a bitcoin being spent hasn’t already been spent.  Bitcoin doesn’t validate the “truth”.  Bitcoin doesn’t validate legal or moral assertions.  Bitcoin doesn’t validate the results of academic research (yes, I have seen a proposal for a blockchain use case where miners validate that academic researchers haven’t cheated with their results…).

Are there contracts?

Ethereum popularised the term “smart contracts” which made people believe in magic. Unfortunately, self-executing magic contracts only exist in Harry Potter.  The presence of contracts in a business network does not immediately mean blockchains or distributed ledgers are suitable.

etc…

There are many other filters and frameworks applied, many of them not helpfully.

2017: So what?  What now?

So how should we think about this technology?  When should we start to think “blockchain” or “DLT”?  It’s about shared control over data (not shared data), and assured multientity processes (not automating business workflow).

So here are three new questions where a distributed ledger could be considered.  They are a little more nuanced than the 2016 set.

1. B2B workflows: Are there bilateral, or even better, multilateral B2B workflows where each participant needs to independently validate the other participant’s data accuracy and/or processes?

A distributed ledger can give parties assurance that the data being stored and used by their counterparts is the same as the data they are working with.  The ledger won’t flag if a participant is being “truthful” or not (ledgers are only as good as ledger entries), but it will assure that the same data is being accessed by the participants.

Similarly, a distributed ledger can give parties assurance that the workflows between parties are being adhered to, and that each entity is running the same business logic, or at least coming out with results that are compatible with the pre-agreed rules of engagement.  In other words, proposed changes to ledger data follows pre-agreed rules.

Even with a distributed ledger, does each party need to validate the results of someone else’s calculations?  Of course they do.  It would be bonkers to rely entirely on someone else’s calculations.  The difference now is that the reconciliation comes before data is stored, rather than after.  I wrote about distributed ledgers being “confirm as you go” rather than “confirm after the fact”.  Switching the order makes a huge difference to operational risk.

2. Industry utilities: For the potential industry use case, could you imagine and design an industry utility that would make sense?  Why doesn’t it exist?  Perhaps it wouldn’t get traction because of political reasons around ownership: either because everyone or no-one would want to own it?

A distributed ledger, in some cases, could provide the answer – it avoids the problem of ownership and control of a utility.  Everyone participates in the sharing of certain types of data, and mutual validation of the data and multilateral processes, but the data itself doesn’t go through a single entity which has ultimate control over data passing through the network – the bottleneck has gone.

3. Is centralisation a risk?

Perhaps there’s a perfectly good centralised solution.  I have written previously about interbank payment systems and centralisation risk.  As cybercrime and cyberwars become reality, there is an immediate and urgent need to de-risk critical infrastructure systems that have central points of failure.  Investigating if a distributed ledger could be used in place of a central point of failure is an imperative for nation states.

Conclusion

The frameworks for use cases we were using in 2016 are no longer adequate, and as the global understanding of this new technology grows, we must evolve how we decide when to apply this technology.

I understand the reality of budgets, committees, and organisational politics: sometimes sprinkling a blockchain on an inappropriate use case can unlock budget to build automated systems that wouldn’t otherwise receive funding.  And that’s fine!

However, I have long been a proponent of avoiding blockchain for blockchain sake (B4BS).  The three criteria articulated in this article should help us think about determining real value-adding use cases that improve business and industries.