Blockchain is a new-ish distributed database technology (circa 2008-think BitCoin) which seems near the top of its hype curve. So, it seems like a good time to evaluate whether this promising technology has anything to offer organizations that require the capabilities provided by PLM applications. First, let’s understand the basics of blockchain. If you have used databases your whole career, it is time to think differently. The fundamental ideas of blockchain are:
Permanence of past transactions (impossible to change the past)
Trust of data on untrusted media (the data is stored somewhere)
To ensure the above characteristics, blockchain distributes data among a vast network of world-wide peer-to-peer nodes that can be hosted by ANYONE, including bad actors. (Of course, even bad actors, have many reasons to count on the integrity of their data.) Reliability of the data is ensured because records are reconstructed on-demand from the network by consensus of the nodes. Cryptography ensures that single-record changes are difficult, and the blockchain data structure ensures that in order to change an old transaction, every transaction since then must also be changed across the entire network.
The result is a complete and immutable list of records. At an application level, we can think of a blockchain as just another database. But where do traditional databases fall short? And, what kind of applications require these properties?
Traditional database technology is hosted on a single (logical) server. And in most database implementations, any administrator can change data without anyone else knowing. Even if all participants agreed that all administrators are 100% trustworthy, hardware is not. Media are subject to many random physical processes and is only truly reliable in a locality and to a (albeit high) degree. There are, of course, technologies that improve the reliability of traditional databases, but there is still the issue of the trustworthiness of whoever physically owns the media where the data is stored. Blockchain’s distributed representation is fundamentally different, and suffers none of these limitations as there is no single copy of the data. In fact, all data is stored everywhere, and data is only read-out via algorithms that ensure the continuous monitoring of the data.
This brings us to the second question: what kind of applications require the characteristics of a blockchain? The answer comes down to basic questions such as “How important is the data?” and “Can a single owner be trusted to maintain it?”. Perhaps, summing those up, “What are the risks of recalling the data wrongly?”. So, consider the archetype of a blockchain application – cryptocurrency like Bitcoin. First, it helps to think of physical currency as distributed data. If I have $12.85 in my pocket, that would be one record. But how did it get there? A long chain of events lead to the printing/minting, distribution, and transactions that resulted in this record. If we had a perfectly indisputable and transparent history of all those events, then the bills and coins in my pocket become redundant and can be discarded. We would only need to query the network when I arrive at the lunch counter, and the clerk would agree about the money I own, and can use it to buy a sandwich.
This simple example illustrates an application where it would be VERY BAD if the data were allowed to be modified or corrupted. Who/what would we trust to maintain a traditional database of who holds what money forever? A government? All sides in dissenting political views get woozy at the thought. So, blockchains are good for tracking financial transactions.
OK, let’s try another application… food supply. Wouldn’t it be nice to know where a salmonella-laced hoagie picked up it’s unwanted stowaways? Restaurants and groceries are at the end of a fairly complex world-wide supply chain. And the risks are fairly obvious. Sounds like a candidate for blockchain. What about parts for a Boeing 747? It might be good to know, for sure, whose hands they passed through to get there. And, in both cases, it’s not obvious who can be trusted with owning the data. You get the idea.
But, what about the downside of blockchain? Aggregating votes from a world-wide network of a large number of nodes is time-consuming. So, how long are you willing wait at the counter for your hoagie? Or on-line to buy limited-availability airline or concert tickets? Even when the risks are high, we will all still come down on the side of practical limitations such as transaction duration. So, even applications that are clearly in blockchain’s wheel house may not be well-suited to run an economy. Scalability and performance are two areas where the technology still needs to improve.
So finally, let’s address the suitability of blockchain for PLM.
It is not hard to argue that the distributed nature, and inherent trust issues of most supply chains may be good motivations for using blockchain. We may see procurement transactions over blockchain in the relatively near future. But PLM is fundamentally a behind-the-firewall decision support system. It tracks data that you can trust your employees to protect. There is no reason to allow transparent access to your product and operational data. And, inherent blockchain performance issues run the risk of impacting the productivity of many valuable employees. So, what’s the worst-case consequence if PLM data gets corrupted? There may be cases where product safety is impacted, but there are also many other checks and balances in product development and manufacturing processes that could prevent a rogue record from having any impact at all.
Since there are traditional technologies that raise traditional database reliability and security to an acceptable level, it is not clear that blockchain would add much value to core PLM capabilities.
I’d love to read your thoughts on this matter. Are there other use cases in manufacturing that may benefit by applying blockchain technologies?
– Fred Smith, Sr. Solution Architect, Autodesk
(0)