Best blockchain implementation
Editor's note: This is the second in a two-part primer on how to get started on a blockchain implementation. In part one, SearchCIO editorial director Sue Troy looked at the potential impact of blockchain technology across industries and took readers through the first phase of a blockchain project: identifying a use case that brings value to the business and making a plan for scoping the required technology. Here, Troy reports on the next three stages: proof of concept, field test and full-volume rollout.
Proof of concept
Jeff Garzik, co-founder at blockchain services and software company Bloq and a core Bitcoin developer describes the proof of concept stage for a blockchain implementation as a one- to-three-month exercise.
"You create a system ... that integrates into an isolated sandbox environment with that ... institution's data and you get to see the software operate in a simulated environment with real customer data. It does not impact customers, but it's real customer data, real transaction volume, " Garzik said. "If you're talking larger volumes, a million transactions per day - something of that nature - you get to see how well the blockchain system scales up to meet that demand."
At the Consensus 2016 industry event in May, Catheryne Nicholson, CEO and co-founder at BlockCypher, which builds blockchain APIs, explained the proof of concept process in a panel discussion. "[A proof of concept is] very unmethodological in terms of engineering; it's something where you're trying to iterate quickly, fail quickly. It's the mantra of 10 engineers doing 10 projects in two months and seeing what's sticky."
Most customers are not yet at Stage 4. Fortune 500 is really at Stage 2 POC or Stage 3 field trials with blockchain technology. Jeff Garzikco-founder, Bloq
Both Nicholson and Yorke Rhodes, global business strategist at Microsoft, said the cloud is the best venue for a blockchain proof of concept. "[Cloud computing] lets you spin stuff up without worrying about hardware [or] about it being inside your network, " Rhodes said. Having it in the cloud also makes sense if there are multiple organizations participating in the proof of concept, he added.
Even though testing may be done using public cloud services, most companies will relegate those tests to private or permissioned blockchains. "No enterprise is going to do the first tests on the public blockchain, so I think you'll see a ton of use cases in development that are 100% internal only, " Rhodes said.
There are obstacles that will derail a proof of concept. At the Consensus 2016 event, Scott Mullins, who runs worldwide financial services business development at AWS, implored IT organizations to include all relevant parties in a proof of concept.
"Don't forget you've got people down the chain that you need to include in the [POC] process. You've probably got a third-party outsourcing team, you've probably got a third-party oversight team, you've definitely got a compliance or risk management team, " Mullins said. "Don't wait to get all the way to the end with your POC ... and you have five people who raise their hands and say, 'Hey, you need to talk to us about the different things we need to check the boxes on.'"
Eric Piscini, consulting principal at Deloitte's technology and banking practice, speaking on the same panel, advised against a wide-scale POC. "When we see POCs fail, most likely you start too big and think you're going to change the whole organization with blockchain. My advice: Start with something small that's going to impact a very small part of your organization."
BlockCypher's Nicholson cautioned against lengthy contracts tied to a proof of concept. "From a startup perspective, we have been thrown 150-page boilerplate master services agreement for a POC. It's way overkill. If you're an institution looking to do a POC, put that MSA to the side. Ask the startup if they will work with your four- to five-page agreement instead of going through months and months of negotiation with legal counsel, before you even start."
Field trial and beyond
Garzik said this typically means a small trial with perhaps 5% of customers or customers on a lower-volume product. "IT staffs are locating within their customer product sets perhaps a lower-volume, perhaps less-customer-facing, use case that they can then present both to the board at the CEO level and also to their engineers at the low level to really gain that knowledge."
Nicholson explained that the field trial isn't simply a proof of concept moved to production but rather a restart. A field trial might have completely different requirements than a POC, she said.
