Industrializing the Blockchain

I am going to assume you’ve heard of this Blockchain thing by now. I’m also going to assume that you do not know much about how it works. You have no clue as to how to apply it to your business. The hype surrounding it is annoying, making it appear as yet another technological fad that will fade from view in a year or so. Not worth your trouble to investigate further.

Here’s the truth: Blockchain is actually a very powerful solution for a certain special class of business problems. You are welcome to ignore it, but I think a much wiser move on your part is to learn the special kinds of problems that it is uniquely suited for. I’ll try to illustrate that for you now, in a very non-technical way.

First, let’s get our terminology straight. Almost no one in the know about Blockchain calls it Blockchain any longer. Rather, most people refer to it as Distributed Ledger Technology, or DLT (there are other variants to this term but we are keeping it simple for now). And in fact, this term makes it clearer what the primary function of this technology is: to serve as a utility for making ledger-like entries across a broad space, spanning perhaps many companies and people.

So this now gets us to the first way to think about correct applications of DLT: whenever you need a distributed ledger. When might that arise?

Think about your own or an example value chain for a moment. Who are all the players and how and when do they participate in transactions that make the value chain work? What product or service triggers the movement of some “thing” from one state to another? Is proof of the work required? 

I’ll give you an example from one of my own projects. There, a marine shipping terminal serves as the place where empty barges arrive to collect liquid chemical products. Previously a shipper would have offloaded that same product into tanks from the manufacturer, arriving by boat or pipeline. A third party verifies that indeed, 40,000 barrels of Benzene were received from Acme Chemical and this is noted on a paper form. Now comes an empty barge from MakeCo to receive that 40,000 barrels. The material is loaded and yet another inspector verifies that yes, 40,000 barrels of Grade X Benzene made it onto the vessel at a specific time. Another paper form is generated (in a different format by the way). All the while, the vessel’s arrival, setup, and departure times are recorded in case demurrage (vessel delays) are incurred in which case the responsible party must pay that penalty and so on. 

I could go on and on with this scenario with the actual complexity of the whole transaction but I think you get the point—there are lots and lots of transactions going on, much more than meets the eye, and they are poorly documented. Your business probably looks simple from the outside too but you know all too well that looks can be deceiving.

Your business probably looks simple from the outside too but you know all too well that looks can be deceiving...

OK, So What Do We Have Here? 

First, we have lots of independent actors—the terminal, the shipper, the customer, inspectors, vessel owners—all coming from different companies. What else do we have? Time-stamped events that are critical to the transaction. 

What else? 

Verification, and the need to know something very critical that has substantial financial impact tied to it. We also have a situation where any of several bad human actors has the power to alter the records to their benefit. These kinds of conditions give rise to using DLT appropriately. First, DLT spans many companies, and we are moving toward standardization of this for all users in the same way that email is “standardized” today (I can use whatever email client I want to send you an email and I don't know or care about the plumbing between us - it just works). This multi-agent condition is very important to the application of DLT. Trying to implement DLT as a “database” for just one company simply means that you will be using a slow, expensive database. Multiple agents all with different IT setups push the problem into a different realm, requiring something different from just a database.

Second, DLT is immutable. It is nearly impossible to alter records once they are placed on the ledger. That does not eliminate the possibility of corruption, but it certainly makes it way harder for bad actors to do it undetected. Moreover, reconciliation of the DLT against other records—normally a slow and expensive process—can be largely automated in real-time. 

Another facet of DLT is the so-called smart contract. As that name implies, you can create and store within the DLT “contracts” that execute automatically under certain conditions. 

A good way to think about smart contracts is IFTTT. If This Then That. IFTTT is a consumer application that I am sure that you’ve seen where your super-techie neighbor has wired his home for all sorts of automation. “When I pull in the driveway, turn on my hot tub” might be an example of an IFTTT script that he would use. Sensors determine the “If” condition and actuators execute the “Then” part. 

Same with smart contracts. Some set of conditions are present on the ledger which in turn trigger actions as per a pre-agreed scheme. 

Can You Argue With This?

Let’s return to our marine shipping example. Where would a smart contract be helpful? Let’s say that the vessel heading to the Port of Houston to pick up the benzene experiences an engine failure. What happens in the real world? I can tell you from personal experience: the captain informs the vessel owner by phone or radio. The vessel owner contacts the shipper who then gets into a screaming match with the vessel owner (the language!). Many phone calls and screaming matches ensue among all parties and perhaps if you're lucky a replacement vessel arrives 3 days later (more likely a week or two).  Oh and by the way: the whole cost of the voyage just doubled.

Could this have been avoided? How about all parties agree to a smart contract that automatically pulls the replacement vessel on the incident of the engine failure and schedules it according to a set of pre-arranged rules? This is precisely what smart contracts do.

So now ask yourself this question: when do I have exception conditions that arise where I could have anticipated them? And could those exceptions be handled much more elegantly and cheaply if they were “designed” in advance? If yes, smart contracts might be a useful technology.

Another Example of "What Can Be" With High-Value Automation

In conclusion, I hope you don’t let the hype or the confusion about Blockchain prevent you from seeing where true, valuable applications of it can be used to create value. Rather, take a careful look at situations like the ones that I described and see if there’s a fit. If there is, draw a picture to “model” the application. Use that model to describe this to technologists. You might just find that DLT is the right tool for the job.  

If you enjoyed the content from this newsletter, there is more in my book, The Executive's How-To Guide to Automation: Mastering AI and Algorithm-Driven Business (Palgrave Macmillan). The book is everything you need to know to lead using the emerging technology of AI and Automation.

George Danner is Chief Data Scientist at Valedor Partners LLC, a Houston-based merchant bank and investing firm. For more information on Valedor DSS, please visit our website at valedorpartners.com/dss

Let's Talk - Schedule a Discovery Session