Over the last few years, blockchain technologies have gained significant interest in the enterprise space as a potential disruptive force in the way businesses share and exchange data, act upon that data, and regulate its use. At Velosys, we have been delivering projects that leverage these technologies for several years, and our first-hand experience and observations helped us develop a process that formulates a maturity model to understand where an entity is in its blockchain adoption journey and what leads to successful deployments. This post describes the five maturity levels we believe are part of a natural progression in this journey. A basic understanding of blockchain technology and its benefits is recommended first – a short primer on this can be found in one of our prior blogs: Blockchain Technology in Geographic Information Systems (GIS).
Level 1 – Education and Technology Selection
The first application at scale that brought blockchain into the limelight was Bitcoin. Upon its origin in 2008, Bitcoin created the foundation and concepts upon which an entire ecosystem has developed – the world of cryptocurrencies. In parallel, technologists recognized the utility of the technology itself and started to adapt it to use cases and needs specific to private enterprises: several open source and proprietary projects/products have been developed to cater specifically to the enterprise use.
Fraught with many ups and downs, concerns about its utility and high energy use, and lack of a clear regulatory environment, the crypto ecosystem has nevertheless demonstrated growth and staying power in the marketplace. While the crypto industry initially catalyzed blockchain adoption in the enterprise space, over the last few years, the crypto industry and the enterprise blockchain space have been navigating their own independent progression paths.
It is important to understand the history and evolution of blockchain because any initial consideration for its usage within an enterprise environment is likely to start with this foundation. Generally, the more a company believes in the different future evolution paths of blockchain use in the enterprise space vs the crypto industry, the more likely it will be to dedicate resources towards its exploration and adoption.
The types of blockchain technologies that exist in the marketplace is the next important research area a company will have to delve into. The main distinction to consider here is the difference between private/permissioned vs public blockchains. For most enterprise use cases, participation in blockchain networks needs to be limited to known entities that go through an approval process. As such, the use of a permissioned blockchain is often favored.
Once the most suitable type of blockchain technology is well understood, the next logical step is to narrow the choices of projects/products through a selection process to one or two options to explore further. Some of the most popular candidates in the permissioned blockchain space are products from vendors or open-source projects such as Hyperledger Foundation (Hyperledger Fabric, Indy), R3 (Corda), Digital Asset (Canton), Consensys (Quorum) and Axoni (AxCore).
During this stage, it is useful to start identifying outside partners who would be interested in joining a blockchain network and understand the potential future forms of its governance. Once the product(s) selection is complete, it makes sense to start trying them out.
Level 2 – POC Deployment
A company at this maturity level is engaged in the deployment, in a POC context, of one or more blockchain technologies to evaluate their capabilities, map functions to business needs, and learn how to use them. We recommend considering the following while executing POC deployments:
Technological acumen: Blockchain deployments involve a variety of components with varying degrees of complexity for network topologies and they sit at the intersection of a few important and modern technologies. These deployments require a solid understanding and strong technical skills across a few areas, such as: cryptography, networking, microservices, and infrastructure automation through DevOps and Infrastructure as Code. To simplify this complexity, some providers provide blockchain networks as cloud solutions with varying degrees of success. Based on our experience, a POC stage project might benefit from using such solutions. However as soon as these deployments need to be scaled up (adding more external participants and/or types of network nodes, etc.), the solutions from these providers are not sufficient. In our view, it makes more sense to roll up your sleeves and experiment directly with the technologies involved.
Production vs non-production deployments: Frequently, the initial POC phase stops at a deployment in a non-production environment. However, to better understand the solution’s capabilities, a project team can choose to deploy the blockchain network in a production environment. Note that in this case, any functionality provided by the blockchain network (or data inside it) is not considered the system of record; instead, the blockchain system runs in parallel to other production systems which act as the system of record.
External participation in the network: At this stage, in most cases, the enterprise will create a blockchain network which includes nodes that it fully controls and operates. This is a necessary step in the learning process and provides important feedback before increasing a network’s complexity by adding external participants and/or organizations. While a production deployment (acting as a system of record) which only includes nodes fully controlled by the enterprise can be useful in some cases, the most impactful benefits of a blockchain deployment can only be realized when multiple organizations are involved. The next stage focuses on introducing external participation at the most basic level: data sharing.
Level 3 – Cross-Enterprise Data Sharing
The simplest way to view a blockchain network is to consider it a distributed ledger, or to use an analogy from the relational/no-SQL databases: a database that can have its data written to, replicated to, and read from multiple locations – geographical sites and/or endpoints owned by different entities.
This data sharing is one of the core tenets of blockchain technology. One particularly important innovation brought forward by blockchain is the sharing of not just the current state of the data (i.e., current state of the world) but also of a full log (or history) of all the data changes up to the current state. A new node that joins an existing blockchain network will have a complete view into the full history and current state as soon as all blocks of data are synced to it. The largest benefit from deploying a blockchain is realized when data is shared across multiple organizations.
So, at this stage, an enterprise will seek to add nodes to the blockchain network that are owned by other organizations. The obvious premise for this transition is that multiple organizations can benefit from sharing blockchain data. It is not necessary that all organizations perform data writes; benefits can still be achieved when a subset of the network participants only do data reads. To be useful for all participants, a deployment of real production data sharing is needed for these types of setups, even if the blockchain network might still only act as a parallel system initially.
Whenever multiple parties are involved in data exchanges or sharing, consideration must be given to using data formats that all parties understand and can easily code to. Choosing to adopt an industry standard (e.g., FIX, ISO standards, HL7, etc.) to represent blockchain data can considerably reduce the effort of data standardization across network participants and makes it easier for each organization to process and distribute data that is shared on the blockchain within their own internal systems.
Another key component of blockchain networks are smart contracts – pieces of code that work with blockchain network data and execute business logic. At this stage, smart contracts act more as “semi-smart” contracts: they are just a mechanism to persist and read data from the network with simple validations on the data inputs they receive. A more full-fledged implementation of smart contracts happens at the next level.
Level 4 – Common Code Execution
Data exchanges across multiple entities have been done for many years via a variety of mechanisms – e.g., in batch mode via file transfers, in real-time/near real-time via queues or APIs. While distributed ledgers can make the data exchanges/syncs faster, more efficient, secure, and transparent, this is by no means a new concept. When the same data is shared across multiple entities, it is highly likely that these entities (or at least a subset of them) must apply similar processing on that data. Blockchains have introduced another innovation where implementation of common processing/business rules can also be shared via smart contracts.
Through the application of network policies, a blockchain network’s participants agree on smart contracts definitions, the required data, and their deployment and versioning. Thus, smart contracts vetted by the participants can be deployed across the network and reused by participants. For example: a consortium of manufacturers producing similar products chooses to leverage the same network of shippers and distributors to distribute their products to end users. These manufacturers, shippers, and distributors form a blockchain network to support these business processes. One of their most common business functions is creating invoices. Instead of each manufacturer creating their own application to generate invoices, they set up a common smart contract deployed on the blockchain network.
The data needed by smart contracts is another key element to consider when they are designed – smart contracts should only require data that belongs to these categories:
- Data on the blockchain that is shared with all network participants.
- Data on the blockchain that is available to only some network participants. (Permissioned blockchains allow participants to restrict access to selected data to only a subset of participants or even none at all.)
- External oracles (i.e., data services) that all participants that execute smart contracts have access to.
If a smart contract requires any other kind of data, its reuse in the blockchain network becomes significantly degraded and this calls into question whether the business logic implemented in this smart contract makes sense to be deployed at all.
Enterprises that transition to this phase can leverage their participation in the blockchain network. Up to this stage, one enterprise can act as the single network administrator and implementor of policies that govern who has access to the network and to what extent. In the next stage, these responsibilities are delegated to a consortium of enterprises.
Level 5 – Consortium Governance and Control
Decentralization is one of the other tenets at the foundation of blockchain. There are various degrees of decentralization but at its core this approach attempts to:
- Reduce operational concerns related to single points of failure.
- Distribute control and management to as many participants as possible.
Some cryptocurrency systems put maximum emphasis on decentralization and use it as a prerequisite for building in censorship-resistant characteristics. However, higher degrees of decentralization mean larger trade-offs in terms of the speed and volume of transactions that can be processed on the network.
In the enterprise space, the level of decentralization will inherently be lower since access to joining the network is limited. Also, in an enterprise blockchain network, only a small set of participants need be part of the group that forms the consensus necessary to order transactions (to ensure their integrity and atomicity) and group them into blocks. The consensus algorithms supported by most enterprise blockchains allow much higher throughputs and transaction volumes compared to what is possible on a public blockchain, especially if only a handful of network participants are involved in forming the consensus.
As the blockchain network grows, participants should consider expanding the number of participants responsible for the following network functions:
- Consensus forming for processing and committing transactions
- Approval processes and policies for allowing new participants to join (or leave) the network
- Authorization rules that control which participants have access to different subsets of the data in the network
- Authorization rules that govern the lifecycle for managing the use and deployment of smart contracts on the network: implementation, participants’ installation/execution permissions, upgrades, and versioning
Note that different enterprise blockchain products have various degrees of sophistication in terms of how well they support the definition and application of policies to enforce these rules. The most mature blockchain deployments are characterized by a well-balanced and representative participation in the consortium of network members that governs the definition, application, and control of the functions listed above, which, in the end, helps achieve the goals of decentralization.
Conclusion
As the Gartner Hype Cycle for Blockchain showed in 2022, blockchain platforms are poised to exit the Trough of Disillusionment phase. Interest, experience, tooling, and applications of their use in the enterprise keeps increasing. If an enterprise sees potentially suitable use cases for deploying and/or joining a blockchain platform, the sooner it engages in climbing the maturity ladder, the higher the competitive advantage it can achieve.