The Business Blockchain: Promise, Practice, and Application of the Next Internet Technology - William Mougayar, Vitalik Buterin (2016)

Chapter 6. IMPLEMENTING BLOCKCHAIN TECHNOLOGY

“Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world.”

-ALBERT EINSTEIN

THE MORE FOUNDATIONAL A TECHNOLOGY IS, the more impact it can have. Blockchain technology is not a process improvement technology. At its fullest deployment potential, it is rather a disruptive technology; therefore it must be given that potential when being implemented.

Most of the major blockchain platforms have been developed via a transparent, open source, collaborative approach, including a good degree of decentralized contributed work. This has two outcomes: a) the proverbial “sausage-making” is not always pretty, and b) up until final releases are set, implementation and deployment compromises are more routine than exceptions. Until blockchain technology development matures (around 2018-2020), you will need to manage the variety of implementation challenges that are paved along its way.

We could end up with a similar situation as during the Web’s initial years. Many early businesses failed, some due to weaknesses in technology, others due to stretched business model assumptions (the result of a lack of enough market experience), and some due to both. Eventually, Internet and Web technology evolved, improved, and enabled the building of more powerful implementations.

With the blockchain, one could adopt a conservative approach and wait until the technology matures, then get involved when all uncertainties are removed. As the saying goes, the early bird would get the worm, but the second mouse gets the cheese. Some companies will undoubtedly follow that route, while others will be more attracted to being pioneers and innovators who are willing to trade risks for greater or earlier rewards.

There are two ongoing approaches for implementing the blockchain: a) inside existing organizations, as an add-on technology; or b) outside organizations, by a startup who may not be as concerned with existing processes. This chapter focuses on covering early steps in internal blockchain implementations, inside organizations. Many of the ideas in Chapters 3, 4, and 5 highlighted the innovative work of startups. Later in this chapter, we will also cover inter-organizational opportunities that are a mix of the former two.

INTERNAL STRATEGIES FOR TACKLING THE BLOCKCHAIN

There is no right or wrong way to implement the blockchain within large organizations. There are various approaches. A startup begins with a blank sheet of paper, and no baggage. But an organization can be held hostage by its existing situation. The old adage, “Yes, God created the world in six days, but that’s because he didn’t have an installed base,” is true again.

Getting large organizations up to speed and knowledgeable about blockchains and their impact is not an overnight project.

It takes some time before a given issue (the blockchain) gains momentum, understanding, and share of mind within senior executive ranks, along the way in figuring on the CEO’s priority agenda. Typically, that starts to happen after a combination of groundswell interest from progressive employees, and via external market pressures.

Suddenly, one or a handful of employees in leadership positions begin owning the blockchain topic, and they start to continuously think about it. Some of the organizational questions might be:

· How shall we organize to tackle the blockchain, and why?

· How do we develop use cases, strategies and implementation approaches?

· How do we evolve from Proofs of Concepts to full deployments?

· What documented benefits shall we be expecting from the blockchain—strategic versus operational?

· What lessons are we learning, and mistakes are we making?

· What benchmarks are we measuring ourselves against?

· What best practices can we share, so we can be more effective in our endeavours?

· What can we hope to accomplish over the next year?

THE BLOCKCHAIN CZAR

The origin of the czar analogy dates back to the reengineering days during the early 1990s when Michael Hammer and James Champy advocated the role of the “reengineering czar” in their book, Reenginering the Corporation. The reengineering czar was that person who would become the rallying point for reengineering efforts within a company.

In the reengineering definition, the reengineering czar is “an individual responsible for developing reengineering techniques and tools within the company and for achieving synergy across the company’s separate reengineering projects.”1

It is noteworthy that the reengineering czar does not make reengineering “happen.” That is the role of “reengineering leaders” who receive support from the czar. Continuing on the role of the reengineering czar from Hammer and Champy, “The reengineering czar has two main functions: one, enabling and supporting each individual process owner and reengineering team, and two, coordinating all ongoing reengineering activities.”

