Quality and Innovation

Quality is all about satisfying stated and implied needs –now, or in the future. When we envision and design high-quality products and services for the future, that’s innovation. One of the most hyped innovations of 2017 was blockchain, which has the potential to transform business models and the way quality is managed. The purpose of this article is to explain this relationship in a simple way.

Blockchain is the innovative technology supporting the Bitcoin cryptocurrency. Bitcoin gained tremendous traction in 2017, starting at just over $1,000 in January and reaching nearly $20,000 by the end of the year.  It increased in value so much over this time that it’s been compared to the Dutch tulip market bubble of the 1630s.  After tulips were imported into Holland from Turkey, an alteration to the solid colors of the tulips caused the appearance of “flames” on the petals. This made people believe that the tulip bulbs held extreme value, and so many people traded their land and their savings to invest in what they felt was a “sure thing” – to lose everything not long after, when the market corrected itself.

The blockchain technology that supports Bitcoin is, at its core, a database. It’s a special kind of database, but no more magical, really – and easier to contextualize if you think about innovations in database technology over the past two decades.

Databases can be roughly classified into these categories:

• Relational databases (Oracle, MySQL, PostgreSQL, Sybase): When you can organize your data in terms of tables, fields, and relationships between those entities, a relational database is often appropriate. For example, your customer data might be kept in the “people” table with fields like address, state, or gender. Each record in the people table might have a type – employee, partner, or customer. Although records can be changed, it’s easy to accidentally input bad data, and it’s also easy to accidentally generate duplicate records. Scaling a relational database can also be rather tricky.
• Non-relational (NoSQL) databases (MongoDB, Cassandra, Redis): If most of your data comes in large blobs and you don’t want to split it up into fields and tables, these databases are useful. MongoDB is great for collections of documents, such as web pages, log data, or tweets. Cassandra works well for analytics applications. Sensor data and other data types that change frequently or need to be held in active memory (for example, in key-value stores) are handled well by databases like Redis. NoSQL databases are easier to scale than relational databases.
• Other databases and data stores with special properties: Some databases are so unique they don’t feel or act like databases. Solr, for example, is traditionally used when you have to provide search functionality over a store of documents. Hadoop is a distributed file system, so it functions somewhat like a database even though it’s not one. Graph databases are designed for data stores where the relationships are the most important aspect, so they are gaining popularity for social networks. Large, institutional science projects often store their data in special binary files that have distinct formats, can be queried like databases, and in many ways act like databases – but they are not technically databases.

 

What Distinguishes Blockchain-based Databases from Ordinary Databases?

First, the blockchain is designed to handle transactions – it’s a digital ledger. So it’s not surprising that its first “successful” use cases are in the realm of cryptocurrency, where people engage in transactions with one another to exchange something of value.

Next, this database is immutable, meaning you can’t go back and change earlier records. Every time a new transaction occurs, a cryptographically sealed “snapshot” is taken of the entire database. When I first heard this, I was worried: so that means if we accidentally enter something incorrect into the database, it can never be changed, right? And its presence is memorialized forever? The answer to this question is: sort of. Thanks to “smart contracts”, we shouldn’t ever be in the situation where bad data gets entered into our blockchain-based system, because incoming data will be checked (by multiple agents) against the smart contract — and only allowed to join the blockchain database if it meets all the quality requirements specified by the contract. It’s like a fancy way to implement validation rules – with the added benefit of being totally traceable. Imagine how nice it would be to trace all the steps in the process that brought the fresh fruit into your kitchen – or any other product you use — just because all transactions in the production process were logged into a “supply blockchain.”

A blockchain database is also decentralized and distributed — you don’t just “buy a blockchain database” and install it at your company. Databases can be centralized, decentralized, or distributed. Most business databases in the past were centralized: there was one instance installed, and a database administrator (or team of them) ensured the performance and security of the database while everyone in the organization created and used applications that interacted with the data. Today, these databases are more commonly distributed: there’s not just one instance, but several – there is no central storage, but there may be storage on many computers, or over a network of connected computers (or “in the cloud”). 

Decentralized systems have many advantages – for example, nodes can join or leave the network at will. For example, you can create a web site or take it off the internet whenever you want, if you own and control it. In decentralized systems, there is no single point of control. If a business wants to implement blockchain but also wants to control all the nodes, that should be a big red flag. By its nature, blockchain is decentralized just like the internet itself.

Finally, blockchain is transparent. Any of the participants who own nodes can see all the transactions — so there should be fewer opportunities for fraud. This doesn’t mean that there isn’t opportunity for danger, though.

 

Why is Blockchain Potentially Useful for Quality Assurance?

In addition to enhancing provenance and traceability, one of the biggest envisioned applications of blockchain databases is to support machine to machine transactions. As intelligent agents grow in complexity and are trusted to handle more tasks, and as the Internet of Things (IoT) expands, there needs to be a high-quality record of how those objects and agents interact with other objects and agents – and with humans. Blockchain could also be used to support new business models like decentralized energy markets, where you can consume energy from the local power plant, but also potentially generate your own and contribute the excess energy to your local community for a fee. It could potentially transform middleware as well, which is software that allows different software systems to communicate with one another. (A long time ago, someone told me that it’s like “email for applications” – they can send messages to one another so they know how to react, for example, when a company receives an order and several systems need to be alerted that the order has arrived.)

In principle, transactions logged to a blockchain make it impossible to defraud participants in the process, and impossible to manipulate records after they are recorded. They are self-auditing and fully traceable. Blockchain won’t make quality assurance, tracking, or auditing EASY, but you should expect it to make the business landscape different – new business models will be possible, and it will be possible to entrust intelligent agents with more tasks.  

Blockchain can help us ensure that stated and implied needs are met, and do it in such a way that the integrity of our data is assured simply by its presence. But we’re not there yet. Developers still need to implement simple, demonstrable use cases to make it easier for managers and executives to map these technologies onto specific business needs. In addition, blockchain is slow compared to relational database systems, so this needs to be addressed as well before widespread adoption.

 

Read more in our December 2017 SQP article.