Free advice can be valuable… but only if you take it

If a client tells you your solution doesn’t solve their problem, it may not be the problem that needs to change…

I often argue for the importance of blockchain and distributed ledger technology by using the following chain of logic:

  • Bitcoin’s architecture solved the problem of censorship-resistant digital cash
  • But few, if any, financial firms are interested in censorship-resistant digital cash
  • So why are they looking at this technology?
  • Because some principles underpinning Bitcoin’s architecture – shared ledgers, for example – could be relevant to problems that banks face.

Sure, a blockchain or a replicated shared ledger could indeed be useful to banks. Perhaps it could reduce the need for reconciliation between firms if they all ran off a single ledger, for example. But this says nothing about whether blockchains are the optimal solution to any particular problem in banking.  That still has to be argued, of course.

Recall: the bitcoin architecture was a solution to a very specific, very carefully framed problem – how to transmit value without the risk of censorship. Just because the underlying architecture could be used to solve some pressing problems in banking doesn’t mean it’s the best way to do so. Indeed, although the interlocking aspects of the Bitcoin solution are in some ways quite elegant, there are also some compromises. After all, it is an engineering solution to a set of very specific constraints and so it has to be demonstrated that it’s the right solution when the constraints are different.

Lee Braine, of Barclays Investment Bank CTO Office, made an important contribution to this debate when he spoke at London Blockchain Conference 2015 recently.  The video is now available and I urge anybody working in this space to watch it and to internalise its message.

[vimeo 137190236]

We all too often “talk past each other” in the distributed ledger world and we are quick to assume the other person just “doesn’t get it”.  I can assure you that Lee does get it and it would be a brave startup in this space that chooses to disregard what he said. He’s giving us free advice! Take it!

Like I say, watch the video for yourselves.

I think another way to capture the chain of logic in the video is as follows:

  • Assume the ongoing interest in the application of blockchain technology continues
  • Assume further that some banks identify some compelling business opportunities in deploying a cryptographically-secure shared ledger between themselves.
  • What is the probability that a derivative of Bitcoin or Ethereum or any other current platform will be the best solution to that specific problem?
  • Given that none of them were invented to solve that problem, surely it’s quite low, right?

So we could find ourselves in the situation that bitcoin and blockchain technology have catalysed an orgy of activity, that this activity has identified countless high-quality business problems and yet none of those opportunities are best addressed with the technology that triggered the excitement in the first place!

The theme of this blog is “free advice” and the free advice I’m taking from Lee’s comments includes:

First, we shouldn’t get enamoured by a particular implementation of a technology. Sure: if you have an implementation then you may have bought a place at the table.  But don’t make the mistake of assuming that if the business problem doesn’t fit the technology then it’s the business problem that needs to change!

Secondly, if you’re working in a financial institution, be careful to distinguish between the principles embodied in these technologies. Shared ledgers? Yes. That seems to be at the heart of this domain. Indiscriminate replication? Perhaps. Cryptographically-secured access down to the “row” level? Probably. And so on.

Thirdly, consider the complexity of banks’ existing IT environments. An idealised, “wouldn’t the world be perfect if…” solution is no use to anybody if it requires the whole world to move at once and/or if there is no credible migration path.  This points to a need to listen to the incumbents when they object.  Furthermore, consider the non-functional requirements which are simply a given in this space.

Fourthly, if we assume that today’s current hyperactivity will lead to a new understanding of the possibilities for banks but don’t assume that today’s blockchain platforms (permissioned or permissionless) are the (whole) answer, then surely we’re back in the land of engineering, architecture and hard work? Perhaps this means that the combination of persistence, data models, APIs, consensus, identity and other components that we need won’t all come from one firm.  So a common language, some common vision and an ability to collaborate may become critical. Where is your distinct differentiation? Where would you fit in an overall stack?

Advertisements