In my last year at Hewlett-Packard in 1995, I held the role of Reengineering Czar for the company’s Canadian Operations. That position reported to the CEO because reengineering was an executive level initiative that had the highest possible level of agenda priority. At that time, I was managing a dozen reengineering projects by assisting the teams that were implementing them across the company, and we followed Hammer and Champy’s methods and practices, with great success.

For historical reference, there is a governmental related antece-dent to the czar positions. In 1993, President Clinton appointed Ira Magaziner2 as the United States Internet Czar, during a time when there were 11 czar titles nominated by the White House. It is interesting to note that the number of czar titles later skyrocketed to 33 under President George W. Bush (2001-2009) and 38 under President Barack Obama (2009-2016).3

The difference between the reengineering days and the early blockchain period is that the “cookbook” for reengineering was largely written, and much of the work was about implementation. In the early 1990s, the underlying catalyst technology was Information Technology, and it was stable, unlike enterprise blockchain technologies that were still growing and maturing as of 2016. However, the spirit and intent of the reengineering czar position remains totally applicable for the blockchain.

Following the practices of process reengineering was business religion in its purest form, and it is my hope that blockchain initiatives and investments get the same treatment.

In this context, the “Bockchain Czar” should have experience in your own business operations and they should understand the role of reengineering business processes via technology implementations. This person could also become the company internal and external spokesperson. Ideally, this role is not to be filled by an analyst from the research department, but they could be part of an innovation group, as long as they have had operational experience. The Blockchain Czar will be responsible for removing obstacles within your organization, facilitating education, curating and sharing best practices, and overseeing the progress of various implementations across the organization. This job is a tough one, because it involves finding and obliterating old processes, instead of automating or streamlining what is currently being done.

ORGANIZATIONAL MODELS

So, how do you organize internally? There are various options.

Some companies are funding a “Blockchain Labs” entity that includes software engineers who can get their “hands dirty,” as soon as ideas come to the fore and need to be demonstrated. These labs typically have an internal focus to “show and sell,” or educate the blockchain’s possibilities to other business units and departments within the organization. Their challenge is typically not in the incubation of ideas, but rather in how these ideas get handed over and implemented inside other departments and business units who are the real implementations playgrounds.

Some other organizations have formed an internal blockchain task force comprised of the various business unit stakeholders, who meet and communicate on a regular basis. The challenge with this type of approach is that not all of these stakeholders may be at the same level of knowledge or motivation and they may not agree on a given direction. The role of this group could be more about sharing and collective learning than influencing.

Another approach is to discover ideas within the various groups via a common process, but to develop the proofs of concepts for them in the labs, then proceed to implementing the best candidates with the business units.

Regardless of the approach, they would all benefit from at least one strong blockchain advocate that is a respected thought leader, and a bold communicator and an enthusiast about blockchain technologies.

A BLOCKCHAIN FUNCTIONAL ARCHITECTURE

One way to understand the scope of blockchains is by studying the comprehensive functionality they hold. This section depicts a proposed generic building block approach that was derived by analyzing the various approaches that exist on the market.

In 2016, it looks like these pieces are many, but there will be consolidation, and we will gradually start to talk less about what is under the hood, and more in terms of higher-up capabilities. Eventually, this type of technology infrastructure will be taken for granted, and most of it will come assembled “out-of-the-box,” instead of in an IKEA box, like the early approaches.

The following are the building blocks of a blockchain technology:

Let us dive inside each one of these pieces in more detail.

CORE & PROTOCOL

Peer-to-Peer Network

The Peer-to-Peer (P2P) Network is the collection of computers that are connected together as nodes, and into an ever expanding topology. It is a basic foundational element of a blockchain. Each node runs the same software, therefore delivering inherent redundancies to the whole network, which means that if one node goes down, or is not responding, the work of other nodes is always compensating. In essence, a P2P network is difficult to take down entirely. You would have to take each and every node down.

Consensus Algorithm

The various methods that dictate “what” or “how many” nodes can participate in the permissioning aspects of validating transactions is also part of the consensus algorithm configuration, and they help to determine if the outcome is a public, private or semi-private form of consensus. Mining may or may not be involved in this process. Keys and signatures are part of this functionality.

