Blockchain for business : how to use distributed ledgers in an enterprise context

Roughly speaking, there are three approaches towards blockchain technology nowadays.

• You’re in it for the “get rich quick” scheme, and couldn’t care less about technology. #HODL is the name, trading the game. You probably have/want a Lambo.
• You’re in it do disrupt everything with decentralized apps (at a few thousand users a day) and are wild about technology. You probably have a cat.
• You’re in it from an enterprise context and although business is your focus, every day you have to answer questions about the technology as business users suddenly need to understand the stack before deciding. You probably have a boss.

My category is the last one. Going through the questions I receive, the “but what’s the added value of using a blockchain?” scores in the top 3. No one can tell me what the added value is of eating cereals with a spoon from a bowl, but for blockchain it’s important to figure out every detail and the possible revenues from not yet existing business models.

Well, it’s a struggle. There are few cases to compare with. The added value is hidden in ecosystems, in network effects. It’s hard to calculate when the system is already running (is profit generated because or despite the blockchain?), but even worse upfront. The equation to calculate the value contains many rather unknows : the technology, the partners, the final solution, the operation model.

So, let’s try a different approach. Rather than calculating a financial benefit, let’s take a look at how it changes the way companies eventually collaborate and exchange data. Let’s look at it from a risk point of view. As I studied Law, I always see value in taking away risks as it reduces the amount of possible outcomes with a negative impact.

A single company : no blockchain please

A single company has virtually no reason to implement a (private permissioned) blockchain solution, that’s not new. Why write the same data at the same time on different servers in your basement? Instead, they’re organised in a silo with several functions supporting the new gold, the data.

Within this company, let’s call it Business A, we see several items relevant for data and how to deal with it.

• We have the human knowledge on what actually happens in a process, and how data should be structured. People are usually able to correct data to their understanding.
• Internal processes, based upon human knowledge, handle data in an automated (hopefully digital) way.
• The results or input of these processes is stored in a database, safely tucked away in the company infrastructure.
• Last but not least, a control function exists to validate the data, the process, the treatment of the data in an automated or manual way, basically everything.

Two (or a few) companies collaborating

When two (or a few more) companies collaborate, we get a different story. The stack remains the same, but there is a new process found: the internal implementation of the agreed upon central process. Both parties however implement this shared process in their stack, in their interpretation of how it’s supposed to work. They have expectations towards the data they receive, and assumptions towards the data being sent.

As the drawing above shows, we created two dataflows. The process itself generates a flow of processed data, but to ensure that the data remains the same on both sides, more than likely a reconciliation flow, maybe with spot checks, has to be installed.

The internal control function will put more effort in validation and follow up of the exchanged data in the shared process as, despite agreements, no one knows what happens with the data “on the other side”. So both data-exchange and reconciliation flow are scrutinized.

Two (or a few) companies collaborating, on blckchn

When two (or a few more) companies collaborate, they could use a blockchain. It doesn’t sound like the best idea or business case, and it probably isn’t. It’s comparable to an airbag.

An airbag is something you expect to have in a car. It doesn’t make you happy it’s there, but you’ll be reluctant to get a car without one. Most of the time, it seems to be the most pointless piece of tech in your car. Until you hit something… if it’s a small concrete pole, you won’t be happy neither. Repairing your airbag is more costly than the damage on your car. When it’s a truck, it saves your life. Then you’ll rejoice and boast about how smart you are to have such an airbag. Ad hoc, ergo propter hoc: after the facts, thus along the facts.

Adding a blockchain allows you to drop proof of the data exchange. You’ll have an auditlog to validate where things went wrong, just in case. Maybe you’ll never need it… but what if you do? Of course you’ll have to underpin this airbag with wet contracts, aligning the accountability for the parties involved.

Insofar you exchange all data on the blockchain, you could probably even skip reconciliation between the two business. It would be far easier to rely on the data in the ledger. In this scenario, your airbag, the blockchain, serves as a post hoc (after the facts) tool to validate the facts.

When many companies collaborate

An even broader collaboration, maybe international, maybe along the full supply chain, adds quite some complexity to the point to point data streams. Even when a central platform is used, it still requires a heap of connections to be made, maintained, supervised. Everyone creates his own interpretation of the process… even companies that are barely known in the network. Hmmmm, their data requires extra validation.

The effect above is known as Metcalfe’s Law, which indicates that the number of connections is exponential given a linear growth of participants. Add more parties and it really looks like Picasso’s Guernica.

More data means more data exchange, more reconciliation (and reconciliation upon reconciliation), more validation of what happened, more processes to be updated,… but it works. We know it does.

When many companies collaborate, on #blockchain

The larger the ecosystem becomes, the more stress there is on exchange of data and share processes. Without common infrastructure, it’s like a snowball of data and validation of data. Mayhaps… could we add a blockchain to the mix to add some clarity?

Instead of everyone having its own little piece of process, implemented with good intentions but tailored to the company, smart contracts could be added to the blockchain. These “smart contracts” (not smart, not contracts) are a programmed version of the agreed upon process. It’s usable by all, owned by no one, and updated after consensus. Best of all, it’s enforced and automated.

When it’s triggered, it will run. From a legal/risk point of view, that’s amazing. There is no way to bribe a smart contract, or to block it. If it’s bugged, it can be updated. To make such efforts work smooth, governance is of utmost importance. Decide how to decide, how to collaborate, write it down in contracts with liability clauses, and sign these.

So, there is now a common layer with which parties can connect to join the ecosystem. The airbag part still delivers validation after the facts. This immutable ledger filled with proof, is most useful to reconcile with. It gives post hoc validation.

Furthermore, there is a shared process layer. Due to its pre-agreed, automated and enforced character, parties in the network know how and which outcome they’ll get. All of a sudden, you can have ex ante trust in what happens in the network, on the blockchain. It again removes the need to validate more and more, reducing each companies efforts to strengthen the ecosystem. Having this predictability, is an asset of exponential value for which a blockchain seems the most apt technology.

Conclusion

In a smaller setting, a blockchain adds value as airbag solution with post hoc validation with liability. Unseen, but there in case of need insofar it’s ever needed. Not the best use case, but shall I remove the airbag from your car? No? Maybe consider adding it to your business processes then.

In a larger setting, a blockchain provides the above but also returns value as ex ante truth and trust layer, by guaranteeing the outcome (standard data structure) of shared processes without any risk any of the parties involved is able to tamper with it.

That being said, there are no pixies with fairy dust in the ledger. If absolute nonsense, contentwise, is added to the ledger, you’ll have immutable nonsense being treated by a standardized process, resulting in nonsense output. That’s why signed wet contracts are still required to align liability in such a case.

By consequence, the parties participating in the blockchain are then known. Furthermore, as valuable data is not shared outside the consortium and user rights will be implemented, a private permissioned blockchain seems to be the logical way forward.

By giving up decentralization to a certain extent, the opportunity to scale and secure the blockchain based network grows.

As business value is created in growth while securing the data / legal obligations from participants and their consumers, adding a blockchain now becomes an asset and opportunity, rather than a question mark.

This article was originally published on Medium.