Can a database technology really kill an entire industry?
That’s what I was asking myself at one of two blockchain presentations I recently attended. The first was a panel discussion in which knowledgeable blockchain evangelists predicted blockchain will indeed lead to the demise of entire industries. The second was a presentation by a blockchain expert for a Fortune 50 company. Not surprisingly, he offered a different perspective on whether blockchain will cause traditional industries to crater.
So how could a database platform, in this case blockchain, put anybody out of business?
A blockchain is sometimes defined as a shared, immutable ledger. I would add to this, “transparent”.
Put together, these characteristics make blockchain into something very valuable and potentially very disruptive:
SHARED + IMMUTABLE + TRANSPARENT = TRUSTED
The digital history recorded in a blockchain, whether of documents, transactions, or digitized records of assets or even people, can be trusted by all participants.
Who did the panel of blockchain evangelists predict blockchain would put out of business? Trust brokers. Businesses whose value proposition is to ensure the validity and integrity of documents and transactions. Businesses selling trust that can be replaced by using a blockchain. Title insurance companies. Stock clearing houses. Gone.
Sounds revolutionary, and scary if you make your living in the trust-broker business. But this panel was presenting to an audience of hundreds, and I didn’t get a chance to follow up with questions that were bothering me: What does it mean to “broker trust”? Does that always mean the same thing? Can blockchain replace all trust brokers or just some, and why?
I was still thinking about this when I attended a second blockchain presentation two days later, this one a lively talk by an IBM “Global Blockchain Industry Leader” (that’s what they call them at IBM). The speaker didn’t mention disruption, and he didn’t even mention “trust”, but when he got to how IBM adds value to the blockchains it manages for clients, my antennae went up. IBM is a “blockchain network administrator.”
Blockchain administrator? Why does a blockchain need an administrator? I thought the whole point of blockchains like Bitcoin was that they are decentralized networks that don’t need an “administrator.” Was IBM just trying to invent a way to add value to a platform that doesn’t need it? Was IBM just another trust broker trying to remain relevant?
Public vs. Private Blockchains
To answer these questions, you have to understand that there are two types of blockchains: public and private.
Public blockchains, which anybody can join, get all the (popular) press. They include the cryptocurrency blockchains, the blockchains whose disruptive potential my panel of evangelists was very excited about.
Private blockchains, also known as permissioned blockchains, require an invitation to join. They allow a business consortium to take advantage of all of the technical features of a blockchain platform while restricting access to, well, an invitation-only consortium. In one interesting example of a private blockchain, an entire food supply chain was digitally recorded and tracked in a blockchain, reducing the time to track the origin of a mango on a retailer’s shelf from almost a week to two seconds. You may have heard of the retailer: Walmart. (The blockchain was implemented by IBM.)
Enterprise blockchains are private blockchains, and while private blockchains may not be as sexy to casual blockchain fans and soothsayers, they are seeing wide adoption in industry and are not going away. (According to a late-2016 Deloitte survey of executives across a variety of industries, 25% expected to have production blockchain deployments by the end of 2017.)
So who grants permission to join a private blockchain?
The answer is no different for blockchain than for any other private network. Permission is granted by a gatekeeper, and that gatekeeper could be the blockchain administrator. So on that basis alone, there’s a future in the (private) blockchain administrator business.
In addition to its gatekeeper function, IBM enhances its enterprise blockchains by capturing business rules in what are called smart contracts. Smart contracts are snippets of code that capture business rules applied to blockchain transactions. They define what actions should be taken when given conditions are met, such as delivering payment upon confirmation of shipment. The only thing that makes them any smarter than any other codified business rules is that they are stored on the blockchain alongside documents, so they are shared, immutable, and transparent (and therefore trustworthy).
Smart contracts, just like any other contracts or business rules, have to be written and maintained by somebody. For a private blockchain, that somebody may well be the blockchain administrator. Once again, it appears a form of trust brokerage (defining and maintaining the business rules encoded into a blockchain) is here to stay.
Who will blockchain put out of business?
While blockchain technology has the potential to be enabling and disruptive in exciting ways, clearly it won’t disintermediate all intermediaries or make all trust brokers go broke. Here’s my take on the factors that will determine blockchain winners and losers:
If an entire business process can be reduced to general-purpose blockchain transactions, blockchain can and will replace companies whose only business is ensuring trust in that process. I think those companies will be the exception, not the rule. Companies that serve as gatekeepers for enterprise consortia or, more generally, implement or integrate specialized business rules will not only survive but thrive.
Also published on CTO Craft
In a previous post I looked at how the adoption of not only cloud-based software platforms but ancillary cloud-based services has really taken off, supported by a robust ecosystem of third-party SAAS tools for project management, testing, QA, monitoring, analytics, collaboration, etc. In the past it was common for software teams to develop some of these services, such as testing and monitoring, in-house. Others services, such as project management tools, might have been purchased on physical media (first floppies, then CDs, later DVDs) and laboriously installed on individual computers — often in far greater numbers than officially licensed).
Still other services, such as distributed collaboration tools, simply didn't exist before.
In today's cloud ecosystem, these readily-accessible tools are available in ever-increasing numbers. If you know what you're looking for, you can Google something like "agile project management software" to find product information and reviews. But sometimes it's nice to hear about what's new or popular a little more serendipitously.
CTO Favorites and Contenders
During previous research I conducted a survey of fellow CTOs to quantify their use of cloud services. As a byproduct of that exercise I received several CTO suggestions for favorite service which I’ve shared here,
along with notable category competitors also worth considering:
Distributed Agile Standups
User Session Playback
Visual Regression Testing
…Which are your favorites?
Also published on CTO Craft
QA is too-often treated like the ugly stepchild of software engineering, particularly in fast-paced startup-type environments. Look at many teams’ code and you’ll find a hodgepodge of scripted tests, possibly automated (possibly not), with varying levels of coverage and maintenance, driven by individual initiative more than universal mandate.
In this age of agile Continuous Integration (CI), automated tests have become generally accepted best practice, yet in my experience they remain far from a generally practiced best practice.
QA outsourcing has become increasingly popular. It’s easier and cheaper than ever to contract with a human(s) to manually test your software or even use a “crowdtesting” service to mimic automated software tests. Whatever its merits, I believe QA outsourcing dampens adoption of automated testing by making it economically feasible to “solve” the QA problem by throwing people at it. This helps perpetuate software developers’ “we’re too busy to write tests” argument.
Common Types of Software Testing
Before I go further, let’s take a moment to review some definitions:
Now that we’ve gotten that out of the way — what’s your team’s adoption of automated testing?
A. We’ve automated our unit tests
B. We’ve automated our integration tests
C. We’ve automated our functional tests
D. Yes to A, B, and C
E. We have people who test — they’re called “QA”
(If you answered D, congratulations! You can stop reading now.)
Not too long ago I was managing a team whose answer was ‘E’ — we had people for that (in this case, an outsourced contractor). This was a capable, high-performing software development team, quick to adopt new technologies and generally moving fast (and breaking things along the way). The team was adding unit tests, but slowly. They didn’t see writing and automating tests as particularly high priority, especially with a contractor doing a seemingly good job of finding a few new bugs nightly after every code drop. It wasn't broke so they weren't going to fix it.
Perhaps this sounds familiar.
To make the case to invest in developing a robust portfolio of automated tests, I created the following deck:
Automated tests are indeed a lot like robots on a factory floor. They don’t replace the people who conceive of the product (formulate test plans), create initial versions of the product (manually run test plans), design and build the robots (write automated tests), or do new product R&D (perform exploratory testing). But for the large part of QA that consists of repetitive testing, robots (automated tests) outperform their human counterparts and should be leveraged for unit, integration, and functional tests across all software environments.
Also published on CTO Craft