The early years of blockchain developments were plagued with heated discussions over which type of consensus is best, but as these technologies mature, and certainly past 2018, the type of consensus algorithm will be a moot subject, as it will be taken for granted, as long as it is efficient, secure, and well supported.

Virtual Machine

It is a concept, borrowed by the popular Java Virtual Machine (JVM) approach, but pioneered by Ethereum, within the blockchain development context. The Virtual Machine depicts the part of the protocol that handles internal state and computation. It can be thought of as a large decentralized computer (actually made-up of the several P2P machines) that contains information about the millions of accounts, which update an internal database, execute code, and interact with one another. Programs written in Smart Contract Language get compiled into the Virtual Machine, and to create the contracts you send the transaction containing your code.

Historical Record

Transactions are actually recorded in sequential data blocks (hence the word blockchain), so there is a historical, append-only log of these transactions that is continuously maintained and updated. A fallacy is that the blockchain is a distributed ledger. In the technical sense, it is not, but it acts as one, because the collection of transactions on blocks is equivalent to a distributed ledger. However, you can build immutable distributed ledger applications based on the historical records that the blockchain provides.

State Balances

Bitcoin was not designed around accounts, although accounts are a more common way to think about the transactions that are taking place, because we are used to looking at our banking transactions as such. Under the hood, Bitcoin uses a method called Unspent Transaction Outputs (UTXO), a concept that links unspent transactions as an output that can be spent as an input in a new transaction. Other blockchains use different methods to keep tracks of state balance. Ripple has a ledger that contains a snapshot of the current balances held everywhere on the network as opposed to a chain of historical events. In Ethereum, the state is made up of objects called “accounts,” with each account having state transitions being direct transfers of value and information between accounts.

BLOCKCHAIN SOFTWARE DEVELOPMENT

The various pieces comprising blockchain software development include:

· APIs (Applications Programming Interfaces)

· Various clients implementations (e.g., C++, Python, Go, Java, Haskell)

· Integrated Development Environments and Rapid Application Development frameworks

· Smart Contracts Languages and Scripts

· Testing tools

· Sandbox environments

ON-CHAIN SERVICES

· Time-stamping

· Naming registration

· Oracles

· Identity management (online, legal, pseudo, etc.)

· Voting

· Smart Contracts Management

· Tokenization

· Messaging

· Assets linkages

· Proof of existence

END-USER VIEW

· Command line

· Special browsers

· Wallets

· Applications

· Downloadable clients (as the application entry point)

OFF-CHAIN SERVICES

· Reputation

· Messaging

· Storage (DHTs, File systems)

· Exchanges (for tokens, assets, currency)

· Payments gateways

OTHER DESIRED BLOCKCHAIN FEATURES

· Encrypted transactions (confidential transmissions)

· Monitoring (statistics and analysis)

· Audit

· Security

WRITING DECENTRALIZED APPLICATIONS

Since the consensus process of blockchains is decentralized by nature, it makes sense they are enabling a new breed of decentralized applications. A decentralized app can be decentralized technically, politically, or both.

The reality is that decentralized apps are not for everything, and not everything fits a decentralized app paradigm. However, there are a lot of applications that do fit the blockchain distributed paradigm, and that presents a good amount of opportunities for developers, creators, and visionaries.

Decentralized applications start by creating their own rules for ownerships, transaction requirements, and logic.

There are various levels of sophistication in writing decentralized applications.

1. Use cryptocurrency as a currency unit to pay for services.

2. Use a blockchain service as a feature, for example, to register an asset or verify the authenticity of a process, typically done via an API.

3. Use a smart contract on a blockchain to run some business logic that returns a particular value if certain conditions are met, for example, financial derivatives. In this case, there’s a digital asset whose ownership and movement are governed by the blockchain.

4. Use the blockchain in a more fundamental way, where the app would not function without the blockchain. Typically, you would set-up a specific peer-to-peer network with nodes, for example, OpenBazaar, as a decentralized e-commerce app.

