Blockchain technology has gone through various stages of hype. To mitigate any negative impact and plan for future viability with Blockchain, technology leaders need to be aware of misconceptions that can lead to disappointment and failure in blockchain projects.
Key considerations
Hype about blockchains has prompted many enterprises to undertake blockchain projects that amount to deployments of technology for its own sake, rather than to solve business problems.
Most blockchain proofs of concept (POCs) are an attempt to improve current processes and don’t use the full capabilities of blockchain technology. Further development in blockchain-enabling technologies is needed before organizations can leverage the complete spectrum of blockchain offerings.
The blockchain data structures and consensus algorithms that are most proven today are constrained in transaction scalability and, by design, require increasingly massive amounts of compute, storage and networking resources in order to grow.
Blockchain’s decentralized public consensus increases trust across multiparty business value chains. But few enterprises make use of this key blockchain innovation.
Suggestions
Organisations evaluating what benefits could result from embarking on a blockchain project should:
Structure their blockchain project to also prioritize learning, in addition to immediate business value, and use that learning to gain insight into new business models, markets, products and services from the resultant new operating models.
Experiment with tactical narrow-scope deployments of blockchain technology in the short term, with a focus on innovation-driven business value accompanied by an understanding that many selected platforms will have a useful life of at most 12 to 24 months.
Plan a migration path off, or interoperability for, or substantial upgrades and additions to, any current-generation blockchain platform, because viable platforms that scale will only arrive in the next generation.
Blockchain projects common mistakes
Every region and industry have developed an intense interest in how blockchain can be used to improve market efficiencies and reduce costs and latency. But there’s still a significant gap between the hype and market reality. Resolving interorganizational business process, governance and performance issues are extremely difficult and complex. They rarely receive the early or sufficient focus they deserve. As a result, the vast majority of organizations get stuck when they first encounter these challenges while attempting to move their blockchain projects from proof of concept (POC) to any form of scaled development.
Among those organizations that have invested in blockchain, client inquiries indicate that the majority of POCs fail to get beyond that initial experimentation phase. Challenges exist in terms of business case viability, governance maturity, technology maturity, availability of skills and even an underlying willingness to alter the way the core enterprise and industry works.
The blockchain platform market and blockchain-enabling technologies that will be used by organizations to carry out their enterprise blockchain projects are still quite nascent. As a result, there is no industry consensus on product concept, feature set, core application requirements or target market. We do not expect there to be a single dominant platform within the next five years. Instead, we expect a multiplatform world to emerge through the midterm five-year range and beyond. It is likely that large enterprises will initially use multiple platforms driven by different use cases and influenced by:
Participation in multiple consortia (each one with its own platform) to reflect diverse parts of enterprise business activities
Internally developed or acquired platforms by different business units
Platforms embedded in solutions and delivered by third-party vendors
Therefore, CIOs need to carefully assess their respective enterprise’s risk appetite. They should ensure that business leaders clearly understand that investment should be driven by deep analysis that confirms the potential of blockchain to enable different business and operating models that CIOs are striving to achieve. Blockchain technology investment and development must be conducted in view of the future of industries, not just the competitive specifics of a single organization.
To understand how to get value out of a project that would otherwise be destined to fail, it is first necessary to understand the root causes of failure. Figure 1 summarizes the seven most common mistakes made during enterprise blockchain projects. We will explore each of these in detail and present actions on how to avoid them.
Most Common Mistakes Made During Enterprise Blockchain Projects
Figure 1. The Most Common Mistakes Made During Enterprise Blockchain Projects
#1: Misunderstanding or Misusing Blockchain Technology
Many organizations have been seeking to explore the potential of blockchain in their business. For many, this has translated into developing POC solutions with providers. However, Leading analysts’ research has found that most POCs for permissioned blockchains (where membership of the blockchain network is controlled) are not using key blockchain innovations — notably, decentralized consensus or tokenization. Instead, most commercial and government entities today use permissioned blockchain to support shared record keeping and asset tracking, supported by distributed ledger technology (DLT) data structures.
Organizations use blockchain technology to support compliance, brand protection (such as flagging counterfeits or identifying infected food lots) and other use cases that need a single shared version of the truth based on immutable data and audit trails. Nearly two-thirds of the POC projects we examined were solely for recording data on permissioned or public blockchain platforms.
In summary, from a technology point of view, blockchain’s DLT and associated data security components are the features that organizations most commonly embrace today as they discover a more secure and reliable method of conducting business as usual. DLT is a component of blockchain and is also implemented in nonblockchain data structures.
The fact that organizations are so infrequently using complete blockchain features beyond DLT — such as decentralized consensus, tokenization and smart contracts — calls into question whether blockchain is even needed by these organizations. Yet, these more advanced blockchain features can underpin truly disruptive ways of doing business across parties that don’t trust each other, even if they do introduce more implementation complexity. Most organizations will need time to imagine these disruptive use cases, and to develop the business processes and technology to support them with their partners and value chain.
#2: Assuming That Current Technology Is Ready for Production Use
The blockchain platform market is largely composed of fragmented offerings that often overlap, with some also being used in a complementary fashion. Many of these are from small, venture-funded startups, while others are community-driven, open-source projects (Bitcoin, Hyperledger and Ethereum being the most notable examples) without overt control of a single, focused vendor.
Some platforms are also under the auspices of a consortium (R3 Corda being a notable example). A few listed in “Market Guide for Blockchain Platforms” are not platforms per se, but instead constitute subsystems or functional components; for example, storage subsystems such as BigchainDB and InterPlanetary File System (IPFS), which can be leveraged by other platforms. Some of these subsystems are evolving into platforms.
A number of platforms are primarily a currency and only secondarily a platform — some examples have expanded beyond their initial intended use. For example, RSK turns what is mostly a currency (bitcoin) into more of a platform by adding smart contract capability. Others are application-level solutions, possibly targeting a vertical sector, that have an embedded platform. An example of this would be Factom, which has its own foundation-layer blockchain technology to enable its solution to publish data proofs for the purpose of proving data. But it can be used to build other solutions and enable them to evolve into a platform.
These blockchain platforms are trying to differentiate themselves in various ways:
Universal computing (world computer or operating system).
Higher transaction throughput or number of nodes through alternative consensus algorithms or data structures.
Greater confidentiality of data achieved through various means (for example, closed private network, homomorphic encryption of fields in the transaction data record, zero-knowledge proofs).
Purpose-built programmable behavior to model contracts governing transactions (“smart contracts,” for example).
Higher-level and more familiar language for smart contracts.
Interoperability protocols among various blockchain platforms and distributed ledgers.
Tokenization for the monetization of multiple forms of assets reflected in a digital context.
#3: Confusing a Limited, Foundation-Level Protocol with a Complete Business Solution
Some business and IT leaders must solve problems in diverse areas such as supply chain management or medical information systems. Because blockchain technology has been discussed in conjunction with these scenarios, there is an implicit assumption (what we have termed “wishful thinking for magic software”) that the foundation-level technology is not that far removed from a complete application solution. Such solutions typically consist of a multilayer technology stack built on a base-level foundation, which includes middleware such as an application framework and horizontal subsystems underneath vertically oriented application logic. The complete solution will consist of a user interface, business logic, data persistence and interoperability mechanisms.
The reality is that blockchain, as a foundation-level technology, is better viewed as a “transport protocol for value.” In that sense, it is analogous to how TCP/IP is a foundation-level transport protocol for data packets across the internet. No one would confuse the TCP/IP suite of communication protocols for a complex, full-featured application such as an email system (for instance, Gmail) or a web e-commerce system (such as Amazon) or a complex social network application (such as Facebook). These internet applications exist because there have been many years of development efforts by a multitude of skilled programmers writing millions of lines of code. Most of these internet-based applications wouldn’t exist, and would have no purpose or value, without the foundation protocol (including TCP/IP, SMTP and HTTP). But that foundation comprises a minuscule portion of the overall system (less than a few percent, if one counts lines of code in the complete system).
Likewise, blockchain solutions for innovative supply chain management systems, decentralized energy trading systems or medical records management cannot exist without the underlying blockchain protocols. However, the actual protocol will comprise less than 5% of the complete solution. This is something that many CIOs do not consider when embarking on an ambitious blockchain project. The situation exists even if the blockchain technology is performant, scalable, mature and secure, all of which are yet to be proven in the new generation of blockchain platforms.
A related consideration is that all solutions in a given application category are not equivalent. Not only must the decentralized application (dapp) be built with considerable expenditure of staff time and money, but the result must be functionally complete and well-designed. The successes mentioned earlier (Gmail, Facebook and Amazon) were each just one entrant among a field of many competitors. The competitors were often of lower quality, had less functionality and an unwieldy user experience, or poor packaging and marketing versus the eventual winner. These aspects and challenges of building a complete solution should also be considered by IT leaders when building a successful blockchain-based solution.
#4: Viewing Blockchain Technology Purely as a Database or Storage Mechanism
Some CIOs hear the term “distributed ledger” and think of blockchain as a data persistence mechanism or distributed database management system (DBMS). Although this is not far from the core concept, it is nevertheless far enough to be off-target and to result in misaligned enterprise blockchain projects.
In its current form, blockchain technology implements a sequential, append-only and “immutable” (if records are tampered with, it is readily apparent) record of significant events such as transactions. It does not implement the full create, read, update, delete (CRUD) model that is found in conventional DBMS technology. Instead, only the first two operations (create and read) are supported. Further, current blockchain platforms cannot support complex data models, nor should they; nor can they currently guarantee low-latency and offer high throughput, and deliver other capabilities found in modern, distributed DBMSs. Some blockchain platforms are in the process of adding these functions but, upon initial release, will likely be unproven.
The fundamental design trade-off that led to the creation of blockchain platforms was to accept limitations in the aforementioned data management capabilities to enjoy an authoritative, immutable, trusted record of events arising out of a dynamic collection of untrusted parties. This approach enables the goal of not having to rely on a centralized server and to avoid trusting a single central organization. Future generations of blockchain technology will attempt to span both high-function and high-performance data management, storage and retrieval, in addition to the basics of a secure immutable ledger. But that is not currently the case, and expecting otherwise could cause a misalignment that will negatively impact the project.
#5: Assuming Interoperability Standards Between Blockchain Platforms Exist
Some vendors of blockchain technology platforms talk about interoperability with other blockchains. The rationale is that, at this point in the market landscape, there are multiple competing alternatives that will be adopted by different organizations, or even within a single organization. Interoperability mechanisms can ensure that a specific platform does not become a dead-end choice. But it is difficult to envision interoperability when most platforms and their underlying protocols are still being designed or developed. Indeed, vendors are still reticent about what is in their products and how they will function. Most are still “works in progress” and susceptible to a high degree of volatility, technology evolution and “pivoting” to meet shifting market requirements.
Through a layer of abstraction or via an API, it is possible to have some interoperability at the most basic level (adding a transaction record to the ledger). But most blockchain platforms have much more ambitious scope that does not lend itself to a common abstraction. If history is any guide, enterprises should view vendor discussions regarding interoperability and standards as a marketing strategy — one that may benefit the supplier’s competitive standing, but not necessarily deliver benefits to the end-user organization.
For example, consider the enterprise portal sector in the 2000s. During that period, the portal sector was a highly dynamic and crowded competitive arena, with dozens of vendors (both small and large) jockeying for competitive advantage. There was ongoing discussion of portal standards — JSR 168 and Web Service for Remote Portlets (WSRP) — that lasted for much of the past decade. Support for standards was a key aspect of vendors’ marketing messages and of technology selection decisions by enterprises. But, at the end of the day, the number of enterprise portal deployments that relied on these standards in a significant manner was minuscule (less than 5%). The failure of standards to have a significant impact was due to the rapidly evolving technology platforms. These were similar in concept but different in detail, combined with a standardization process that started quickly but then slowed down dramatically as the market evolved (and some vendors were finding market success without standards).
This pattern is likely to be repeated in the blockchain sector. Also, while it is possible to define an API in blockchain technology for simple data persistence, this ignores the real value of blockchain platforms: The smart contract capability that adds fine-grain dynamic behavior to transactions — a mechanism that differs from one platform to another, not just in detail but in concept. Smart contracts written for one platform are unlikely to run on another, in the same manner that a C# program on .NET will not run in a Java environment, even though both platforms are similar in concept. That said, there is the possibility that side-chain mechanisms will allow heterogeneous blockchains to interoperate with each other, but these will be de facto mechanisms rather than standards defined by standards bodies.
#6: Assuming That Smart Contract Technology Is a Solved Problem
Smart contracts (for example, for managing, assigning or valuing assets) are perhaps the most powerful aspect of blockchain-enabling technologies in the long term. Smart contracts add dynamic behavior to what would otherwise be transactions of passive objects. They enable not just the “Internet of Money,” but the “Internet of Programmable Value” (what we, in other contexts, calls the “programmable economy”).
Conceptually, smart contracts can be understood as stored procedures that are associated with specific transaction records (for example, a value transfer in the Bitcoin stack cannot be completed without executing a short program written in Bitcoin script). Unlike a stored procedure in a centralized system, smart contracts are executed by all nodes in the peer-to-peer network, resulting in challenges in scalability, manageability and funding of resource consumption.
As intriguing and powerful as they seem to be, smart contracts currently (and are still likely to in the near future) face daunting challenges (in scalability, auditability, manageability and verifiability) that have yet to be adequately addressed. Smart contract capability is evolving in diverse, innovative and incompatible ways across different platforms in the blockchain category.
The current approach is to use languages that are similar to mainstream established languages such as Java and C++. Unfortunately, these do not all currently meet the elevated requirements for bug-resistant, secure, trusted code. Although it is possible to build useful solutions on smart contract platforms such as Ethereum, these should be viewed as highly vulnerable to errors and compromise, and are not understood or transparent to validating nodes.
#7: Ignoring Governance Issues for a Peer-to-Peer Distributed Network
Multiple new capabilities must be acquired by enterprises to fulfill the potential of blockchain. Among these are both internal and external data and process governance. Governance is a critical issue for public blockchains, but less so for private or permissioned blockchains, since it’s likely the latter will be governed by the blockchain “organizer.”
If large channel-master organizations such as Walmart, Amazon or other similar entities are the main sponsor of a particular blockchain, they will typically set the standards for membership and governance, and resolve the disputes.
Public blockchains are a different matter. Governance for Ethereum and Bitcoin is defined, but unclear to most participants, which is a worrisome leading indicator. Governance in these blockchains is aimed at technical issues only. Human behaviors or motivations, both of which are important factors in the success or failure of any system, are only addressed in terms of how participation is structured (for example, voting rights). The ongoing strong influence of currency speculators on Bitcoin prices makes clear some of the consequences of inadequate governance — or, more specifically, of governance that addresses only technical standards and not motivation, acceptable and unacceptable behaviors, and good versus bad outcomes.
Disputes in both Bitcoin and Ethereum have been resolved in the recent past by “forking,” or splitting off a segment of the community, a practice that inevitably reduces mass for a given community. The motives of blockchain participants range from technical to social, financial and criminal. Deep conflict between subgroups that is unresolvable short of forking is likely in the absence of governance mechanisms that address shared commercial, public sector or human factors and values. True decentralization (versus replication controlled by a centralized permissioning authority) and permissionless entry into blockchains will likely create additional governance conflicts and challenges.