Open Access

A maturity model for blockchain adoption

Financial Innovation20162:12

DOI: 10.1186/s40854-016-0031-z

Received: 16 October 2016

Accepted: 4 November 2016

Published: 14 November 2016



The rapid development of the blockchain technology and its various applications has rendered it important to understand the guidelines for adopting it.


The comparative analysis method is used to analyze different dimensions of the maturity model, which is mainly based on the commonly used capability maturity model.


The blockchain maturity model and its adoption process have been discussed and presented.


This study serves as a guide to institutions to make blockchain adoption decisions more systematically.


Blockchain Technology adoption Maturity model


Blockchain is a distributed database comprising records of transactions or digital events that have been executed and shared among participating parties. Each of these transactions is verified by the consensus of a majority of the participants in the system (Crosby et al. 2016), thus enabling the creation of a distributed consensus in the digital, online world. Blockchain technology facilitates systems to develop a democratic, open, and scalable digital economy. The characteristics of blockchain technology include superior features such as smart contracts and smart property. Its potential financial applications include private securities, insurance, Internet finance, etc., while its non-financial applications include the Internet of Things, decentralized data storage, notary documents, anti-counterfeit solutions, etc.

Measuring the maturity of a blockchain system poses problems in the adoption of the technology because “If you can’t measure it, you can’t manage it” (Park et al. 2012). A generic business approach for designing and adopting a blockchain application involves an assessment of the current state of the product by an organization before it is included in a strategic plan. However, despite the emerging importance of blockchain maturity and accessibility, little has been covered in previous literature.

The maturity modeling exists broadly (Poppelbub et al. 2011) as it has been applied to IT fields for a long time. The capability maturity model (CMM), which is the most popular model, was initially used to evaluate the degree of software developing processes (Herbsleb et al. 1997). CMM, which was developed over a span of 20 years, is also widely adopted as a general maturity model in business process, commerce, industry, and IS/IT organizations; for example, people CMM (Curtis et al. 1995), IT-business alignment CMM (CCS 2014), and IT green maturity (Park et al. 2012).

This study presents the taxonomy of the maturity assessment, which is used as a basis for developing the blockchain maturity model (BCMM). In addition, this study also presents a procedure that facilitates organizations in blockchain application design and adoption.

Blockchain maturity model

Technology maturity is defined by four indicators: networks, information systems, computing methodologies, and security and privacy, according to the ACM Computing Classification System (CCS 2014), which is well accepted in the computer science society.

To determine the maturity level of the BCMM, we adapt the five stages (stage 1 to stage 5) of maturity from CMM: (1) initial, which is the chaotic and ad hoc status of a new service; (2) repeatable, wherein some experiences are borrowed from similar products; (3) defined, which is the stage at which a service is standard and documented; (4) managed stage, which comprises the standard metrics proposed for qualitative evaluation; and (5) optimizing, which means that the service is continuously optimized and improved. Detailed definitions of the five stages of maturity are illustrated in Table 1.
Table 1

Taxonomy of the maturity assessment


1. Initial

2. Repeatable

3. Defined

4. Managed

5. Optimized


• Ad hoc, chaotic

• Emerging

• Lack of understanding

• Methodology establishment

• Controlled and coordinated

• Reactive

• Standardized and documented

• Proactive

• Quality metrics establishment

• Consolidated and reliable

• Continuous improvement

• Share of knowledge and information


• Focus on function

• High cost

• Focus on reliability

• Transactional customers

• Broad no-target promotion

• Focus on assured delivery of services

• Prices settle down

• Requirements are measured

• Standard services

• Price with incentives and outcome metrics

• Customers are grouped with profiles

• Promotion is targeted

• Empathy in dealing with emerging business needs

• Create the product special influents in industry.


• Less supervision

• Competition is forbidden

• Rules have been borrowed from related domains

• Regulation rules and laws are defined

• Measurements on regulation is set up

• Competition is encouraged under supervision

• Free competition

• Market based on well-established legal system

Based on the taxonomy above as well as related literature (Zamfir 2016), the BCMM is shown in Table 2.
Table 2

Blockchain maturity model


Initial (stage 1)

Repeatable (stage 2)

Defined (stage 3)

Managed (stage 4)

Optimizing (stage 5)



Network load



Information Systems








Business efficiency


Computing Methodologies


Computational complexity


Security and Privacy



Data security

Transaction security