5. Use your own blockchain (could be shared with others), without an economic token or currency unit. This is where most of the permissioned blockchains play within enterprises.

6. Use your own blockchain (or another blockchain), including a token or currency unit, to create an economic network of value, for example, MaidSafe,⁴ which creates a market for unused computing resources over a peer-to-peer network of users.

12 FEATURES OF A BLOCKCHAIN PLATFORM

If you need to evaluate a given blockchain platform, the following features are important:

1. 1. Programmability. What specific programming languages are available?

2. 2. Scalability. How many nodes can the blockchain grow? Will there be upper limits?

3. 3. Upgradability. What is the track record of the developers for delivering enhancements and upgrades to the blockchain?

4. 4. Transactions manageability. Is there real-time transparency for all transactions?

5. 5. Visibility. Do you have a full view on the blockchain activity?

6. 6. Affordability. What is the cost of deploying that technology?

7. 7. Security. What is the documented confidence level in the blockchain’s security?

8. 8. Speed/Performance. What are the upper limits for speed in validating transactions?

9. 9. High Availability. What is the uptime’s track record?

10.10. Extensibility. Can you extend the basic blockchain functionality with a variety of add-ons?

11.11. Interoperability. Does it inter-operate well with other blockchains or related technologies?

12.12. Open Source. Is the code open source? What is the level of collaboration and contributions from a variety of developers?

13 STRATEGIES FOR CIOS AND CORPORATE EXECUTIVES

Issue 1: Blockchain Redefines Legacy

Large companies are always battling with their legacy applications, because these can be anchors that drag them when new technologies arrive. Even when you thought corporate IT was safe with modern software environments that make use of modular cloud-based capabilities, container-based technology to facilitate operations deployments, or continuous delivery with agile and rapid developments practices, the blockchain is yet another “modern technology” that will need to be absorbed and integrated into the technology toolset of any software development teams.

Issue 2: Blockchain is a Strategic IT Platform

As clearly mentioned in Chapter 1, and expanded upon earlier in this chapter, the blockchain, in its fullest form, is a new major software development platform. Therefore, it is becoming increasingly strategic. Strategic means that it is not just there to reduce costs and improve transactions latency. Strategic means that it needs to find strategic usages that can give you a competitive advantage. Specifically, the intersection of private and public blockchains will yield some very innovative applications, but that exploitation will only become possible when internal organizations are at par with the advancements in applying public blockchain technology.

Issue 3: What Competencies?

There are 5 categories of competencies required to fully roll out blockchain solutions within a company: Education, Discovery, Design, Development and Management.

Education: Learning the basic functionality of a blockchain, and what it enables generically.

Discovery: Identification of areas of opportunities by answering where does the blockchain fit, and what can we do with it?

Design: What solutions functionality will we need to address the potential we saw in the discovery phase? How will it affect what we are doing, including the business process, contractual and legal requirements?

Development: Software development, integration, and deployment of the technology.

Management: Ongoing software maintenance, support, iterative evolution, new features, and updates.

Most companies cannot develop expertise in all of these areas, but they may partner with outside firms for specific aspects of these steps. Knowing how to program blockchains will be a required competency, just as important as programming Web Apps.

Issue 4: What Partners to Choose?

Every organization sits at a different starting point, based on their resources and capabilities, so the chosen approach will rest with your particular situation. The following table segments the various approaches:

Issue 5: Back-end Integrations

When blockchain applications start to reach full deployment levels, they will eventually need to integrate with a variety of back-end systems, just as customer-facing Web and mobile applications had to integrate with existing enterprise systems. However, the blockchain also has the potential to replace some back-end processes, so you must take that likely scenario into account. But keep in mind that it will be easier to start implementing blockchain solutions in some new segments, without internal integrations. If your starting position includes your current systems, then you are inherently extending your implementation horizon by potentially as long as an extra 18-24 months. So, why not consider starting with no baggage and earn new customers who want to try something new?

Issue 6: Blockchain as a Shared Services Platform

