- Department of Industrial Engineering, University of Stellenbosch, Stellenbosch, South Africa
This article outlines the research and development of a blockchain assessment framework which enables the assessment of the technical suitability, high-level design, adoption approach, economic feasibility, and business value potential of a blockchain solution with a particular organization for a specific process. The framework is a comprehensive, high-level, and generic assessment approach that enables better decision-making regarding blockchain exploration. Blockchain is a novel technology with the potential to disrupt several industries through its possession of many desirable functional characteristics, including, but not limited to, immutability, transparency, decentralization, and secure. Cryptocurrencies and these desirable characteristics have created hype around blockchain, consequently leading to blockchain projects with minimal understanding of what the technology is capable of and beneficial for, resulting in excessively high failure rates. Attempts have been made by researchers to reduce these high failure rates by creating a better understanding of blockchain, as well as creating assessment approaches. However, these approaches tend to apply to specific narrow use cases, or the approach is not comprehensive and only considers one aspect of blockchain assessment. This emphasizes the need for a comprehensive and generic blockchain assessment approach to aid with better decision-making regarding blockchain within organizations. This article aims at addressing this need by creating a blockchain assessment framework to aids with deciding whether it is worthwhile investing more time, effort, and money into blockchain exploration. The context of the study is set in the introduction, this is then followed by a brief explanation of the blockchain technology. Thereafter, the blockchain assessment framework is presented, followed by a brief explanation of the demonstration and validation of the framework using a case study and expert analysis. The framework is most valuable during the initial stages of blockchain exploration and creates momentum for further blockchain exploration in an organization. The study concludes with the limitations and future research recommendations.
1 Introduction
Organizations need to continually assess and implement emerging technologies to enhance their competitiveness and productivity (Oliveira and Martins, 2011). There is ample literature and expertise to help with the adoption of a variety of more common technologies. The problem begins where novel, disruptive technologies enter the technology sphere that have the capacity to change the foundation that organizations operate on and leave little time to make an implementation decision.
Blockchain is such a technology with this potential to disrupt the foundations of a variety of industries (Risius and Spohrer, 2017; Sikorski et al., 2017). Often a connection is made directly between blockchain and the financial industry because of its association with cryptocurrencies. However, once blockchain’s copious beneficial characteristics are understood it is seen that there are many industries that could benefit from implementing it, from government to energy to food (Allessie, 2017; Brilliantova and Thurner, 2019; Bürer et al., 2019; Garcia-Torres et al., 2019; Taskinsoy, 2019).
There is a general misunderstanding of blockchain and its capabilities and consequently a universally agreed upon definition does not exist. However, through assessing the different uses of blockchain and identifying its key components, Sultan et al. (2018) proposes an all-encompassing definition to be:
“A decentralized database containing sequential, cryptographically linked blocks of digitally signed asset transactions, governed by a consensus model”—Sultan et al. (2018, pg. 54)
Blockchain has many beneficial characteristics realized through the different elements it implements to operate as intended. These beneficial characteristics include decentralization, distributed, immutable, and transparency. However, blockchain still has its drawbacks and it is certainly not suitable for all cases, where some sources have claimed blockchain project failure rates as high as 92% (Bellini et al., 2019).
This clearly indicates that blockchain is more nuanced than initially expected and rigorous assessment is required before haphazardly implementing a blockchain solution. This is not to say that blockchain has minimal valuable use cases, but rather that the true value of blockchain in a given use case needs to be fully understood before implementation. This is realized through the many real world use cases and the proposed framework for ample more uses.
Das et al. (2022) propose a framework for facilitating data integrity in document management in construction applications by using smart contracts and developing the solution using a blockchain development platform, Hyperledger Fabric. While Ullah and Al-Turjman (2021) present a framework indicating the use of a decentralized application on the Ethereum Virtual Machine which enables the use of smart contracts to manage real estate deals. Reddy et al. (2021) propose a framework for implementing blockchain in the automotive supply chain. These frameworks highlight the potential of blockchain in many different industries.
Krichen et al. (2022) highlight the current blockchain use cases in a variety of industries, from the Internet of Things to military and defense to healthcare. IBM is making big steps to drive up the use of blockchain solutions, such as tradelens which provides participants with a consistent and comprehensive view of shipment data and the corresponding documents. Individuals are also benefitting with networks such as FileCoin which has created a blockchain network that enables the buying and selling of storage in an open market.
Blockchain has been hyped to a point where the expectations surrounding it far exceed its capabilities and thus projects are undertaken when the technology is not suitable. This overhyping tends to occur with nascent technologies that are not fully understood, where misconceptions are created by excessive fanfare and the fear of missing out on the technology motivates blockchain projects that will never be successful and thus brings high project failure rates (Yaga et al., 2018). These high project failure rates may lead to a point where blockchain is seen as an overhyped technology with no real business value, without ever appreciating what blockchain does offer and the potential it has for solving many modern-day business problems.
Academic researchers have realized the value of blockchain and sought to address the general misunderstanding of it, consequently creating a library of useful resources on a variety of topics pertaining to blockchain, from general overviews of the technology to in-depth research on one technical aspect. There is a section of this blockchain literature focused on assessing the technical suitability, economic feasibility, adoption approach, and business value potential of blockchain solutions in a variety of organizations to address the high project failure rates.
However, blockchain is a complex technology with many considerations and different configurations and assessing it can be a challenging undertaking, with the resulting potential implementations just as challenging (Singhal et al., 2018; Yang et al., 2021). Thus, many of the blockchain assessment studies will focus on one specific aspect of assessment or they will concentrate on a specific use case, as opposed to creating a generic approach to blockchain assessment.
These assessment approaches provide good insight into the different aspects of assessment, but a generic blockchain assessment approach stands to produce more value because of the number of organizations that will find such an approach useful, as opposed to just a handful. Multiple attempts have been made at creating generic blockchain assessment approaches concentrating on different assessment aspects, including technical suitability, economic feasibility, high-level solution design, adoption approach, and business value. Intuitively, a complete blockchain assessment approach will include all these aspects to some degree to allow for better decision-making when assessing blockchain solutions.
All these aspects have been addressed in current blockchain literature to some degree. However, some aspects have received multiple, in-depth attempts while others have only been briefly researched. These blockchain assessment studies rarely address all assessment aspects and thus the literature remains scattered. Furthermore, the different approaches for a given assessment aspect often leave out critical information addressed in other studies on the same aspect. Hiring a blockchain professional to assess blockchain for a particular organization would be a lengthy and expensive process, especially if the conclusion is to not implement a blockchain solution. This highlights the opportunity that exists within current blockchain literature and is presented below.
Problem Statement: Literature on the assessment of fundamental blockchain aspects within organizations—technical suitability, economic feasibility, high-level design, adoption approach, business value potential—is scattered and often lacks generality or thoroughness. Consequently, blockchain assessment is a tedious process and often yields subpar results.
With the above problem statement summarizing the current situation within blockchain literature, the main objective of this study can be identified. The main objective is presented below.
Main Objective: Create a comprehensive, generic, and quantitative blockchain assessment approach to assess the technical suitability, economic feasibility, high-level design, adoption approach, and business value potential of a blockchain solution for a specific process within a certain organization.
The ultimate assessment approach developed in this article will help with initiating the blockchain exploration journey and determining whether further blockchain analysis is worthwhile. The developed approach is not used to indicate whether blockchain should or should not be implemented but should rather be used during the early stages of blockchain analysis to identify the next possible steps in blockchain exploration and whether further analysis is worthwhile. Furthermore, the approach and its development provide a strong foundation from which future research can take place.
2 Literature review
The developed assessment approach does not require any external equipment but relies on the user’s knowledge of their organization and the process being assessed for potential blockchain implementation. As such, a brief understanding of blockchain and its primary components will be beneficial in better understanding the inputs and outputs of the assessment approach.
2.1 Blockchain operation
Understanding how blockchain operates and how its different components lend to its beneficial characteristics will help when using the assessment approach. This narrow technical understanding can be obtained by scrutinizing the definition of blockchain presented by Sultan et al. in Section 1.
The block refers to a mechanism that stores a group of transactions which occur within a specific time domain or until a block size limit is reached, where these blocks are then chronologically “chained” to one another to form an immutable digital ledger (Fernández-Caramès and Fraga-Lamas, 2020). Each of these blocks typically consists of the block body and the block header (Nofer et al., 2017; Yaga et al., 2018). The block body primarily contains the transactions recorded on the blockchain, while the block header contains the block version, timestamp, block hash, parent block hash, and any other necessities that may be required during blockchain operation.
Only the key components of the block header need to be understood to grasp a basic understanding of blockchain’s operation and benefits. The block hash is a 64-character hexadecimal string generated based on the data in both the block header and body, where any slight change in this data will output a completely new hash value (Yaga et al., 2018).
As mentioned previously, the parent block hash (the hash of the block before the current block) is included in the block data with which the hash value for the current block is generated. This is the mechanism that links the blocks in a blockchain because any change in the block data of one block will change the next block’s hash value and thus every block after the altered block will have to update their hash values. Thus, one needs to exert immense computational effort calculating new hashes for every block after the altered block to change just a single piece of data.
Creating hash values is a trivial task for modern computers and so consensus mechanisms are used to ensure that blocks cannot be altered without immense resources and that all block data correlates with previous blockchain data in an environment lacking trust (Zheng Z. et al., 2018). Consensus mechanisms were defined by Swanson (2015) as “the process in which a majority (or in some cases all) of the network validators come to agreement on the state of a ledger. It is a set of rules and procedures that allows maintaining a coherent set of facts between multiple participating nodes.” There are a large variety of consensus mechanisms using different approaches to accomplish the same outcome and the selection of a suitable one is far from straight-forward.
The use of consensus mechanisms and hashing to make blockchains more secure might be more evident, but blockchain’s shared and distributed nature elevates it to a new level. The full history of transactions on the blockchain is shared between all nodes (users and maintainers of the network), enabling an elevated level of transparency among these users (Yaga et al., 2018). The users that have access depend on the blockchain type, which include permissioned, permissionless, private, and public (Pilkington, 2016). Furthermore, nodes are allowed to join from any distributed locations with an internet connection, creating a system without a single point of failure.
With this simple understanding of blockchain fundamentals, the benefits of the technology may be better understood. Firstly, blockchains are practically immutable because of the number of resources required to tamper with existing blocks (Yaga et al., 2018). Attacks are still possible but get increasingly more difficult the more nodes present in the network and the further back the transaction block is because of the number of resources one would need to change the required amount of data (Bastiaan, 2015).
Distrusting parties, or parties with conflicting interests, typically require the services of a mutually trusted intermediary party to facilitate transactions, giving the control to this intermediary who will charge for their services and may potentially be subject to fraudulent activities. Using a consensus mechanism and its distributed nature, one of blockchain’s greatest benefits is its ability to reduce the reliance on an intermediary to facilitate transactions (Pilkington, 2016). Blockchain requires these parties to trust the mechanism rather than another party, allowing these parties to transact in meaningful ways without using an intermediary.
Blockchain also creates elevated transparency through its shared and distributed nature, allowing anyone with the necessary permissions to access the entire transaction history. Finally, the transparency and immutability of blockchain enables extremely effective auditing because transactions can be traced to their origin and no data can be manipulated without immense effort or the knowledge and approval of network users (Zheng Z. et al., 2018).
These are the main beneficial functionalities that a blockchain solution may introduce but implementing blockchain is more nuanced than just deciding that these functionalities will be beneficial for a particular use case. The remainder of this section briefly explores some fundamental blockchain components that will be crucial in developing a useful assessment approach, namely blockchain types and consensus mechanisms.
2.2 Blockchain Type
Blockchain solutions are broadly categorized on two properties: data access and consensus participation. Data access can either be public, where anyone can transact and view transaction history, or private, where access is restricted to a select number of participants who may transact and view transaction history (Bitfury Group, 2022). Consensus participation is either permissioned, where only a predefined group of nodes participate in validating and appending blocks, or permissionless, where anyone is able to participate in the consensus process (Bitfury Group, 2022). These two categories enable four blockchain types to be identified: public permissionless, private permissionless, private permissioned, private permissionless. Private permissionless blockchains have no use case currently because of contradicting properties (Allessie, 2017; Bauer et al., 2019).
2.3 Consensus mechanisms
Consensus mechanisms are used in blockchain to ensure that ledgers present on distributed nodes agree with one another, by implementing a protocol to determine how transactions will be validated (Allessie, 2017; Zheng Z. et al., 2018). The basic technique of consensus mechanisms is performing frequent and secure updates of the distributed ledger, enabling a shared state between all nodes (Lashkari and Musilek, 2021). Through the use of consensus mechanisms, if a node publishes a block that all other nodes are in agreement with, the block is added to each respective node’s blockchain copy (Singhal et al., 2018).
There are a variety of consensus mechanisms available to use in blockchain solutions, however, this study will only consider the most relevant in the current blockchain ecosystem because of the practical experience with them and subsequent deductions that have been and can be made with regards to their use. A brief definition of these common consensus mechanisms is presented below.
1) Proof-of-Work (PoW): a node on the blockchain earns the right to verify and append the latest block by being the first to solve a computationally intensive problem, where this problem is taken as “proof” that the node performed work and is then rewarded for its effort (Yaga et al., 2018).
2) Proof-of-Stake (PoS): a node earns the right to verify and append the latest block and be rewarded for it by being randomly chosen, where the chance of being chosen is proportional to the number of digital tokens that the node has staked in the network (Yaga et al., 2018).
3) Delegated-Proof-of-Stake (dPoS): a node earns the right to verify and append the latest block and be rewarded for it by being voted in by the network to be one of a few limited verifying nodes (Yaga et al., 2018). The remaining nodes of the network have voting power that is equal to their digital tokens staked and they receive rewards proportional to this stake if the node they voted for verifies a block (Yaga et al., 2018; Veinović, 2021).
4) Proof-of-Elapsed-Time (PoET): random wait-times are generated and assigned to nodes using specialized hardware and software, where a node gets the chance to verify and append the latest block and get rewarded once their wait-time has elapsed and no other node has taken the chance (Nguyen and Kim, 2018; Yaga et al., 2018).
5) Practical Byzantine Fault Tolerance (pBFT): a leader node is selected by a group of validating nodes (which can change each round) to validate and group transactions into the latest block after a time or size limit is reached (Castro and Liskov, 1999; Sukhwani et al., 2017). Three stages commence once a block has been broadcast to the validating nodes: the pre-prepare phase, prepare phase, and commit phase (Nguyen and Kim, 2018). These stages are used to ensure that each new block additions is valid and that there is consensus among nodes and that this validated block is broadcast to all non-validating nodes.
2.4 Smart Contracts
Business contracts are mechanisms which facilitate the relationship between multiple parties that require trust and a common understanding of the expected transactions that will take place between them. Contracts have three important characteristics which were originally outlined by Szabo (1997).
1) Observability—the ability for the parties involved in the contract to observe one another’s performance or prove their performance of the contract’s stipulations.
2) Verifiability—the ability for the parties involved in the contract to prove that contract stipulations have been performed or breached, or the ability to find such information through other means.
3) Privity—third parties, other than intermediaries and adjudicators, should not have a say in contract enforcement. Only parties for which knowledge and control over the performance and contents of the contract is necessary for the performance and enforcement of the contract should have this knowledge and control.
Blockchains enforce contracts through the use of smart contracts, which is simply contractual agreements formatted in computer code and stored and executed on the respective blockchain, allowing parties to verify that obligations have been fulfilled and enables faster and automated settlement (Hon et al., 2016; Mattila, 2016). These contracts are tamper-proof, automatically enforced, and self-executing, thus reducing the need for human intervention and making the process less risky and more cost-effective (Mattila, 2016). These contracts need to be deterministic, in that they should be able to be represented as a logical flow chart, such as “if A, then B, else C” (Mattila, 2016; Morabito, 2017).
2.5 Blockchain use cases
Feasibly capturing the value of blockchain has proven to be tougher than anticipated, clearly shown by the high blockchain project failure rates. An indication of verifiable blockchain use cases with proven value will help with identifying where blockchain is valuable. There have been a variety of approaches attempting to classify the taxonomy of blockchain use cases. Crosby et al. (2016) classified them into financial and non-financial uses cases, while Swan (2015), Zhao et al. (2016), and Angelis and da Silva (2019) classified the use cases according to the progressive versions of blockchain (i.e. 1.0, 2.0, and 3.0). Finally, Zheng Z. et al. (2018) and Casino et al. (2019) classified the use cases according to major blockchain application areas, such as financial, education, IoT, governance, data management, etc.
Scouring the literature presented a logical approach for classifying blockchain use cases according to the potential value it provides in a use case. Mougayar (2016) identified six areas where blockchain provides value and they can be represented by the mnemonic ATOMIC (Assets, Trust, Ownership, Money, Identity, and Contracts). Each element is programmable and enables blockchain to add value in a business context.
Carson et al. (2018) similarly identifies six categories of blockchain use cases which are split into “Record Keeping” and “Transactions”. These categories correlate well with the ATOMIC concept presented by Mougayar (2016) and is both logical and encompasses all use cases in a concise and relevant fashion. The split of these use case categories and their respective definitions are outlined below.
2.5.1 RECORD KEEPING (storage of static information)
• Static Registry—distributed database for storing reference data.
• Identity—distributed database with identity-related information (specific case of a static registry).
• Smart Contracts—set of conditions recorded on a blockchain triggering automated, self-executing actions when these predefined conditions are met.
2.5.2 TRANSACTIONS (registry of tradeable information)
• Dynamic Registry—dynamic distributed database that updates as assets are exchanged on the blockchain network.
• Payments Infrastructure—dynamic distributed database that updates as payments are made among network participants.
• Other—a standalone use case that does not fit any categories and is often composed of several of the previous categories.
2.6 Design features comparison
These two components of blockchain, type and consensus mechanism, are the two main components involved with designing a blockchain solution that will affect blockchain performance. Thus, the different options of blockchain types and consensus mechanisms are compared against one another using a set of criteria that will enable an effective comparison of these different components’ choices. This comparison is presented in Table 1, where the definitions of the comparison criteria can be found in Table 7.
3 Method and validation
The following section is focused on presenting the method that can be used to assess blockchain solutions within an organization. This is followed by briefly exploring the method used to validate the assessment approach.
3.1 Blockchain assessment framework
The blockchain assessment framework is used to help and organization quantitatively assess the feasibility of a blockchain solution within a particular process during the early stages of blockchain exploration and enables the user to envision what a solution might look like and what to consider when contemplating a blockchain solution. The blockchain assessment framework can be seen in Figure 1. The framework is broken into five different elements and when completing an element refer to the relevant section below on the specifics of completing the element.
The blockchain assessment framework is split into two main phases: “Capability Assessment” and “Solution Scope”. The “Capability Assessment” phase consists of the “Blockchain Critical Assessment” and the “Blockchain Fit Analysis” and focuses on what a blockchain solution is capable of providing a particular organization and whether it is suitable for an organization based on the needs and characteristics of the organization and relevant process. The “Solution Scope” phase consists of the “High-Level Blockchain Design”, “Blockchain Adoption Approach”, and “Blockchain Value Analysis” and focuses on what a blockchain solution might look like for an organization and the most optimal way to go about extracting value from this solution and the things to consider for the organization and relevant process.
The specific workings of each element are presented in their relevant sections below. The overall framework merely indicates the relation between each element and certain decisions to be made before and after certain elements. Most notably is the decision gate at the end of the “Blockchain Value Analysis” whereby the user decides if any performance or cost adjustments are necessary and then whether more detail is required or more information is present and thus another iteration could be beneficial. If the user decides to end the assessment, the true usefulness of the framework comes to light where the user will consider the outputs of every element in conjunction with one another to draw insight and use this insight to make a decision on further blockchain exploration. The remainder of this section provides the step-by-step procedure for completing each element.
3.2 Blockchain critical assessment
This element is focused on allowing the user to swiftly determine whether blockchain is applicable in their specific scenario using critical factors and evaluation questions to gauge these critical factors. This assessment provides a concise method for determining the applicability of blockchain based on the features it enables and the features that a use case may require. All questions are simple yes/no questions and while an affirmative answer is not required for every factor, the case for blockchain implementation becomes weaker the more negative answers there are because the solution becomes too nuanced. The critical factors, evaluation questions, and the flow of the assessment are presented in Table 2 and Figure 2 below.
As can be seen from Figure 2, the first three critical factors are required for the implementation of a blockchain solution, while at least six of the remaining nine factors are required. As mentioned previously, the blockchain solution becomes more nuanced the more negative answers that are present, moving the solution space further away from the ideal in which a blockchain solution would operate. Consequently, any more than three negative answers indicate the solution space becomes too nuanced and the solution will not be used to its full potential.
3.3 Blockchain fit analysis
This element of the framework quantitatively assesses how well suited blockchain is for a particular organization and process. This analysis is broken into two sections to assess the fit that is represented by two scores: “Organizational Fit Score” and “Process Fit Score”. The flow of this element of the framework is presented in Figure 3. Once each respective score is calculated, they can be plotted onto a graph, as shown in the figure, where the threshold values are indicated. If the user falls into a borderline case, it is up to their discretion whether they want to continue with the remaining elements of the assessment or not based on the scores they obtained. The calculation of each score is now presented for the remainder of this section.
3.3.1 Process fit score
There are certain factors that can be used to gauge how well suited blockchain is for a particular process. These factors, along with relevant evaluation questions, are presented in Table 3 below.
When gauging a characteristic, the evaluation questions are answered on a scale of 0–10 or they are simply yes/no/maybe answers or specialized answers as identified in Table 3. Different ranges in the 0–10 scale represent different levels of agreement with the question specified as outlined in Table 4. Furthermore, Table 3 identifies threshold values in bold that refers to the value within the range that indicates the threshold between blockchain being suitable and not being suitable.
The importance weighting indicates the factor’s importance to a suitable blockchain fit within a particular process and falls on a 0–1 scale, where different ranges indicate different levels of importance, as indicated below. The weightings are assigned based on the effect that not satisfying the factor would induce, where a greater effect leads to a higher importance.
• Not Important: 0–0.25
• Mildly Important: 0.26–0.50
• Important: 0.51–0.75
• Very Important: 0.76–1.0
With the information presented, the “Process Fit Score” can now be calculated. The fuzzy weighted average method is used to account for the importance weightings and answer values of each process factor, which was originally proposed by Dong and Wong (1987) shown in Eq 1 below.
Where wi = importance weighting, xi = factor answer value, and n = number of factors. This formula is used to calculate the “Process Fit Score” based on the respective answer and importance weighting of each factor, where non-numeric answers are scored as shown in Table 5.
Everything is available for the user to calculate their “Process Fit Score”. Using the same process outlined above with the threshold values and importance weightings identified in Table 3. The threshold value for the Process Fit Score is 5.63. A score above this threshold indicates that blockchain is a good fit for the process, while a lower score indicates that blockchain is not a good fit for the process.
3.3.2 Organizational fit score
As with a process, there are certain factors that can be used to gauge how well suited blockchain is for a particular organization. These factors, with relevant evaluation questions and statements, are presented in Table 6 below.
All questions are simple yes/no/maybe answers, while all statements are answered on a scale of 0–10, where different ranges indicate various levels of agreement with the factor’s statement, where these ranges are presented in Table 4 above. Again, there are the threshold values which indicate the threshold between a blockchain solution being suitable and not being suitable. The importance weightings are assigned using the same method as for the process factors and have the same range as indicated in Section 3.1.2.1. The fuzzy weighted average method is used once again, as presented in Eq 2 below.
Where wi = importance weighting, xi = factor answer value, and n = number of factors. The non-numeric answers are scored as shown in Table 5. All tools are now available to calculate the “Organizational Fit Score” for the user’s organization. Using the above outlined process and the threshold values and importance weightings presented in Table 6, the threshold score can be calculated. The threshold value for the Organizational Fit Score is 5.34. A score above this value indicates that blockchain is a good fit for the organization, while a score below this value indicates that blockchain is not a good fit for the organization.
3.4 High-level blockchain design
As mentioned in Section 2.6, the two main design components which will affect a blockchain solution’s performance are the blockchain type and consensus mechanism chosen. Thus, this element is focused on presenting a method that can be used to identify the best design features for a given scenario. Using the comparison of the design features presented in Table 1, a description and answer range is given for each comparison criterion in Table 7.
Each comparison criterion has an answer range to gauge the preferences of the user and is linked with a score from 1–5, which is in turn linked to the key of Table 1. The user will simply select their preference for each criterion and identify the relevant score of each criterion. Furthermore, an importance weighting between 0–1 should be assigned to each criterion using the range presented in Section 3.3.1. These inputs can then be used to identify the most suitable blockchain solution for the user’s particular use case using the process identified in Figure 4 below.
3.5 Blockchain adoption approach
This element of the framework is focused on presenting the user with a framework that can be used to identify adoption considerations to be taken throughout the solution’s lifecycle for their specific use case. The outcome of this element will enable the user to gain deeper insight into the adoption process and what can be expected during a blockchain solution’s lifecycle. The framework is an adaptation of the GRAAL (Guidelines Regarding Architecture Alignment) presented by Zarvić and Wieringa (2014). The framework can be used in its blank state to identify potential considerations, where each cell of the framework represents the context of a certain set of considerations that take place within a certain enterprise architecture layer at a certain stage in a blockchain solution’s lifecycle. A brief explanation of each enterprise architecture layer used in the framework is given below.
3.5.1 Enterprise architecture layers
• Enterprise Environment—this layer represents the context of the environment that the organization operates in, with reference to external influences.
• Business Layer—this layer focuses on the organization from a business strategy viewpoint (Bucher et al., 2006), where the organization is typically arranged into different responsibilities that are centered around critical value-creating activities and ensuring that these activities work well together (Janssen, 2009).
• Process Layer—this layer focuses on how processes within the enterprise are organized, indicating boundaries, relationships, inputs, and outputs (Bucher et al., 2006; Janssen, 2009).
• Application Layer—this layer is focused on the coding that is required for the desired functionalities, which are commonly in the form of applications that are used as the interface between the end user and system (Singhal et al., 2018; Rehmani, 2021).
• Blockchain Layer—this layer is focused on a combination of blockchain layer, namely the execution layer, consensus layer, network layer, and data layer. The execution layer is responsible for executing instructions that are received from the application layer (Singhal et al., 2018). The consensus layer focuses on ensuring that there is a consistent and valid state of the ledger typically using a consensus mechanism (Singhal et al., 2018; Zhai et al., 2019). The network layer is responsible for managing and operating the communication mechanism used in the network for discovering, communicating, syncing, and broadcasting (Singhal et al., 2018; Rehmani, 2021). Finally, the data layer is responsible for defining the data structure in blocks, the data storage mechanism, and linking blocks to one another (Yu et al., 2018; Zhai et al., 2019).
• Hardware Layer—this layer is focused on the underlying hardware required for successful operation of the system and represents the organization of this hardware used by the system (Rehmani, 2021).
• Foundation Layer—this layer represents the foundations of the enterprise and thus it extends beyond the boundaries of individual layers and is crucial throughout all layers.
There are many ways to conceptualize the lifecycle of an IT system, where different terms may be used but the general idea can be easily identified and extracted. Miraz and Ali (2020) argue that a software development life cycle is not suited to the nature of blockchain. A Product-Service-System (PSS) lifecycle is considered due to blockchain being an Information System consisting of hardware and software to provide a service. Cavalcante and Gzara (2018) propose a holistic PSS lifecycle model that correlates well with the models proposed by Wang et al. (2016), Beck and Müller-Bloch (2017), and Kharitonov (2017) for blockchain solutions. The proposed four-stage blockchain lifecycle is defined below based off of these models.
3.5.2 Blockchain lifecycle stages
• Discovery—this first stage is responsible for studying the feasibility of blockchain and the opportunity it presents through creating, recognizing, elaborating, and articulating this opportunity. Furthermore, this also includes stimulating interest and building an internal community along with scrutinizing the potential solution and strategizing a possible way forward.
• Implementation—this stage evolves the opportunity from the discovery stage into a business proposition, requirements, design, development, experimentation, training, and lastly integrating the solution into the relevant process.
• Operation—this stage is, as the name suggests, focused on the regular operation, optimization, and maintenance of the employed solution.
• Disposal—this stage is triggered when the benefits of the solution fall lower than the costs of it, thus making the solution obsolete. At this point, the solution is converted into experience and knowledge and phasing out the solution will begin, often in favor of a newer solution.
These definitions enable a deeper understanding of the individual cells of the adoption considerations framework. As mentioned previously, the framework can be used in its blank state, but the framework presented in Figure 5 is presented with reference considerations already filled in. These reference considerations are included because a blank canvas can be an intimidating prospect and these reference considerations simply help the user conceptualize what these cells might entail.
The use of this reference adoption considerations framework should be completed in two simple steps.
1) Select relevant considerations from the reference framework. The framework considerations may exceed what an organization needs to consider.
2) Add other relevant, unaccounted for considerations. The reference framework does not consist of an exhaustive list of considerations and may lack some that may be relevant for an organization.
This considerations framework, with the relevant considerations identified, can be used to identify the different factors which will be important throughout the blockchain solutions lifecycle and in different layers of the relevant enterprise. This element of the blockchain assessment framework is more aimed at presenting a thought experiment for the user to enable thought on the many different aspects of blockchain by structuring the user’s thoughts in a logical way, guided by the considerations framework.
The definitions for each of the considerations presented in the reference considerations framework are presented in Table 8 as extracted from the work of Wang et al. (2016), Allessie (2017), Kharitonov (2017), Morabito (2017), Yaga et al. (2018), Joannou et al. (2020), and Toufaily et al. (2021). These sources were obtained by using the keywords blockchain, adoption, implementation, considerations, and challenges on Google Scholar. The results were evaluated, and relevant sources were identified based on whether the article addressed blockchain adoption or implementation and the challenges or considerations associated with this. Considerations were extracted from these sources by ensuring they were present in more than a single source or they correlated logically with previous blockchain literature.
3.6 Blockchain value analysis
Due to the scarcity of performance and cost data, the blockchain value analysis element is used to enable deep contemplation on the different aspects involved with the costs and benefits of the blockchain solution rather than presenting a quantitative value analysis. The framework presented for this element is used to identify potential costs, relevant performance metrics, and process cost reductions. The framework is used to highlight the areas where costs, performance and cost reductions will most likely be present. The value analysis framework is presented in Figure 6.
The framework proceeds in a simple linear fashion so the user is able to logically conceptualize how certain choices will affect specific outcomes. The framework begins by identifying preferences for a set of development cost influencers, which are simply a set of factors or features which will influence the time spent on development and the costs incurred, with their options outlined below as identified through the previous work of the literature review and the work of Leewayhertz (2019) and Gopalakrishnan et al. (2021). These sources were obtained by using the keywords blockchain, adoption, implementation, cost, and development on Google Scholar. The results were evaluated, and relevant sources were identified based on whether the source identified factors or features that would influence the cost of a blockchain solution. Due to the limited results, the search was conducted again on Google to find blockchain development platforms or businesses that indicate the different features and factors that would influence the cost. The cost influencers were extracted from these sources by ensuring that they correlated logically with previous blockchain literature.
• Blockchain Type—public permissionless, public permissioned, private permissioned, private permissionless
• Financial Transactions—requires financial transactions, does not require financial transactions
• Network-User Interaction—web interface, mobile interface, admin interface, desktop interface
• Proof of Concept—PoC required, PoC not required
• Deployment—third-party cloud computation, no cloud computation (on-premises), hybrid
• Developers—in-house, freelancers, agency/outsourcing
• Operation Complexity—blockchain network is its own information system, blockchain network interacts with other information systems outside itself
• Development Approach—from scratch, integrated with existing system, blockchain development platform (Hyperledger, Ethereum, R3, etc.)
• Development Speed—normal, fast, immediate
• Number of User Types—any size required, where increased users affect performance (user types: customers, suppliers, administrators, customer support, etc.)
Based on the preferences identified, the insight gained from the adoption considerations, and the blockchain design, the costs can be identified according to the categories identified in the framework. This is aided by presenting typical cost items that are present in each category, which are presented below as identified by Takyar (2019), Davies (2021), and Gopalakrishnan et al. (2021). These sources were obtained by using the keywords blockchain, adoption, implementation, cost, and development on Google Scholar. The results were evaluated, and relevant sources were identified based on whether the source identified the costs of a blockchain solution. Due to the limited results, the search was conducted again on Google to find blockchain development platforms or businesses that indicate the different costs of a blockchain solution. The costs were extracted from these sources by ensuring that they correlated logically with previous blockchain literature and were present in more than a single source.
• Consulting Costs—consultant fees
• Design Costs—white paper cost, prototype development
• Development Costs—solution development, smart contracts development, user interface development, cryptocurrency/token integration
• Quality Assurance Costs—security (sales, cyber), legal costs, know your customer costs, anti-money laundering, agency costs, individual costs
• Deployment, Operation and Maintenance Costs—node hosting costs, system migration, maintenance and upgrading, continuous integration, storage and energy costs, infrastructure
Again, using the development preferences, insight gained from the adoption considerations, and the blockchain design, relevant performance metrics can be identified which can be used to compare blockchain solutions with one another, as well as with traditional solutions.
The definitions for these metrics are presented below as defined by Hyperledger Performance and Scale Working Group (2018), Maharjan (2018), Kombe et al. (2018), Sukhwani et al. (2018), Zheng P. et al. (2018), Kuzlu et al. (2019), Bergman et al. (2020), Dabbagh et al. (2020), Smetanin et al. (2020), Monrat et al. (2020), Ruan et al. (2021), Dabbagh et al. (2021), and Khan et al. (2022). These sources were obtained by using the keywords blockchain, performance, evaluation, analysis, and metrics on Google Scholar. The results were evaluated, and relevant sources were identified based on whether the article addressed analyzing a blockchain solution’s performance. Blockchain performance metrics were extracted from these sources by ensuring they were present in more than a single source and could feasibly be used to compare blockchain to more traditional solutions.
• Throughput—successful transactions or read operations per second.
• Latency—response time for transactions or read operations from initialization to execution and commitment.
• Scalability—the number of participants the network can accommodate.
• Success Rate—the ratio of successful operations performed to the total number of operations.
• Transactions Per CPU/GPU—the degree to which a CPU/GPU is consumed for blockchain operations.
• Transactions Per Memory Second—the degree to which memory is consumed per second of transactions for temporary operations that require memory for computation efforts.
• Transactions Per Disk I/O—the degree to which I/O is consumed by blockchain operations for reading from the hard disk (permanent storage) and writing to it.
• Transactions Per Network Data—the degree to which the network flow (upload and download capabilities) is used for blockchain operations such as transferring data blocks.
Using the costs and performance metrics identified, the user can identify potential process cost reductions from the set presented in the value analysis framework. The framework does not present an exhaustive list but provides some of the most common cost reductions that can be expected from a blockchain solution.
Definitions for each of the process cost reductions are listed below as identified by Hedman and Kalling (2003), Wang et al. (2016), Hassani et al. (2018), Niranjanamurthy et al. (2019), Panuparb (2019), and Chen et al. (2022). These sources were obtained by using the keywords blockchain, cost, benefit, value, business, and SWOT on Google Scholar. The results were evaluated, and relevant sources were identified based on whether the article addressed the cost reductions or value a blockchain solution provides. The cost reductions were extracted from these sources by ensuring they were present in more than a single source or they correlated logically with previous blockchain literature.
• Verification Costs—Blockchain enables data to be distributed between multiple parties securely and thus reduces unnecessary duplication of data and constant requests for data, consequently saving time and money.
• Improved Settlement Speeds—With one shared version of the truth, parties can transact with greater trust and thus reduce the need for intermediaries to process transactions to ensure integrity, thus reducing time and saving money.
• Enhanced Security & Data Integrity—Data cannot be changed, and all new information is shared with the relevant parties, making it secure because alterations can be tracked and monitored, thus requiring less effort in ensuring data integrity.
• Debugging Costs—Due to synchronization mishaps, data between organizations may be misaligned and addressing these misalignments can be time-consuming and costly, whereas blockchain removes the possibility of such misalignment.
• Policing & Enforcement Costs—Blockchain’s transparency and immutability allow regulators to more easily and swiftly scrutinize any transactions to ensure compliance and that all parties stick to the terms of an agreement.
• Transactions Costs—Reducing the need for constant administrative searching and communication activities, eliminating intermediaries, and increasing process transaction efficiency will reduce overhead costs because blockchain allows distributed access to a single, immutable source of truth.
• Bargaining Costs—Smart contracts can be used to automatically execute certain code based on set conditions in a transparent and efficient manner, thus reducing the need for complex and time-consuming human interaction to reach agreement between parties on an appropriate contract.
• Search & Information Costs—Blockchain provides a “single line of sight”, enabling more agile responses to events and more inter-organizational collaboration, while reducing the need for costly administrative searching and communication activities.
As mentioned previously, this element of the framework is used to provoke deep contemplation and does not provide tangible outcomes. Inputs are less important, the framework more acts as a guideline to structure thoughts logically. The framework helps to guide the thoughts of the user to identify the potential costs and benefits of a blockchain solutions by highlighting the links between specific choices and the outcomes they might affect.
3.7 Validation
The blockchain assessment framework was demonstrated with the use of a case study and validated with expert analysis. These methods are briefly explained below.
1) Case Study—an enterprise asset management company (simply referred to as “the company” throughout) wished to investigate a particular process for blockchain implementation, thus providing the necessary inputs required to use the blockchain assessment framework.
2) Expert Analysis—two experts that were involved with the case study were taken through the steps of the blockchain assessment framework and presented with the outcomes of the assessment, whereby a semi-structured interview took place to gain the experts’ perspective on the usefulness and rational of the framework.
3.7.1 Case study
The process selected by the company was a complex flow of work orders and invoices between the company and a client. All inputs were received from the company’s divisional manager and head of product development and were used to complete the blockchain assessment framework. The framework indicated blockchain to be a plausible solution for the process, but that the technology is still in its infancy and the company is in a good position to follow the role of other companies within this space, rather than being the disruptors themselves.
3.7.2 Expert analysis
A presentation was used to present the framework and its results to the company representatives and was aimed at ensuring they were happy with the insight produced by the framework and to receive feedback on the framework itself. A semi-structured interview approach was used to promote feedback while ensuring that the company representatives were never pressured into giving feedback on topics they had not pondered, while allowing the conversation to be guided to receive the necessary feedback. The main points of feedback are summarized below, followed by the insights that were gained and the actions that can be taken presented in Table 9 as presented by Spencer-Hicken (2022).
• The framework conglomerates a collection of blockchain knowledge which helps to advance the understanding and application of the technology in organizations.
• The framework covers the primary aspects of assessment to provide important outcomes and guidelines.
• The framework helps to generate momentum with blockchain exploration and the future steps to be taken within an organization.
• The elements of the framework are clear, complete, and purposeful, while flowing logically between one another and being easy to understand and use.
• The framework helps with efficient decision-making regarding potential further blockchain analysis.
• Certain improvements can be made to the framework to make it more helpful with blockchain implementation, rather than just indicating if further blockchain analysis will be beneficial or not.
As can be seen from Table 9, the actions that are taken on the insight are either translated into future research recommendations or by altering the final framework. The blockchain assessment framework addresses a need and, while there are improvements that can be made, the framework helps with assessing blockchain and starting a blockchain exploration process.
4 Limitations and recommendations
As mentioned previously, the blockchain assessment framework is helpful when initiating the blockchain exploration journey but is less helpful further on when deeper analysis is required. The study is limited by the blockchain research that is available because being a new technology there has not been a lot of time to build up a strong research base. Furthermore, there is a lack of blockchain standards within industries, such as standards for measuring blockchain performance and thus different studies use different metrics for blockchain performance indication. This lack of standards limits how research can be compared with one another.
The framework has only been tested in a single industry with a single company and thus there is more insight to be gained from other industries, limiting the outcome of this study until its value is proven further in other industries. A further limitation are the potential design features excluded in the high-level design because of the lack of data linking these features to the comparison criteria. Lastly, subjective inputs are used and thus the blockchain assessment framework is limited by the perspective and biases of potential users.
Clearly the framework has aspects that have the potential to be improved. As such, there are areas of future research that can be used to enhance the blockchain assessment framework. The recommendations for future research are listed below as presented by Spencer-Hicken (2022).
• Blockchain Development and Implementation Costs—gather empirical data on the cost of developing and implementing blockchain solutions to enable the creation of cost models that can be used to more accurately predict blockchain costs.
• Different Blockchain Configuration Performances—gather empirical data on the performance of different blockchain solution configurations based on a wide variety of performance metrics to enable more accurate predictions of blockchain solution performance.
• Blockchain Cost Reductions—create mathematical models that can be used to estimate the cost savings introduced by a blockchain solution based on the time it saves during different operations.
• Blockchain Design Choices—investigate how different design features and their relevant options will affect the performance of different comparison criteria of a blockchain solution.
• Design Comparison Criteria Trade-offs—investigate how the different comparison criteria identified affect each other and the relationship between them.
• Introduce Objectivity into the Framework—investigate how more objective inputs can be used within the blockchain assessment framework to reduce the biases of potential users and increase the accuracy of results. Further investigate how different multi-criteria decision-making methods affect the results produced by the assessment framework and which produces the most accurate results.
5 Discussion
The validity of this study was ensured by using multiple different sources of data, with the main being existing blockchain literature but also using a demonstrative case study and expert analysis to guide the development of the framework. A gap of knowledge was identified, and subjectivity and bias were minimized, by ensuring that this gap was translated into literature topics systematically so that replication of the logic of the research is possible. Presenting the outcome of this study as a framework with tangible outcomes, opposed to a discussion format or decision-making model, is to provide potential framework users with practical value and quantitative indicators.
The framework itself is high-level and helps with blockchain decision-making during the early stages of blockchain exploration. It is a great tool for initiating the blockchain exploration journey and helping decide whether further blockchain analysis is worthwhile. Furthermore, this study has gathered relevant knowledge regarding blockchain assessment and provides a strong foundation from which future blockchain assessment research can be built upon.
Data availability statement
The original contributions presented in the study are included in the article/Supplementary Material, further inquiries can be directed to the corresponding author.
Author contributions
SS-H was the main author of the study, doing the necessary research and writing up the article. CS and PV were the supervisors of the study, aiding with the conception of the work and editing the rough drafts to ensure it was professional and conveyed what was necessary.
Funding
The author of this study, SS-H, received a research grant from his supervisors for the duration of his studies. Furthermore, Stellenbosch University Industrial Engineering Department is the institution paying for this article’s processing fees.
Conflict of interest
The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.
Publisher’s note
All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.
References
Allessie, D. (2017). Blockchain technology for governmental processes: The design of a blockchain assessment tool: A design science approach. Netherlands, Delft: Delft University of Technology. [master’s thesis].
Angelis, J., and da Silva, E. R. (2019). Blockchain adoption: A value driver perspective. Bus. Horizons 62 (3), 307–314. doi:10.1016/j.bushor.2018.12.001
Bastiaan, M. (2015). “Preventing the 51%-attack: A stochastic analysis of two phase proof of work in bitcoin,” in 22nd Twente Student Conference on IT (Netherlands: Enschede).
Bauer, I., Zavolokina, L., Leisibach, F., and Schwabe, G. (2019). “Exploring blockchain value creation: The case of the car ecosystem,” in 52nd Hawaii International Conference on System Sciences (Hawaii: United States of America).
Beck, R., and Müller-Bloch, C. (2017). “Blockchain as radical innovation: A framework for engaging with distributed ledgers,” in 50th Hawaii International Conference on System Sciences (Hawaii: United States of America).
Bellini, E., Ceravolo, P., and Damiani, E. (2019). “Blockchain-based E-vote-as-a-service,” in 2019 IEEE 12th International Conference on Cloud Computing. (Milan, Italy: IEEE), 484–486.
Bergman, S., Asplund, M., and Nadjm-Tehrani, S. (2020). Permissioned blockchains and distributed databases: A performance study. Concurrency Comput. Pract. Exp. 32 (12), e5227. doi:10.1002/cpe.5227
Bitfury Group (2015). Public versus Private Blockchains: Part 1: Permissioned Blockchains: White Paper. Available at: https://bitfury.com/content/downloads/public-vs-private-pt1-1.pdf (Accessed October 02, 2022).
Brilliantova, V., and Thurner, T. W. (2019). Blockchain and the future of energy. Technol. Soc. 57, 38–45. doi:10.1016/j.techsoc.2018.11.001
Bucher, T., Fischer, R., Kurpjuweit, S., and Winter, R. (2006). “Analysis and application scenarios of enterprise architecture: An exploratory study,” in 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (Hong Kong, China: IEEE).
Bürer, M. J., de Lapparent, M., Pallotta, V., Capezzali, M., and Carpita, M. (2019). Use cases for Blockchain in the Energy Industry Opportunities of emerging business models and related risks. Comput. Industrial Eng. 137, 106002. doi:10.1016/j.cie.2019.106002
Carson, B., Romanelli, G., Walsh, P., and Zhumaev, A. (2018). Blockchain beyond the hype: What is the strategic business value. New York, NY McKinsey and Company, 1–13.
Casino, F., Dasaklis, T. K., and Patsakis, C. (2019). A systematic literature review of blockchain-based applications: Current status, classification and open issues. Telematics Inf. 36, 55–81. doi:10.1016/j.tele.2018.11.006
Castro, M., and Liskov, B. (1999). “Practical Byzantine Fault Tolerance,” in Third Symposium on Operating Systems Design and Implementation (Louisiana, United States of America: USENIX Association).
Cavalcante, J., and Gzara, L. (2018). Product-service systems lifecycle models: Literature review and new proposition. Procedia CIRP 73, 32–38. doi:10.1016/j.procir.2018.03.324
Chen, W., Botchie, D., Braganza, A., and Han, H. (2022). A transaction cost perspective on blockchain governance in global value chains. Strateg. Change 31 (1), 75–87. doi:10.1002/jsc.2487
Crosby, M., Pattanayak, P., Verma, S., and Kalyanaraman, V.Nachiappan (2016). Blockchain technology: Beyond bitcoin. Appl. Innov. 2 (6-10), 71.
Dabbagh, M., Choo, K.-K. R., Beheshti, A., Tahir, M., and Safa, N. S. (2021). A survey of empirical performance evaluation of permissioned blockchain platforms: Challenges and opportunities. Comput. Secur. 100, 102078. doi:10.1016/j.cose.2020.102078
Dabbagh, M., Kakavand, M., Tahir, M., and Amphawan, A. (2020). “Performance analysis of blockchain platforms: Empirical evaluation of hyperledger fabric and Ethereum,” in IEEE 2nd International Conference on Artificial Intelligence in Engineering and Technology. (Kota Kinabalu, Malaysia: IEEE).
Das, M., Tao, X., Liu, Y., and Cheng, J. C. (2022). A blockchain-based integrated document management framework for construction applications. Automation Constr. 133, 104001. doi:10.1016/j.autcon.2021.104001
Davies, A. (2021). How much blockchain cost for software development? Available at: https://www.devteam.space/blog/how-much-blockchain-cost-for-software-development/.
Dong, W. M., and Wong, F. S. (1987). Fuzzy weighted averages and implementation of the extension principle. Fuzzy sets Syst. 21 (2), 183–199. doi:10.1016/0165-0114(87)90163-1
Fernández-Caramès, T. M., and Fraga-Lamas, P. (2020). Towards post-quantum blockchain: A review on blockchain cryptography resistant to quantum computing attacks. IEEE access 8, 21091–21116. doi:10.1109/access.2020.2968985
Garcia-Torres, S., Albareda, L., Rey-Garcia, M., and Seuring, S. (2019). Traceability for sustainability–literature review and conceptual framework. Supply Chain Manag. 24 (1), 85–106. doi:10.1108/scm-04-2018-0152
Gopalakrishnan, P. K., Hall, J., and Behdad, S. (2021). Cost analysis and optimization of Blockchain-based solid waste management traceability system. Waste Manag. 120, 594–607. doi:10.1016/j.wasman.2020.10.027
Hassani, H., Huang, X., and Silva, E. (2018). Banking with blockchain-ed big data. J. Manag. Anal. 5 (4), 256–275. doi:10.1080/23270012.2018.1528900
Hedman, J., and Kalling, T. (2003). The business model concept: Theoretical underpinnings and empirical illustrations. Eur. J. Inf. Syst. 12 (1), 49–59. doi:10.1057/palgrave.ejis.3000446
Hon, W. K., Palfreyman, J., and Tegart, M. (2016). Distributed ledger technology and Cybersecurity. Athens, Greece: European Union Agency For Network And Information Security.
Hyperledger Performance and Scale Working Group (2018). Hyperledger blockchain performance metrics. Whitepaper. Available at: https://www.hyperledger.org/wpcontent/uploads/2018/10/HL.
Janssen, M. F. W. H. A. (2009). “Framing enterprise architecture: A metaframework for analyzing architectural efforts in organizations,” in Coherency management: Architecting the enterprise for alignment, agility and assurance. Bloomington, IN: AuthorHouse, 107–126.
Joannou, D., Kalawsky, R., Mart´ınez-Garc´ıa, M., Fowler, C., and Fowler, K. (2020). Realizing the role of permissioned blockchains in a systems engineering lifecycle. Systems 8 (4), 41. doi:10.3390/systems8040041
Khan, D., Jung, L. T., Hashmani, M. A., and Cheong, M. K. (2022). Empirical performance analysis of hyperledger LTS for small and medium enterprises. Sensors 22 (3), 915. doi:10.3390/s22030915
Kharitonov, A. (2017). A framework for strategic intra-and inter-organizational adoption of the blockchain technology. Available at SSRN: https://ssrn.com/abstract=3005343.
Kombe, C., Dida, M., and Sam, A. (2018). A review on healthcare information systems and consensus protocols in blockchain technology. Int. J. Adv. Technol. Eng. Explor. 5 (49), 473–483. doi:10.19101/ijatee.2018.547023
Krichen, M., Ammi, M., Mihoub, A., and Almutiq, M. (2022). Blockchain for modern applications: A survey. Sensors 22 (14), 5274. doi:10.3390/s22145274
Kuzlu, M., Pipattanasomporn, M., Gurses, L., and Rahman, S. (2019). “Performance analysis of a hyperledger fabric blockchain framework: Throughput, latency and scalability,” in 2019 IEEE International Conference on Blockchain. (Atlanta, GA: IEEE).
Lashkari, B., and Musilek, P. (2021). A comprehensive review of blockchain consensus mechanisms. IEEE Access 9, 43620–43652. doi:10.1109/access.2021.3065880
Leewayhertz (2019). Blockchain app development calculator. Available at: https://leewayhertz.outgrow.us/Blockchain-Cost-Calculator.
Maharjan, P. S. (2018). Performance analysis of blockchain platforms. Las Vegas: University of Nevada. Ph.D. thesis.
Mattila, J. (2016). The blockchain phenomenon, Berkeley, CA: Berkeley Roundtable of the International Economy. 16.
Miraz, M. H., and Ali, M. (2020). Blockchain enabled smart contract based applications: Deficiencies with the software development life cycle models. Baltica J. 33 (1), 101–116. doi:10.48550/arXiv.2001.10589
Monrat, A. A., Schel´en, O., and Andersson, K. (2020). “Performance evaluation of permissioned blockchain platforms,” in 2020 IEEE Asia-Pacific Conference on Computer Science and Data Engineering. (Gold Coast, QLD: IEEE).
Morabito, V. (2017). Business innovation through blockchain. Switzerland: Springer International Publishing.
Mougayar, W. (2016). The business blockchain: Promise, practice, and application of the next internet technology. United States of America: John Wiley and Sons.
Nguyen, G. T., and Kim, K. (2018). A survey about consensus algorithms used in blockchain. J. Inf. Process. Syst. 14 (1), 101–128. doi:10.3745/JIPS.01.0024
Niranjanamurthy, M., Nithya, B. N., and Jagannatha, S. J. C. C. (2019). Analysis of blockchain technology: Pros, cons and SWOT. Clust. Comput. 22 (6), 14743–14757. doi:10.1007/s10586-018-2387-5
Nofer, M., Gomber, P., Hinz, O., and Schiereck, D. (2017). Blockchain. Bus. &Information Syst. Eng. 59 (3), 183–187. doi:10.1007/s12599-017-0467-3
Oliveira, T., and Martins, M. F. (2011). Literature review of information technology adoption models at firm level. Electron. J. Inf. Syst. Eval. 14 (1), 110–121.
Panuparb, P. (2019). Cost-benefit analysis of a blockchain-based supply chain finance solution. Cambridge, MA: Massachusetts Institute of Technology. Ph.D. thesis.
Pilkington, M. (2016). “Blockchain technology: Principles and applications,” in Research handbook on digital transformations (United Kingdom: Edward Elgar Publishing).
Reddy, K. R. K., Gunasekaran, A., Kalpana, P., Sreedharan, V. R., and Kumar, S. A. (2021). Developing a blockchain framework for the automotive supply chain: A systematic review. Comput. Industrial Eng. 157, 107334. doi:10.1016/j.cie.2021.107334
Rehmani, M. H. (2021). “Blockchain technology and database management system,” in Blockchain systems and communication networks: From concepts to implementation (Berlin, Germany: Springer), 15–22.
Risius, M., and Spohrer, K. (2017). A blockchain research framework. Bus. Inf. Syst. Eng. 59 (6), 385–409. doi:10.1007/s12599-017-0506-0
Ruan, P., Dinh, T. T. A., Loghin, D., Zhang, M., Chen, G., Lin, Q., et al. (2021). “Blockchains vs. Distributed databases: Dichotomy and fusion,” in Proceedings of the 2021 International Conference on Management of Data, Virtual Event China. (New York, NY: Association for Computing Machinery).
Sikorski, J. J., Haughton, J., and Kraft, M. (2017). Blockchain technology in the chemical industry: Machine-to-machine electricity market. Appl. Energy 195, 234–246. doi:10.1016/j.apenergy.2017.03.039
Singhal, B., Dhameja, G., and Panda, P. S. (2018). Beginning blockchain: A beginner’s guide to building blockchain solutions. New York: Apress.
Smetanin, S., Ometov, A., Komarov, M., Masek, P., and Koucheryavy, Y. (2020). Blockchain evaluation approaches: State-of-the-Art and future perspective. Sensors 20 (12), 3358. doi:10.3390/s20123358
Spencer-Hicken, S. (2022). Blockchain feasibility assessment – a quantitative approach. Stellenbosch, South Africa: University of Stellenbosch. [master’s thesis].
Sukhwani, H., Martínez, J. M., Chang, X., Trivedi, K. S., and Rindos, A. (2017). “Performance modeling of PBFT consensus process for permissioned blockchain network (hyperledger fabric),” in IEEE 36th Symposium on Reliable Distributed Systems (SRDS) (Hong Kong, China: IEEE).
Sukhwani, H., Wang, N., Trivedi, K. S., and Rindos, A. (2018). “Performance modeling of hyperledger fabric (permissioned blockchain network),” in 2018 IEEE 17th International Symposium on Network Computing and Applications. (Cambridge, MA: IEEE).
Sultan, K., Ruhi, U., and Lakhani, R. (2018). “Conceptualizing blockchains: Characteristics and applications,” in 2018 11th IADIS International Conference Information Systems (Lisbon, Portugal: Cornell University).
Swan, M. (2015). Blockchain: Blueprint for A new economy. United States of America: O’Reilly Media, Inc.
Swanson, T. (2015). Consensus-as-a-service: A brief report on the emergence of permissioned, distributed ledger systems. New York, United States: R3CEV Tech Report. Available at: https://www.the-blockchain.com/wp-content/uploads/2016/04/Permissioned-distributed-ledgers.pdf.
Szabo, N. (1997). Formalizing and securing relationships on public networks. First Monday 2–9. doi:10.5210/fm.v2i9.548
Takyar, A. (2019). How to determine the cost of blockchain implementation? Available at: https://www.leewayhertz.com/cost-of-blockchain-implementation/.
Taskinsoy, J. (2019). Blockchain: A misunderstood digital revolution. Things you need to know about blockchain. Available at SSRN: https://ssrn.com/abstract=3466480.
Toufaily, E., Zalan, T., and Dhaou, S. B. (2021). A framework of blockchain technology adoption: An investigation of challenges and expected value. Inf. Manag. 58 (3), 103444. doi:10.1016/j.im.2021.103444
Ullah, F., and Al-Turjman, F. (2021). A conceptual framework for blockchain smart contract adoption to manage real estate deals in smart cities. Neural Comput. Appl. 33 (4), 1–22. doi:10.1007/s00521-021-05800-6
Veinović, M. (2021). “Comparative analysis of consensus algorithms in blockchain networks,” in International Scientific Conference on Information Technology and Data Related Research (Wuhan, China: Singidunum University).
Wang, H., Chen, K., and Xu, D. (2016). A maturity model for blockchain adoption. Financ. Innov. 2 (1), 12–15. doi:10.1186/s40854-016-0031-z
Yaga, D., Mell, P., Roby, N., and Scarfone, K. (2018). Blockchain technology overview. Gaithersburg, MD: National Institute of Standards and Technology. doi:10.6028/NIST.IR.8202
Yang, W., Garg, S., Huang, Z., and Kang, B. (2021). A decision model for blockchain applicability into knowledge-based conversation system. Knowledge-Based Syst. 220, 106791. doi:10.1016/j.knosys.2021.106791
Yu, Z., Liu, X., and Wang, G. (2018). “A survey of consensus and incentive mechanism in blockchain derived from P2P,” in IEEE 24th international conference on parallel and distributed systems (Singapore: IEEE).
Zarvić, N., and Wieringa, R. (2014). An integrated enterprise architecture framework for business-IT alignment. Des. Enterp. Archit. Fram. Integrating Bus. Process. IT Infrastructure 63 (9), 14–22.
Zhai, S., Yang, Y., Li, J., Qiu, C., and Zhao, J. (2019). Research on the application of cryptography on the blockchain. J. Phys. Conf. Ser. 1168 (3), 032077. doi:10.1088/1742-6596/1168/3/032077
Zhao, J. L., Fan, S., and Yan, J. (2016). Overview of business innovations and research opportunities in blockchain and introduction to the special issue. Financ. Innov. 2, 28. doi:10.1186/s40854-016-0049-2
Zheng, P., Zheng, Z., Luo, X., Chen, X., and Liu, X. (2018). “A detailed and real-time performance monitoring framework for blockchain systems,” in 2018 IEEE/ACM 40th International Conference on Software Engineering: Software Engineering in Practice Track. (Gothenburg/Göteborg, Sweden: IEEE).
Keywords: blockchain, blockchain decision-making, blockchain suitability, blockchain feasibility, quantitative blockchain assessment, blockchain adoption, blockchain assessment
Citation: Spencer-Hicken S, Schutte CSL and Vlok PJ (2023) Blockchain feasibility assessment: A quantitative approach. Front. Blockchain 6:1067039. doi: 10.3389/fbloc.2023.1067039
Received: 11 October 2022; Accepted: 16 January 2023;
Published: 26 January 2023.
Edited by:
Roman Vitenberg, University of Oslo, NorwayReviewed by:
Giovanni Meroni, Technical University of Denmark, DenmarkRameez Asif, University of East Anglia, United Kingdom
Copyright © 2023 Spencer-Hicken, Schutte and Vlok. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.
*Correspondence: Scott Spencer-Hicken, sspencerhicken@outlook.com