This BCMM contains four CSS categories as described below:
  • In the network category, the main concern in blockchain adoption is the network-loading problem as each transaction is broadcasted over the network.

  • In the information systems category, the maturity level of most features of blockchain is lower.
    • ■ Architecture: It is not clear whether the architecture is based on the public Internet or the private intranet. Integration with existing information systems is challenging because the blockchain system may not be a stand-alone system.

    • ■ Upgrading: Blockchain systems need to be upgraded due to various reasons, such as environment changes (e.g., Internet communication protocols, computer operating systems, programming languages, interfaces, and external databases), the bug fixes, and improvements. As blockchain systems exist all over the Internet, the upgrade cannot be similar to other existing enterprise software upgrades. Additionally, there are upgrading related issues, such as who determines and manages such upgrading.

    • ■ Integration: In many applications, the blockchain system is not a stand-along system and is a sub-system of an organizational information system. Therefore, there are two difficult integration tasks. First, importing previous transactions into the blockchain system is a complicated procedure. Second, the organizational system needs to integrate the blockchain system with the legacy systems.

    • ■ Storage: Each block is duplicated and stored with multiple participating parties. Such huge duplications are not efficient from a storage point of view.

    • ■ Scalability: It is challenging to extend blockchain systems and estimate the costs for such extensions.

    • ■ Maintenance: With the exception of Bitcoin, there is no other real-world blockchain system. Therefore, there is a lack of experience with regard to maintenance.

    • ■ Business efficiency: Blockchain systems are able to perform trusted transaction storage and are more efficient than the traditional approaches.

  • In the computing methodologies category, most features of blockchain have not yet achieved high-level maturity.
    • ■ Standardization: Presently, the blockchain standardization is at its nascent stage. There is a need to set up an organization to manage and develop such standards.

    • ■ Computational complexity: All the computations are executed at all of the participating parties. Such an approach is not considered efficient from the perspective of complexity.

  • In the privacy and security category, the blockchain technology is rated well.


Adoption procedure

From the BCMM described above, it is clear that the blockchain technology is not at an appropriate level of maturity for the process of adoption. Therefore, a safe adoption procedure comprising three stages is described below.
  1. 1.
    Feasibility study: Why blockchain? If four or more of the following conditions are met, then blockchain has strong potential to provide a solution (Blockchain 2016):
    1. 1)

      Multiple parties share data: multiple participants need views of common information

    2. 2)

      Multiple parties update data: multiple participants take actions that need to be recorded and change the data

    3. 3)

      Requirement for verification: participants need to trust the validity of the actions that are recorded

    4. 4)

      Intermediaries add cost and complexity: removal of ‘central authority’ record keeper intermediaries has the potential to reduce cost (e.g., fees) and complexity (e.g., multiple reconciliations)

    5. 5)

      Interactions are time-sensitive: reducing delays has business benefits (e.g., reduced settlement risk and enhanced liquidity)

    6. 6)

      Transaction interaction: transactions created by different participants depend on each other

  2. 2.
    Development: During this stage, the key focuses are as follows:
    1. 1)

      Requirement analysis

    2. 2)

      Architectural design

  3. 3.
    Operation: If the blockchain system is replacing an existing system, a progressive replacement procedure is proposed as follows:
    1. 1)

      Keep the existing system running and run the blockchain system as the backup system for a certain period.

    2. 2)

      If the blockchain system is running smoothly, let it run as the operational system and run the existing system as the backup system.

    3. 3)

      Finally, operate the blockchain system as the stand along system.



Blockchain is a promising breakthrough technology and is highly applicable to vast businesses. However, it is still hard to find empirical evidence to show the comparison between blockchain approaches and traditional approaches. With reference to adoption, businesses should realize that the blockchain system is not yet at an optimum maturity level and should conduct extensive feasibility studies before implementation.



This study was funded by National Natural Science Foundation of China (No. 71601090).

Authors’ contributions

HW carried out the design of the study and coordination and draft the manuscript. KC participated in the research design and drafted the manuscript. DX participated in the research design and paper writing. All authors read and approved the final manuscript.

Competing interests

The authors declare that they have no competing interests.

Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (, which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors’ Affiliations

Rongxin Internet Finance Group
South University of Science and Technology of China
University of Queensland


  1. Blockchain (2016) The $5 billion opportunity for reinsurers. Price Water House Coopers
  2. CCS (2014) ACM Computing Classification System (CCS).
  3. Crosby M, Nachiappan, Pattanayak P, Verma S, Kalyanaraman V (2016) Technical Report. Sutardja Center for Entrepreneurship & Technology, University of California Berkeley
  4. Curtis B, Hefley WE, Miller S (1995) Overview of the People Capability Maturity Model. Technical report, CMU/SEI-95-MM-01. Pittsburgh
  5. Herbsleb J, Zubrow D, Goldenson D, Hayes W, Paulk M (1997) Software quality and the capability maturity model. Commun ACM 40(6):30–40View ArticleGoogle Scholar
  6. Park S-H, Eo J, Lee JJ (2012) Assessing and managing an organization’s green IT maturity. MIS Q Exec 11(3):127–140Google Scholar
  7. Poppelbub J, Niehaves B, Simons A, Becker J (2011) Maturity model in information systems research: literature search and analysis. Commun Assoc Inf Syst 29(27):505–532Google Scholar
  8. Zamfir V (2016) The Blockchain Has a Dark Side. IEEE Spectrum, p 12–13


© The Author(s). 2016