In addition to internal applications and use cases, there will be a number of new opportunities for creating shared blockchain services, either at the vertical level (e.g., a particular financial services application), or at the horizontal level (e.g., a generic records verification service).

Issue 7: Disrupt or Construct?

For startups, there is no doubt the blockchain is a disruptor, but large companies do not like to disrupt themselves unless they are forced to. Within large companies, the first likely scenarios will be to deploy blockchain technology to strengthen their existing operations, by achieving new levels of efficiency or seeing cost reductions. However, it may not be enough. The specter of outside disruption will still loom if you stop short at the constructive/defensive stages.

Issue 8: Blockchain As the New Database

The blockchain as a database is a recurring theme in this book, so you might as well have as many blockchain-savvy developers as you have database-savvy developers. Knowing when to use a traditional database and when to use a blockchain will be important, and knowing how to optimize their dual operations will be even more important.

Issue 9: Blockchain Platforms

In 2016, we are seeing many pieces and choices, and “hand assembly” is still required. We may be in similar stages as when we had to build Web pages by writing HTML code, page by page. Blockchains that come out of the box will be a welcomed evolution, although Blockchain-as-a-Service is a step in that direction.

Issue 10: How to Get Educated

You can take a proactive approach to educating various departments about blockchain technology, or you can wait until the market continues to educate everybody generically. If there is no sense of urgency, it probably means that either you have not taken the time to understand the full potential of the blockchain, or that the blockchain is not being led by the right person whose job will be to light-up the required sparks within the various business units.

Issue 11: Dead-End vs. End-to-End Proofs of Concept

Proof of Concepts (POCs) are popular in some large companies, as a way to dip your toes into new technology without getting totally wet. But the risks are that they could be timid experiments that do not show commitments and they might reach a dead-end, because they will not always allow you to see the potential benefits. It’s better to implement smaller blockchain projects end-to-end where you can see results and a full lifecycle of usage with real users. That said, POCs can be used to narrow down a portfolio of committed projects, but you need to move beyond them.

Issue 12: Business Process vs.Technology

I have long argued that implementing the blockchain is 80% about business process changes and 20% about figuring out the technology behind it. Of course, this assumes that you want to be ambitious enough to tackle the required toughness in changing business processes. If you think that the blockchain technology is not ready yet, or has some weaknesses that might be solved later, then use that time to start reengineering your business process, and by the time you are done the technology will be ready.

Issue 13: Use Cases Saturation

Brainstorming to find use cases is good as an initial entry point, but it is not enough. The risk is in thinking that use cases are disposables. You try them, and if you do not like them, you throw them out. Use cases could lead to something, or maybe not. The term “use case” assumes that something has to fit within existing processes, so the bar is not high enough for making more difficult choices that go beyond the obvious, and into the innovation discovery potential. The next section tackles how to think about the blockchain with an innovation hat on.

DECISION-MAKING FRAMEWORK

Often, the first question that comes to mind is: “What problem is the blockchain solving?” It is a good, but self-limiting question, because it assumes that the blockchain can only solve known problems.

What if the blockchain could create new opportunities, instead of solving existing problems? Then, you will need a different mindset to take that direction. The Internet did start by solving specific problems that world trade was complaining about, but it provided us electronic commerce as a novel version of global trade. If you asked the newspapers, they didn’t think they had any problems, but the Internet challenged their industry. Social media was not a solution to a problem, but an enhancement on human relations.

We could categorize the blockchain’s impact into three broad categories:

1. Solving Problems

2. Creating Opportunities

3. Applying Capabilities

Solving Problems

The “problems” category comes in a variety of flavors. It forces the thinking around understanding if the blockchain has immediate applications that could impact:

Cost savings: Back-office? Middle-office? Customer service?

Productivity: More throughput?

Efficiency: Faster processing? Compliance/Reporting enablement?

Time delays: Faster clearing? Faster settlements?

Quality: Less errors? More satisfaction?

Outcomes: Growth in revenues? Increased profits?

Risk: Less fraud? Less exposure?

