Last Friday, June 15th, I presented at the grandly named "Blockchain in Banking Summit" in Madrid. A smallish conference (less than 100 attended) but of good quality. Here is my talk, I'll try to post separately my conclusion after watching the full day's proceedings.
Usual disclaimer: of course the content of this presentation does not reflect the official opinion of the European Union nor of the European Commission. Responsibility for the information and views expressed therein lies entirely with the author (me).
This is the point of view of a technologist, not of a regulator. Before doing blockchain, I used to be an enterprise architect. I would therefore try to look at the benefits large organization could derive from embedding the “blockchain pattern” in their information systems.
I did not focus on “money transfer”, nor on “clearing and settlement”, nor on KYC nor AML. Predictions like the one in the above picture are a dime a dozen. They will be forgotten, unless they become true, in which case those who made them will make sure we remember that "they were right".
Truth is, blockchain is actually hard to embed in large organizations with classical IT landscapes. Not because of the IT but because of its redefining the boundaries of trust
But let's start from the beginning.
By now everybody knows what a blockchain is. But what is a blockchain architecture ?
First of all, an infrastructure layer which is provider agnostic – you can deploy an operate blockchain nodes in your own data centre or on any cloud provider. That is powerful disintermediation – blockchain architectures have the power to commoditize cloud services. Instead of having a load-balanced, replicated, high-availability, Tier-IV system hosted by a cloud provider for, say "1000", you can install 8 regular, Tier-II with 4 different cloud providers (2 each) for the equivalent of "100" per system, because the price of the servers varies in a non-linear manner when climbing the "Tiers". If one of the 4 infrastructure providers tries to jack up its prices you can shop around for the best value without fear that your service will be interrupted.
Second, a replicated data base which you decided to share with your partners in a consortium – there is a huge IT benefit to be reaped, and that is semantic consistency: you design only one data structure which is common and every member in the consortium complies with it. Imagine the savings in data transformation and data reconciliation.
Third, the central, consensus layer. What are the pre-agreed rules about adding data and modifying the shared software system in the future? For permissioned, corporate blockchain systems, DPOS is practically the only workable model.
Fourth – the application layer, what is usually called “smart contracts” which, thanks to service orientation, can link and embed the blockchain system into the overall Information system of the organization.
Fifth, the user interfaces, which should offer a similar user experience with that of "non blockchain" systems. The user needs not even be aware that your system relies on a blockchain engine.
Ideally, you’d imagine a blockchain project that falls at the intersection of the three circles, but even when the project falls at the intersection of only two of them it is still worth considering.
Technical interoperability – there is one system that runs on several instances
Semantic interoperability – there is only one logical database
Economic mechanism design – the great blockchain innovation is the “token” which can be associated with value and transferred, tracked, divided, etc. It allows the modelling of debt and credible commitments. "A blockchain without a token is just a database"
Between companies, transactions are secured by contracts. Inside companies transactions happen based on commonly agreed rules, called business processes and do not require contracts. Each actor in a business process trusts that the previous actor will do what she is supposed to do. Each company represents a trust domain.
Blockchain consortia create new trust domains that span multiple companies. Consensus over transaction validity becomes algorithmic – this offers the possibility of lower transaction friction – more transactions, at lower cost.
However, many companies find difficult to change their approach. Therefore, I suggest a large organization might want to consider starting with non-ideal but still very useful learning constructs where they apply the blockchain patter to solve an internal organizational problem
In large organizations trust is often brittle, its span inversely proportional to the size of the company. This is well studied and documented.
Trust is often breaking between vertical silos because of the implicit competition between them, resulting from the pyramidal nature of the organization. You can replace “IT” in the image above with other support functions such as HR or budgeting and accounting
Organisations are “where actions are performed based on trust rather than on written contracts”. But the necessary trust that oils those internal transactions has been shown to decrease as the size of the organization increases.
“Activity Based Costing”, while conceived as a way to compensate is actually corroding trust further because it has been shown that exposing people to money changes their behaviour – where previously they were doing things for various non-monetary reasons, when money comes into the equation people start thinking “What’s in it for me? Am I going to make more or less money than before?”
Setting up consortia and doing economic mechanism designs while mastering the intricacies of consensus protocols, smart-contract coding and network setup is possibly too much to do at once.
This is why a gentler way to start is by trying to leverage it in order to strengthen employee engagement and organizational culture, by using it to support a “gamified process” with its internal token.
Usual gamification exercises have underwhelming results because it’s difficult to attach real value to the points and “badges” that they distribute to employees. Here the value of the internal token could (and should) be assigned from the very beginning. Whether it’s a special activity during the annual party of the company, a special gift at the X-mas party, free coffee until retirement or, even better, extra bonus or promotion chances.
If you think Pablo and myself are doing a good job, please approve @lux-witness as a witness!