Although the above is not a list of “problems” in the pure sense of the word, it is a list of fundamental business parameters that any organization wishes to streamline. In this case, the blockchain is an invisible enabler that does not change much to the externally visible parts of a business. Rather, it is more of an internal black box that does something better than before.

Hopefully, you are convinced that just asking what problem the blockchain solves is a limiting question on its own. For example, if you look at the startup innovation around banks in FinTech, you will see plenty of cases where these new companies did not really solve a “problem” the banks had, but they tackled a particular market or service differently. So the tipping point was to compete by reframing the opportunity, for example, peer-to-peer lending, unconventional home loans, really fast approval cycles, efficient robot investing, and so on.

Creating Opportunities

It is more difficult to figure out opportunities, because that requires applying innovation, being creative, and making profound changes. These are more difficult objectives to achieve, because business process changes are involved, and it takes a longer time to change them. When you sum it up, the blockchain is about 80% business process changes, and 20% technology implementation.

Creating new opportunities includes entering new markets and/or providing new services that the blockchain enables and that were not possible before. It requires a more imaginative process of dreaming up what’s possible and what wasn’t done before. It requires thinking outside the proverbial box, and a deep understanding of what the blockchain can enable in the areas that it is strongly suited for.

New Services Opportunities:

· New Intermediaries

· New Networks

· New Marketplaces

· New Clearinghouses

· New Authorities

These new opportunities could also develop as new markets around 3 spaces: inside your organization, collaboratively between two or several organizations, or in totally new areas that do not initially interface with internal processes. Arguably, anything done on the outside might be easier to tackle because you’re not initially tied down by your core integration requirements.

· Inside: Can we attract a new segment of customers?

· Outside: Can we enter a new market outside of our core?

· Collaborative: Is there a white space we can collaborate on?

Applying Capabilities

The third category of thinking involves applying the blockchain’s capabilities from the ground-up.

In these cases, a deep understanding of the blockchain’s capabilities will lead you to discover implementation ideas for your own business. It’s a lot easier for someone to understand the blockchain than for a blockchain person to understand someone’s business.

Here’s a list of generic capabilities that the blockchain enables:

· Rethinking intermediaries

· Bundling services

· Unbundling services

· New flows of value

· Decentralized governance

· New legal frameworks

· Running smart contracts on the blockchain

· Sharing a distributed ledger

· Creating/Issuing digital assets

· Embedding trust rules inside transactions and interactions

· Time-stamping

· Implementing digital signatures

· Notarizing data/documents to produce proof

· Creating records of a business process, event, or activity

· Verifying authenticity of data/ownership/documents/assets

· Confirming authenticity of transactions

· Ensuring that contractual conditions are undeniably met

· Reconciling accounts

· Finalizing financial settlements

· Embedding digital identity in applications

· Providing escrow or custodial services

· Enabling smart things to transact securely

For example, you cannot directly compare the blockchain to a database and say, “The database does this better therefore we do not need blockchain transactions.” The blockchain is a new para-digm. Rather, start by running smart contracts on a blockchain, and ask yourself what it can enable, then work backwards to see how you can tie it back to your business.

When looking at your blockchain strategy, you need to tackle all three elements in parallel: problem solving, opportunities discovery, and capabilities enablement. That’s the trinity of sanity for an organizational blockchain strategy.

KEY IDEAS FROM CHAPTER SIX

1. Managing an internal blockchain strategy takes some concerted effort and leadership.

2. The “Blockchain Czar” approach is an effective method for booting-up and coordinating disparate efforts in large organizations.

3. A blockchain implementation will have a number of new architectural and functional components that need to work in harmony.

4. Companies will need to decide what implementation approaches to choose, based on their own competencies and choice of external partnerships.

5. You should not just see the Blockchain as a problem-solving technology. Rather, it is a technology that lets you innovate and target new opportunities.

NOTES

1. Ira Magaziner, https://en.wikipedia.org/wiki/Ira_Magaziner.2. “List of U.S. executive branch czars,” https://en.wikipedia.org/wiki/List_of_U.S._executive_branch_czars.3. MaidSafe, http://maidsafe.net/.