Towards an integrated framework for developing blockchain systems

Full text

1
This is a preprint version, accepted for publication in Decision Support Systems journal
Towards an integrated framework for developing blockchain systems
Mahdi Fahmideh, University of Southern Queensland, Australia
Babak Abedin, Macquarie University, Australia
Jun Shen, University of Wollongong, Australia
Abstract. Although the expanding applications of blockchain technologies have been widely
explored in the IS literature, a noticeable gap exists in understanding information systems
development methods (ISDMs) that facilitate the implementation of systems leveraging these
technologies. A conceptual foundation that cohesively organizes an ISDM along with its facets
associated with the development lifecycle for this class of systems is lacking. Applying a Design
Science Research approach and borrowing ideas from method engineering, we describe a
comprehensive framework for the development of blockchain systems. A series of qualitative in-
depth applicability checks with domain experts and case studies lend credence to the core
framework fragments. The evaluation results demonstrate the utility of the proposed framework
as a conceptual anchor to simplify the understanding of the complex nature of developing
blockchain systems and lead researchers to suggest future research agendas in their quests using
our framework. The framework can aid practitioners in comparing or designing new ISDMs to
satisfy the requirements of blockchain development.
Keywords: Information system development, blockchain, design science, method engineering

2
1. Introduction
Organizations are still concerned about the intricate complexities and uncertainties involved in
implementing systems that leverage blockchain technology [1],[2]. For example, numerous
transactions stored on Ethereum have been attacked, with high severity in multiple incidents. For
instance, the DAO and Parity Wallet hacks caused a total loss of USD $150 M. Failures have
extended beyond Ethereum, with USD $58,000 and USD $600 million stolen from the EOS and
Axie Infinity [3] platforms, respectively, using fake tokens. To alleviate these issues, there is a
long-standing acknowledgment that the adoption of information systems development methods
(ISDMs), among other factors, plays a crucial role in the successful implementation and effective
maintenance of systems coupled with emerging technologies [4],[5],[6]. Research and practice in
the IS field have largely benefited from ISDMs as the centerpiece of quality management
initiatives to build sustainable ISs in a cost-effective manner [7],[8].
Although practitioners believe that conventional system development practices can be applied to
implement blockchain systems, as characterized by the phrase old wine in new bottles [9],
opponents vehemently argue that the shift to blockchain results in unique complexities and
requirements to address within the system development lifecycle [10],[11],[12]. Many aspects of
blockchain systems appear to contradict the development of conventional systems. For example,
blockchain platforms enable multiple individuals, organizations, and devices to execute a cross-
chain business workflow concurrently in a decentralized manner, resulting in new ways of data
validation, transaction integrity, and interactions. While some of these complexities are rooted in
the immaturity of current blockchain platforms and the relatively nascent nature of their
application domains, others are inherent to the fundamental concept of the distributed ledger
architecture upon which blockchain systems are developed and run. Therefore, the development

3
of ISs that use blockchain is considerably more complicated than that of non-blockchain systems
[2],[13].
However, a theoretical framework underpinning ISDMs pertinent to this class of systems is
nonexistent in the literature, and a disciplined, organized, and mature development process is
lacking [14]. Despite its significance, mounting evidence in the literature reveals that the concept
of blockchain-specific ISDMs has not been aptly sharpened as an individual unit of analysis;
rather, the concept is murky at best and often combined with purely technical, narrowly scoped
trial and error techniques for programming smart contracts and researcher intuitions [15].
Blockchain research is one of the most vibrant areas in the IS field, and extensive work is still
required to redress the suggestion of Rossi et al. [2] that novel theories are needed or existing
theories should be revisited in light of blockchain. The availability of an integrated blockchain-
specific ISDM is critical to advance the understanding of this salient area of blockchain research
[16]. As with any emerging technology in the IS field, the development of blockchain systems
requires the availability of advanced tools and implementation techniques as well as a nuanced
understanding of their holistic development lifecycle. The lack of a theoretical framework
underpinning blockchain-specific ISDMs hinders research that aims to establish the sequence of
its underlying mechanisms; that is, analysis and engineering business processes based on
blockchain [17]. The availability of such a conceptual framework would offer a complementary
viewpoint to existing knowledge in IS blockchain research and elucidate the development
lifecycle of these systems.
To address this knowledge gap, the current research extends the concept of ISDMs to emerging
IS research in the blockchain domain by providing an integrated framework constituting an

4
expanded array of conventional IS development lifecycles. The framework, which is based on the
concepts of method engineering [18] in the IS field, aims to take an wholistic view of the scattered
literature on blockchain development to unify different perspectives and abstract away from
technical concentration (e.g., Bitcoin scripting languages, smart contract programming models,
and cryptography algorithms). The framework serves as a means of establishing a shared
understanding and standardized terminology to facilitate effective communication and utilization,
and to evaluate existing or new blockchain-specific ISDMs.
We illustrate the utility of our framework, which is rigorously designed and validated based on
the guidelines of the Design Science Research (DSR) approach [19], through a series of qualitative
interviews with selected blockchain experts and real-world scenarios of blockchain
implementation in the supply chain and finance industries. Based on these findings, this study
provides a useful yardstick for IS researchers and practitioners to guide the design of entirely new
blockchain ISDMs and to evaluate existing ones (a.k.a., in-house) analytically, so as to identify
their deficiencies in supporting blockchain system development. Among the two dominant
perceptions regarding the principal outcomes of a DSR project; that is, design artifact camp vs.
design theory camp [20], the proposed framework tends towards the artifact school of thought
leading to the provision of new levels of customer service and convenience [21]. From this
perspective, the contribution of our work is an instance of exaptation [22]; that is, the adoption of
solutions from the IS field to a new problem domain, which is a conceptual shortcoming associated
with ISDMs pertinent to the blockchain domain. To the best of our knowledge, this is the first
study to extend the application of design science to ISDMs in the blockchain context.

5
The remainder of this paper is organized as follows. Section 2 discusses the guiding theories for
constructing our framework, unique requirements for developing blockchain systems, and the
studies most relevant to this research. Our research approach is presented in Section 3, followed
by a presentation of the proposed framework in Section 4. In Section 5, we demonstrate the utility
and application of our framework in analyzing real-world scenarios of blockchain system
development, before discussing the theoretical and practical implications of the study in Section
6. Finally, we discuss the limitations of our work and provide concluding remarks in Section 7.
2. Background
2.1. Theoretical foundations
A search of the IS literature reveals multiple definitions of ISDM, which vary significantly in
direction and detail. More recently according to Sabine et al. [4], ISDM refers to the entire suite
of system development lifecycle activities, e.g., planning, analysis, design, building, testing, and
maintenance, undertaken by humans individually/collectively to create a working information
system. This definition underscores at least three core aspects, namely development processes
(means of working), roles (means of controlling), and modeling (means of modeling), underlying
typical ISDM constituents (Figure 1). These aspects organize the coordination of IS teams,
specifications of certain activities/tasks, sequences, necessary input/outputs, and tools for a
system implementation endeavor. That is, regardless of the application domains for which they
are defined, ISDMs are commonly grounded in these fundamental aspects at the macro level,
although they may vary at the micro level and in domain-specific operationalizations [7].
Retrospectively, this view is consistent with the studies conceptualizing ISDMs for systems
relying on emerging technologies (e.g., business analytics [23], Internet of Things (IoT) [24], and
cloud computing [25]) under the same aspects. This study complements these aspects by capturing

6
the essence of ISDMs in implementing blockchain systems. This implies that it is necessary to
rethink whether ISDMs require an extension or wholesale change in the development mindset
attuned to blockchain development [2],[4],[16]. It is conceivable that the forthcoming generation
of ISDMs can assist IS teams in effectively implementing blockchain systems. These ISDMs
would fully or partially encompass the development process, modeling techniques, and relevant
roles specifically prescribed for blockchain system development.
Several approaches subsumed under the notion of method engineering [26],[18],[27] are
available, suggesting the construction and adaptation of ISDMs as a means of achieving flexible
and well-situated information system development. We borrow ideas from method engineering,
through which a set of method fragments; that is, individual and reusable building blocks of
different ISDMs [18], are assembled to create a new integrated ISDM framework. In this study,
the method fragments, which are labeled under three aspects (Figure 1), are derived from research
data in the literature but are iteratively refined and complemented by the opinions of domain
experts and real-world blockchain project case studies.

7
Figure 1. Core aspects of a typical ISDM used in this research, adapted from Sabine et al. [4]
2.2. Unique requirements in developing blockchain systems
Blockchain technology can be described as a distributed ledger technology (DLT), underpinned
by five fundamental assumptions: decentralization, peer-to-peer (P2P) transmission, transparency
with pseudonymity, irreversibility of records, and computational logic. These assumptions raise a
set of essential requirements for a typical ISDM, which is applied to build blockchain systems.
Drawing on the IS blockchain literature [28],[16],[29], the following requirements offer insight
into the design of blockchain-specific ISDMs.
Security and privacy. Although blockchain technology holds promise for various industries, its
credibility has been challenged by apprehensions regarding security and privacy. In particular, the
legitimacy of public blockchains has faced scrutiny because of concerns such as smart contract
vulnerabilities, consensus attacks, and privacy breaches. For example, in DLT protocols, where
multiple network participant nodes execute smart contract code, the underlying logic of the smart

8
contract becomes accessible to all entities operating these nodes. It is imperative to fortify the
system against such vulnerabilities by implementing robust security measures and conducting
comprehensive testing and auditing. To address these security concerns, an ISDM should
incorporate method fragments guiding the selection of an appropriate blockchain type, whether
permissioned or permissionless, with access restricted to authorized users only, thereby
safeguarding the data and integrity of the platform.
Scalability and performance. Scalability pertains to the capacity of the system to maintain optimal
performance as it undergoes expansion, such as increasing the number of network participant
nodes, storage demands, and transaction response times in tandem as the network grows.
Blockchain platforms often face scalability limitations, particularly in public and permissionless
networks. The blockchain system performance may be degraded as the number of transactions and
participant nodes increases. Hence, an ISDM must provide techniques to address scalability
requirements. For example, the adoption of privately permissioned blockchains can be
recommended by the ISDM because it involves a smaller number of nodes that add blocks to the
chain, resulting in improved performance and scalability.
Interoperability. Systems may differ in their capabilities to exchange and utilize information
effectively. Blockchain platforms may use different protocols, consensus algorithms, and data
formats that may not be supported by existing infrastructure and legacy systems. Integrating
different system components that run on/off blockchain platforms requires careful readiness
analysis and interaction design standards to enable seamless cross-chain communication,
interaction, and data transfer.

9
Energy consumption. Each smart contract transaction (in Ethereum, for instance) incurs a gas fee,
which is determined by the computational intensity of the transaction. Higher computational
requirements result in higher gas fees. The execution of the smart contract may fail if a transaction
consumes an excessive amount of gas. Accurately estimating the gas consumption of a smart
contract can be a complex task. Furthermore, proof-of-work consensus algorithms that are
employed to validate transactions require significant computational resources and energy
consumption. ISDMs should offer guidelines or techniques for designing energy-aware smart
contracts and selecting appropriate consensus algorithms.
Maintenance. Once a blockchain system is in operation, challenges relating to maintainability
negatively affect the ease of updating the deployed smart contract codes, such as incorporating
new features, addressing flaws, and enhancing the code efficiency of smart contracts. An ISDM
is expected to provide the necessary support for smart contract maintainability to enable seamless
updates, flaw corrections, and code improvements throughout the smart contract lifecycle.
Programming languages. The choice of the smart contract programming language and execution
platform may result in complexities in the development of blockchain systems. Not all
programming languages provide built-in support for smart contract development. Some
blockchain platforms (e.g., Hyperledger Fabric and Ethereum) may support only specific
languages, restricting developers to a limited set of options. An ISDM may need to be tailored to
align with the preferred programming paradigm of the selected platform. Thus, an ISDM focused
on the development of smart contracts on Ethereum platforms may be suitable for a project using
a language such as Solidity, which is a statistically typed contract-oriented programming language
specifically designed for Ethereum.

10
2.3. Prior literature
Although ISDMs are applied frequently in the IS field, they are remarkably less prevalent in the
blockchain literature. We found that the knowledge on ISDMs is spread out over the literature,
where each study provides a partial view of the entire development lifecycle at different levels of
abstraction, varying from a high level to purely technical. Apart from promising studies unveiling
the challenges of blockchain adoption in IT-enabled organizations (e.g., [30],[31],[11],[2]), we
deemed the cumulative body of literature most relevant to the current study to be organized within
five interrelated streams.
The first stream of research addresses the need for governance frameworks to ensure that the
development of blockchain systems in organizations is coordinated and compliant with legal
regulations and ethical responsibilities. Very few studies have enhanced conventional IT
governance models to oversee blockchain development projects. For example, Liu et al. [32]
highlighted the lack of guidance on the governance of the decision-making process during the use
and evolution of blockchain in organizations. They presented a new governance model
synthesizing the six principles of the degree of decentralization, decision rights, incentives,
accountability, ecosystem, and legal and ethical responsibilities. Werner et al. [33] defined a set
of governance mechanisms and archetypes for blockchain adoption. The main difference between
our framework and the aforementioned studies, as well as others (e.g., [34],[33],[35]), is that we
narrow our focus to ISDMs as the unit of analysis and explore how they are defined to build a
blockchain system. When developing a blockchain ecosystem governance is carried out as an
umbrella process throughout the lifecycle of all development projects and technology adoption in
organizations. Existing studies are neither sufficiently narrow nor precise in terms of the

11
components of ISDMs in their proposed governance models. However, our framework is a
complementary component to embed into these governance models to fill the gap in the
development of blockchain systems.
The second stream examines blockchain adoption in different contexts but according to a specific
IS theory. The work by Wenyu et al. [36] used the affordance-actualization theoretical lens to
conduct a case study of blockchain implementation in a conglomerate organization and suggested
a process model. The process model extended the affordance-actualization theory by adding an
experimentation phase in which blockchain use cases within the organization are identified,
implemented, and tested. Similarly, Wang et al. [37] used service-dominant logic and social
exchange theory to explore value creation using blockchain platforms that offer solutions for
supply chain partners. The results were interpreted through a series of qualitative analyses
showing the benefits emanating from the blockchain by determining customer categories, their
target motives, and the practices of resource exchanges. These sample studies and others such
as[38],[39] remain in the phenomenological exploration of blockchain, and aspects of ISD
methods, such as development process tasks, roles, and modeling, remain unexplored.
Mirroring developments in the broader literature, the third research stream, which is probably the
closest to the focus of the current study, is dominated by two groups. The first group, which is
mainly associated with the software engineering community, addresses the purely technical,
implementation-oriented, and platform-centric challenges faced by smart contracts. In general, the
central claim of these studies is the proposal of techniques and tools to help developers with
automatic smart contract code generation, detecting security defects, detrimental code flaws,
testing, code execution efficiency on the Ethereum, EOSIO, and Hyperledger Fabric platforms,

12
and updating smart contract codes. Although there are merits to adopting these techniques in the
implementation phase of the development lifecycle, they are largely naïve and insufficiently
grounded in the concept of ISDM. In this study, we raised the abstraction level of the development
lifecycle and fed these studies as data sources for the creation of our framework. In practice, the
techniques proposed in this research stream can be used to operationalize the proposed framework.
However, the second group of work in this research stream, which mainly originates from IS
literature, either accommodates the common system development lifecycle (e.g., [40],[41],[42])
or promotes agile practices (e.g., [43]) in the development of blockchain systems. These studies
do not incorporate core method fragments specialized for blockchain throughout the blockchain
development lifecycle or provide a full end-to-end model for such development. For example, the
method in [41] is specifically designed for implementing industrial IoT systems running on
blockchain platforms.
The final stream of work covers broader literature such as Internet blogs and white papers that
often do not provide rigorous domain-independent validation and generalization but propose
general ideas surrounding blockchain development. The literature in this stream offers a multitude
of studies (e.g.,[44],[45],[46]) driven by the intuitions of bloggers. Similarly, big IT market
players such as IBM [47], Amazon [47], and Deloitte [48] provide experience reports and case
studies of the successful implementation of blockchain systems. Nevertheless, the development
lifecycle is either uncovered, probably because of intellectual property, privacy, and regulatory
issues in publishing internal work, or somewhat narrowly bound to a specific blockchain
development scenario.

13
Despite the proliferation of blockchain research, there is a dearth of studies that address
overlapping ISDM areas, and none of the reviewed streams exclusively aims to create an
integrated framework underpinning ISDMs for this context. The availability of these conceptual
clues is critical. Because ISDMs span all lifecycle stages of implementing blockchain systems and
are relevant to many prescriptions for business transformation to blockchain, their influence on
the high-quality development of target blockchain systems is profound and overarching in nature.
This study aims to address this gap; accordingly, we turn our attention to building a theory-
grounded IS model to guide our inquiry.
3. Research approach
This study seeks to design and validate an integrated framework that provides a cohesive
understanding of blockchain system development, thereby providing a foundation for researchers
and practitioners to use the ISDM concept in the context of blockchain development. Research
that focuses on creating meaningful artifacts to support system development is a type of design
science in the IS field [19],[22]. Thus, we follow the guidelines of the DSR approach to create
artifacts. A DSR project is stimulated by identifying a justifiable research problem, followed by
defining an objective solution to solve the research problem. ISDMs that aid blockchain
development are largely unnoticed and the existing material is fragmented, imprecise, and
incomplete in the unbounded and continuously growing body of IS blockchain literature. A
corollary of this shortcoming is that researchers and practitioners are unprepared and make ad-
hoc interpretations when implementing this new class of ISs. This research ameliorates the lack
of understanding of ISDM for blockchain by proposing a unified framework that captures key
aspects and method fragments for incorporation into the blockchain system development lifecycle
to guide IS practitioners and researchers when defining a new ISDM or evaluating and extending

14
an existing one in support of blockchain development. Drawing on the view of Gregor and Hevner
[22] that kernel theories are justificatory input for artifact creation, the concepts of method
engineering are employed, wherein individual pieces of method fragments are reused and
assembled from different existing sources to create an integrated framework. This framework
enables the characterization of ISDMs for implementing blockchain systems from the perspective
of the development process, roles, and modeling [4].
3.1. Framework artifact quality criteria and design iterations
A DSR project is administered in a series of build-validate-refine iterations, resulting in one or
more artifacts. The iterations are driven by the extent to which an artifact is expected to meet
certain quality criteria (i.e., design principles or meta-requirements) as its construction progresses
[20]; that is, seeking usefulness not necessarily perfect solutions [49]. These quality criteria are
used for artifact design and validation [22] and indicate the ability of an artifact to satisfy its purist
goals.
The creation of our framework artifact is indeed a classificatory effort; that is, creating a set of
assumptions, concepts, values, and practices that constitutes a means of understanding the
research within a body of knowledge [50]. In this vein, we leverage the criteria set adopted from
the IS literature (e.g., [51],[52]), which informs the content and structure of a classificatory artifact
creation effort, such as theoretical frameworks, taxonomies, and typologies. Applying these
criteria during the creation cycles of the framework artifacts is essential to ensure that the resultant
framework comprises aspects that each have mutually exclusive and collectively exhaustive
method fragments relevant to the blockchain system development lifecycle. The criteria in Table
1 were fed into the artifact creation iterations.
Table 1. Quality criteria revisited for the context of this research and fed into the framework design iterations [51], [52]

15
Criterion
Definition
Comprehensiveness
The framework has sufficient coverage of critical method fragments related to process,
modeling, and roles for incorporation into the development lifecycle of blockchain
systems.
Generality
The framework is abstract and independent of specific blockchain platforms, protocols,
standards, implementations, and other concrete technical details.
Soundness
The framework is meaningful and has a semantic link to real-world blockchain
development
Our DSR approach was sustained in three consecutive iterations of conceptualization/deduction
(1st iteration) and empiricism/induction (2nd and 3rd iterations), each leading to a cumulatively
built framework in line with the quality criteria (Table 1). This meant a shift of focus between
research data (i.e., existing literature in the 1st iteration) and empirical data (i.e., domain experts
and case studies in the 2nd and 3rd iterations, respectively). The iterations along with their
underlying logic, input sources, applied analysis technique, and transitional results are outlined in
Table 1, but the internal working of the iterations is delineated in sections 3.2.1–3.2.3. For
simplicity, noticeable refinements to the framework after each iteration are presented in section
3.2.4.
Table 2. Framework creation iterations
Iteration
Primary
purpose
Targeting
quality
criteria
Data source
Technique
Transitive artifact
1st
Crafting an
initial
framework
All,
except for
soundness
Blockchain
literature
Systematic
literature
review (63
studies –
Appendix A)
and thematic
analysis
Preliminary framework
composed of 45 method
fragments for 23 tasks, 7
roles, and 6 modeling
2nd
Validating,
refining, and
extending
framework
All
Domain
experts’ review
12 qualitative
interviews
Updated framework with 3
new method fragments
under development process
and role aspects, changing
the structure of the
framework
3rd
Validating,
refining, and
extending
framework
All
Real-world
blockchain
system
implementation
scenarios
2 case studies
Updated framework with 3
new method fragments
under the development
process and modeling
aspects

16
3.2. Creation of framework
3.2.1. 1st iteration: framework derivation from the literature
The guidelines in the systematic literature review [53] were considered as a point of departure to
collate a set of commonly occurring method fragments from the literature. This iteration assumed
that the literature on blockchain research is rooted in similar notions and axiomatic commonalities,
although they may vary in technical and operational details, such as the choice of blockchain
platforms, smart contract scripting languages, and development tools. We used secondary data in
the form of studies selected from the literature along with the research streams listed in section
2.2. Secondary research data have been recognized as an important source for conceptualization
and theory generation efforts [54] and have been used extensively in previous ISD studies [25],
[55], [56]. The research data in the context of the current research were studies delineating either
the partial or full development lifecycle of blockchain systems published in the scientific digital
libraries of AIS, SCOPUS, Google Scholar, ACM, and IEEE from 2016 onwards.
Given the nascent state of ISDM for blockchain, each piece of work in the literature could provide
only a partial view of specific phases or areas within the development cycle. A paper was selected
from the literature to feed into the framework creation upon satisfaction of four conditions: (i)
presenting a clear business problem for which the implementation of a blockchain system had
been proposed as a viable solution; (ii) adopting blockchain as a core technology, rather than a
subsidiary, as the focus of the system implementation; (iii) explaining an actual system
implementation rather than ideation; and (iv) providing good records of system implementation
in the form of an in-depth case study, interview, prototype, or simulation so that we could identify
instances of method fragments.

17
The framework was derived based on preconceived assumptions regarding the development
process, role, and modeling aspects. More precisely, the method fragments were defined by
abstracting, harmonizing, and labelling text segments in the selected studies into a set of method
fragments to align with the framework. If an identified method fragment was meaningfully related
to one or more aspects, it was classified as such. Table 3 presents an example of research data on
five exploratory case studies of blockchain adoption reported in AIS-leading journals, excluding
MISQ, ISR, and ISJ, in which the blockchain development undertaken was ancillary to the
purpose of our analysis. These case studies provided in-depth insights into the real-life
development of blockchain systems, leading to the integration of method fragments within the
overarching framework. Statistically, of 63 selected studies, 78%, 39%, and 37.5% provided
method fragments related to aspects of the development process, role, and model, respectively
(Appendix A).
Table 3. Excerpt of coding research data into relevant method fragments
Study
Venue
Research data
Aspect(s)
Candidate
method
fragment
[S28]
Wang, Lu, et al.
Value creation in
blockchain-driven
supply chain
finance,
Information &
Management
(I&M)
“our findings indicate three distinct roles during
the blockchain-enabled value creation processes:
core company, supplier, financial institution,” p. 5
Role
Blockchain
user
“standardized norms and protocols are required to
be applied to transactions to increase the efficiency
of B2B interactions,” p.7
Development
process
(design phase)
Consensus
protocol
design
“transactions in a multitier SCF scenario require
higher settlement speed and adequate security
guarantees,” p.8
Development
process
(design phase)
Security
design
[S47]
Du, Wenyu
Derek, et al.
Affordances,
experimentation
and actualization
of FinTech: A
blockchain
implementation
study, The Journal
“not all use cases were feasible. For example,
AirSouth’s headquarters intended to integrate the
loyalty programs of subsidiaries, such as airlines,
hotels and tourism, but subsidiaries did not want to
give up their customer information,” p. 11
Development
process
(analysis
phase)
Feasibility
assessment
“The development team developed a use case,
whereby small suppliers could use blockchain
records to prove their solvency and secure loans
from financial institutions,” p. 7
Development
process
(analysis
phase)
Requireme
nts
analysis

18
of Strategic
Information
Systems (JSIS)
[S58]
Vaia, Giovanni, et
al. Digital
governance
mechanisms and
principles
that enable agile
responses in
dynamic
competitive
environments,
European Journal
of Information
Systems (EJIS)
“The suppliers had the responsibility to define the
specific architecture and manage all of the
implementation activities at the periphery,” p. 9
Model
Architectur
e models
“Spunta proof-of-concept project was powered by
close collaboration and coinnovation between all
participants, with each playing a key role,” p. 9
Development
process
(analysis
phase)
Actor
identificati
on
“Spunta participants reached consensus on
“Corda” as the blockchain platform to underpin the
project. The collaborative solution resolved
mismatches through performing checks and
exchanges directly within banking applications,” p.
9
Development
process
(design phase)
Consensus
protocol
design
[S59]
Zhang, Wenping,
et al. Beyond the
block: A novel
blockchain
technical model
for long-term care
insurance, Journal
of Management
Information
Systems (JMIS)
“we only include four prominent stakeholders in
LTCI: a person applying for LTCI (denoted as
applicant), a nursing home (denoted as NHO), an
LTCI distributing insurance company (denoted as
DIO), and an LTCI leading insurance company
(denoted as LIO),” p. 15
Role
Blockchain
user
Proposed InsurModel blockchain model (Figure 1
on p. 10)
Model
Architectur
e models
[S14]
Chong, Alain Yee
Loong, et al.
Business on chain:
A comparative
case study of five
blockchain-
inspired business
models, Journal of
the Association
for Information
Systems (JAIS)
“if trading partners are on separate blockchains,
transactional data are inscribed on both subchains
synchronously,” p. 10
Development
process
(design phase)
Off/on
blockchain
identificati
on
“by developing its own blockchain architecture,
ChainArchitect is able to offer an open innovation
platform,” p. 10
Model
Architectur
e model
“we designed a scenario-based task and recorded
the time spent on task completion across three
different technical models. This task aims to
identify the source of tampering and fraud… This
experiment has two players: a fraudster and a
detective. The task of the fraud is to select a
business node randomly, tamper with the file at this
node, and send the tampered file to the subsequent
node(s),” p. 16
Development
process
(implementati
on phase)
Test

19
3.2.2. 2nd iteration: domain expert review
To extend and refine the framework, we conducted a domain expert review [57] to obtain
affirmative or dissenting qualitative feedback on how well the framework was perceived regarding
the quality criteria (Table 1). The purposive selection of experienced practitioners was strictly
driven by three exclusive conditions: (i) actively involved in at least one real-world blockchain
(on-going) project with explicit responsibilities in a development team; (ii) formally enacted an
ISDM (e.g., agile or in-house) at the macro level within which a micro-level blockchain-specific
development was performed at the individual project level, as an indication of the maturity of the
host organization in systematic system development; and (iii) possessed some knowledge of
ISDMs. We invited 36 randomly selected experts from our industry network, of whom 13
accepted our invitations (denoted as E1–E13 in Table 4). The selected experts were from six
countries and had a combined experience of over seven years in blockchain system development.
Of the 11 interviewees with different roles, which allowed us to gain different perspectives on the
framework artifact, two were purely technical developers of the core blockchain infrastructures.
Our research project objectives, relevant terminologies, and review procedures were explained to
each participant to obtain a consistent understanding of our research project goal. This included
an invitation letter, a three-page document detailing the method fragments of the framework, and
a set of open-ended questions associated with the quality criteria (Table 1), which was sent as an
electronic document to each expert via Google Forms. Without communicating, each research
participant qualitatively assessed the framework to determine its soundness and deficiencies as
per the quality criterion set. Wherever required, we conducted follow-up interviews with each
participant to prevent the misinterpretation of their feedback or further open-ended questions. The
feedback collected from the research participants, which spanned two months, from August to

20
October 2022, was treated anonymously and confidentially to refine the framework, resulting in
the next version.
Table 4. Details of domain experts recruited for framework review
ID
Number
of
review
sessions
Role of
expert
Adopted
ISDM
Application
domain
Experience
Blockchain type
Country
E1
2
Blockchain
developer
Scrum
Blockchain
1 yrs
Permissioned
public
Australia
E2
3
Blockchain
developer
Scrum
Blockchain
1.6 yrs
Permissioned
public
Switzerland
E3
4
Blockchain
consultant
Scrum
Supply chain
6 yrs
Permissioned
private
Australia
E4
1
Blockchain
developer
Scrum/
Kanban
Digital
governance
5 yrs
Permissioned
private
Germany
E5
1
Blockchain
developer
In-house
Finance
4 yrs
Permissioned
private
Australia
E6
1
Project
leader
In-house
Supply chain
1 yrs
Public
Pakistan
E8
1
Technical
advisor
Lean
Energy
5 yrs
Permissioned
private
United
States
E9
1
Systems
architect
XP
Game
2 yrs
Permissioned
public
Germany
E10
2
Blockchain
developer
Scrum
IT
1 yrs
Permissioned
private
Canada
E11
2
Researcher
Lean
Education
3 yrs
Permissioned
private
Australia
E12
1
Project
leader
In-house
Finance
5 yrs
Permissioned
private
Australia
E13
2
Project
leader
In-house
IT
6 yrs
Permissioned
public & private
Australia
3.2.3. 3rd iteration: case study application
As discussed in Section 5, the dual purpose of the case studies was to examine how capable the
framework artifact is in framing blockchain system development endeavors in case organizations
and to identify areas for improvements in an enacted in-house ISDM, which may positively impact
the cost, on-time delivery, and quality of blockchain system development. This approach involved
conducting a series of thought trials [58] that have been applied in previous literature to evaluate
theoretical IS frameworks [51]. We selected two completed projects [55] that, in addition to the

21
first two conditions in the 2nd iteration, had a consistent and relatively stable context and sufficient
availability of documents (e.g., logs, reports, diagrams, and smart contract source codes) to
strengthen the triangulation and substantiation of the method fragments of the framework. After
obtaining permission from the ethics authority of our academic institute and ensuring the privacy
of the project data of the organizations, we conducted a post-hoc analysis through a series of
interviews with each project leader, over four months from August to December 2022, to analyze
the conformance of the enacted ISDM in their organizations to the framework qualitatively. The
interviewees were first provided with a full list of the method fragments of the framework,
accompanied by their definitions. To determine whether the method fragments had been enacted
in the in-house ISDM of the organization (e.g., Agile Scrum, XP, and relevant sprints), we asked
interviewees to indicate the perceived important method fragments in their project and to provide
a rationale and illustrative examples to support their answers. We investigated the adopted in-
house ISDMs as the units of analysis. Among them, we examined the conformance of significant
events, decisions, and actions in the project logs to the corresponding method fragments in our
framework. The iteration provided an opportunity to identify missing method fragments in the
framework, thereby yielding a refined framework.
3.2.4. Iterative refinements to framework and quality criteria
In relation to the DSR guidelines asking for design as a search process [49], ensuring the
adherence of the framework to the quality criteria was related to both the conceptualization and
empiricism iterations. Each iteration provided an opportunity to extend and refine the framework
based on the quality criteria. The following provides exemplary evidence for applying quality
criteria to the iterations of the framework creation.

22
To address the criterion of comprehensiveness, the snowballing technique [59] was applied in the
1st iteration, through which forward and backward searches over the selected papers were fed into
the iteration as resources for identifying new method fragments. However, the framework was
deficient in terms of feedback from domain experts and case studies in the 2nd and 3rd iterations.
Thus, to improve its comprehensiveness, we extended the framework to two and three new method
fragments associated with the process and role aspects, respectively.
For the generality criterion, the recommendation by Nickerson et al. [51] for taxonomy design
was followed by noting that the conceptual models should be explanatory, not descriptive; that is,
not explaining a framework in complete detail, but rather, providing useful explanations of the
nature of the framework. Therefore, in the derivation of method fragments during the iterations,
we were inclined to include method fragments that were sufficiently representative, agnostic to
blockchain platforms, and independent of implementation techniques and tools to make them as
equally applicable as possible in different contexts of blockchain system development. For
example, we discarded a come-out candidate method fragment known as analyze device mobility
(a task for blockchain IoT systems) that was identified from study 61 (Appendix A) in the 2nd
iteration and fuzzing test (a technique to identify bugs in blockchain smart contracts written in
different programming languages) as suggested by E3 in the 3rd iteration. We deemed that the
inclusion of these method fragments could skew the framework towards being too specific,
whereas other iterations did not necessarily recommend them out of other options.
In addition to the domain expert review in the 2nd iteration, we used a frequency-based technique
as a yardstick to determine the inclusion of a candidate method fragment in the framework to
satisfy the soundness criterion. The technique, with its previous application in the IS literature

23
[55],[25], is based on the premise that a conceptual model for a given domain should be formed
based on the most commonly referred to and agreed upon elements. Hence, during the 1st iteration,
candidate method fragments with a lower frequency were revisited or omitted from the
framework.
4. Framework of ISDM for blockchain
The framework depicted in Figure 2 maintains a balance between being sufficiently theoretical to
capture the essence of the development lifecycle for blockchain systems and being sufficiently
aligned with empirical data for validation purposes. Inevitably, in such an artifact creation
exercise, technical details relating to framework instantiation and operationalization will be
mentioned; however, we deemphasized these details to focus on the core ISDM aspects for the
development of blockchain systems.
The framework captures important method fragments that are classified according to the
development process, role, and modeling aspects [4]. Within this framework, the development
process unfolds along a set of task method fragments, although their sequences are not fixed, and
they are grouped into seven phases: analysis, preliminary design, detailed design, construction,
transition, maintenance, and retirement. It is worth noting that, at the macro level, the development
phases in the framework are reminiscent of the conventional ISD lifecycle, e.g., the model of
Avison et al. [6], yet consistent with earlier blockchain research [12],[32]. In addition, the
development phases suggest new special method fragments for incorporation into the
conventional ISD lifecycle or an existing in-house ISDM that suits a blockchain project, as
explained further.
The analysis phase calibrates further phases by identifying organizational challenges and existing
points in business workflows for which the implementation of a

24
Figure 2. Framework as a backbone providing constituent method fragments classified under development process, modeling, and role aspects. Many means are available for actually
applying the framework method fragments in real settings: they can be applied sequentially, in an iterative and ongoing incremental manner, or according to any other development
lifecycle deemed suitable by development teams.

25
blockchain system is a solution. In the preliminary design phase, decisions are made regarding
the mapping of blockchain use cases to candidate smart contracts. This phase includes an off/on
blockchain identification task to define the overall architecture (e.g., system blueprint) of a target
blockchain system, showing how business workflows and existing systems will use the blockchain
smart contracts. The skeleton of smart contracts is crafted; that is, clauses of legal (textual)
contracts, business transaction logic, and backend codes are transformed into smart contract codes
such as Ethereum Solidity scripts that are executable on blockchain platforms. The detailed design
phase is responsible for elaborating the system architecture and smart contract models (e.g.,
operations, parameters, and states), which, in turn, act as guidelines for the construction phase.
The validated smart contracts are configured and deployed on a selected blockchain platform
during the transition phase. The maintenance phase is concerned with managing postdelivery
operations and supporting smart contracts to maintain their operations prior to the retirement
phase, where the retirement phase is performed to move back data from on-chain to off-chain.
Furthermore, a blockchain system development endeavor can be viewed as a collaboration among
human resources, actors, and other stakeholders to realize the final system [60],[61],[62]. The role
aspect in the framework indicates the responsibilities assumed by IS teams that lead to effective
organization of the development process and regulations. Beyond the typical system development
roles (e.g., project manager/technical leader developer, developer, and data modeler), a
blockchain system development endeavor entails new specific roles with different associated
responsibilities, such as legal professionals, auditors, smart contract developers, and integrators,
as shown in Figure 2. These roles may be combined in practice, where an individual can be a
smart contract developer, miner, and integrator.

26
Finally, in the context of system development, it is crucial to ensure that all aspects of the system
are adequately represented [63]. This includes models such as the system structure, processes,
transformations, and defined solutions. In this framework, the modeling aspect, which includes
diagrams, images, and pure sentential text, offers a means of understanding and obtaining
knowledge of the domain of interest, and a consistent method of communication among the roles
involved. Furthermore, models enable a precise representation of different components of a
blockchain system; for example, tracing stakeholder requirements, starting from use cases towards
actual executable smart contracts. In this vein, the role aspect characterizes a continuum of models
that are created and read as the outcome of performing task method fragments under the
development process aspect by the different roles. It should be noted that the modeling aspect in
our framework is not a substitute for the well-known modeling practices recommended in
conventional ISD; however, as shown in Figure 2, it extends to a new set of blockchain-specific
modeling associated with each phase of the development lifecycle. An ISDM may accommodate
multiple modeling techniques that vary from simple block diagrams to semi-formal languages,
such as the Unified Modeling Language (UML) and Entity-Relationship (ER) diagram, for
modeling the compositional facets of a blockchain system (e.g., smart contracts). Models may
impose a costly burden in terms of update and maintenance, and are not generated in a vacuum;
rather, they depend on the lifecycle focus and decisions of IS teams.
Some of the listed method fragments in the framework (Figure 2), such as assess readiness or
develop use cases in the development process aspect, are general and already known in
conventional ISD. We assume that they offer practical relevance to blockchain system
development, as confirmed by our findings through the iterations of conceptualization (1st
iteration) and empiricism (2nd and 3rd iterations).

27
5. Function of framework: utility application in organizations
Two qualitative case studies are presented that serve two purposes. First, they demonstrate the
efficacy of the framework in characterizing real-world scenarios of blockchain system
development. Second, they aim to highlight the value of the framework in analyzing the
shortcomings and inadequacies of the in-house ISDMs of organizations regarding blockchain
system development.
Table 5 summarizes the case studies with two development teams: (i) Food Trust: a large
multinational IT corporation that is headquartered in the US and operates over 170 countries, and
gave us access to its Australian branch, and (ii) Token Exchanger: a start-up blockchain service
provider in Switzerland.
Table 5. Details of case studies
Case 1: Food Trust
Case 2: Token Exchanger
Domain
Supply chain
Finance
Business
problem and
implemented
blockchain
system
In the occurrence of a food-borne disease
outbreak, it can take days to identify the
reason. If investigators cannot point to
farms, the government advises consumers
to avoid products grown in certain areas. A
blockchain food traceability system could
help save lives by allowing companies to
act faster and protect the livelihoods of
farmers by only discarding products from
the affected farms. The system enabled
tracking of mangoes sold in Walmart’s US
stores and pork sold in its China stores. For
pork in China, it allowed uploading
certificates of authenticity to the
blockchain, resulting in more trust, and for
mangoes in the US, the time needed to track
the provenance of over 25 products from
five different suppliers was reduced from
days to seconds.
Users are often concerned by the complexity
of transferring tokens over multiple
blockchain platforms, for example,
purchasing a non-fungible token from other
users or blockchain systems in multi-chain
environments. The project aimed at providing
a multiple blockchain ecosystem known as
Squid, i.e., a third party for interoperable
business to business integration, e.g., users
and systems, which simplifies token
exchange (or cross-chain logic) in
multiple/cross-chain blockchain
environments. Squid allows the exchange of
tokens between platforms. Users can
integrate their systems via either Squid’s
APIs and smart contracts or by using Squid’s
front-end application.
Type
Permissioned private
Permissioned public
Project duration
Ongoing
18 months
Base ISDM
Agile scrum
Agile scrum
Team size
6–30
10
Development
team
composition
Project leaders, architects, promontory,
blockchain advisors, blockchain
developers, project manager
Community manager, architect, blockchain
core developer, backend developer, user

28
experience, frontend engineer, data designer,
DevOps lead, business development
Team location
Australia (co-located)
Switzerland (distributed)
To help to discern the commonalities across and differences in the enacted in-house ISDMs among
these case studies, Figure 3 succinctly shows exemplar method fragments that were either
instantiated as evidence of their soundness in practice (blue labels) or left unaddressed in the in-
house ISDM of organizations as areas for improvement (red labels). Every blockchain
development project is driven by specific business problems and objectives. Therefore, each case
study incorporated a subset of the method fragments of the framework into its core ISDM. For
example, in the Food Trust case, the method fragments identify participants, approve agreement,
decide on/off blockchain components, design permissions, and create consensus protocols were
instantiated by the team, but in the Token Exchanger they were not (grey labels). The rationale
was that, in the Token Exchanger case, the blockchain system was aimed at serving as a public
service to enable interoperability and cross-chain token exchange across multiple blockchain
platforms. In the same vein, some other grey labelled method fragments were not observed in
either in-house ISDMs, given that either of the blockchain tools can automatically take care of
their executions or are subsidiary to the project. For example, at Token Exchanger, the Axelar
technology was adopted by the development team to operationalize method fragments relevant to
the construction and transition phases, specifically for implementing and publishing smart
contracts. The Axelar technology provided protocols, tools, and APIs that allowed core
blockchain developer roles to build on blockchain platforms for interoperable token exchanges.
However, in the Food Trust case, Hyperledger Fabric was used to implement, test, and deploy
smart contracts.

29
Figure 3 is largely self-explanatory, showing the observed method fragments instantiated in each
in-house ISDM in light of our framework. With respect to the development process, the task
method fragments develop use cases, design security, implement smart contracts, test smart
contracts, and monitor nodes were instantiated in both in-house ISDMs. The ISDM of neither
Food Trust nor Token Exchanger necessitated the instantiation of define smart contract skeleton
and define smart contract change as explicit method fragments. Regarding the role aspect, system
architect was a major player in both projects. While it was absent in the Food Trust case, the core
blockchain developer played an active role in the Token Exchanger case. The role involved
constructing the necessary APIs, system-level protocols, and tools to allow smart contract
developers to engage in cross-platform communication and construct interoperable smart
contracts. In comparison, both case studies aimed to develop smart contracts for different groups
of the blockchain user role; that is, a limited group of stakeholders in Food Trust (permissioned
private) vs. a broad group of stakeholders (permission public) in the Token Exchanger. Regarding
the modeling aspect, from the project data, we observed that for both development teams, the
models (system) prototype, base architecture, smart contract models, and data flow were mostly
upfront. For example, once the business case for blockchain technology was established, Food
Trust started working on two proofs of concept for a food traceability system.
Our framework artifact aims to provide actionable recommendations for the improvement of the
in-house ISDMs when the costs, resources, overheads, on-time delivery, and quality of the
blockchain system development become significant. At the outset, the fact that the in-house ISDM
in the Food Trust case did not provide adequate support for the method fragments analyze
technology and optimize gas consumption (red labels in Figure 3.1), which were perceived as
important by the development team, was a concern. This suggests improvement areas that should

30
be prioritized when adopting an ISDM for blockchain development. For example, the interviewed
project leaders highlighted that the optimize gas consumption design task deserves special
attention during the development process when implementing smart contracts. Each transaction
that is executed by a smart contract charges a certain amount of gas, which means that a higher
gas fee is paid when the smart contracts are more computationally intensive.

31
Figure 3.1. Instantiation of framework in Food Trust in-house ISDM
Figure 3.2 Instantiation of framework in Token Exchanger in-house ISDM
The trivial method fragments of in-house ISDMs and practices (e.g., project management, risk management, and quality assurance) are not presented to preserve the parsimony of our diagrams. Legend:
Instantiated method fragment Not necessary to instantiate Unaddressed area of the in-house ISDM for improvement

32
A comparison of the ISDM of Food Trust with the framework highlighted that performing the
comprehensive analyze technology task was relatively unaddressed during the development
process. Notably, the same observation was made regarding the security designer role in Food
Trust. Among the method fragments perceived as important in the Token Exchanger case, the
scrum post-mortem review revealed that only identify participants had not been adequately
supported as an explicit task in earlier scrum sprints (Figure 3.2), which indicates a lack of
attention to end users of the target blockchain system at the early stage of development. This
deficiency caused complexity in the coordination of the subsequent phases. Finally, another
observation made upon examining both cases was the inclusion of conventional IS practices (e.g.,
the system prototype model in both projects) in the blockchain development, which was a
confirmatory finding to [9] indicating that conventional IS can be well connected and
accommodated in blockchain development endeavors.
6. Discussion
6.1. Theoretical contributions
This study is the first to directly explore the concept of ISDMs in this area and it makes three
contributions. First, the proposed framework outlines the implementation of blockchain systems
in a core set of method fragments associated with the three key aspects of the development
process, roles, and modeling. Our study elaborates on how the method fragments underlying the
ISDM structure are incorporated into a blockchain system implementation endeavor. This
framework elevates the discussion from a purely technical (e.g., smart contract programming,
etc.) to the managerial level. This shift allows the IS community to gain valuable insights into the
entire developmental lifecycle of blockchain systems. It also creates a separation layer between

33
defining (what) and operationalizing (how) an ISDM, thus reducing the complexity of ISDM
maintenance and updates.
In addition, the proposed framework offers a solution to the knowledge integration problem in the
context of blockchain, that is, the meta-method. Prior studies [63],[64],[65],[66] discussed that
the availability of multiple views on ISDMs is beneficial, as they allow for pluralist interpretations
at the inception of emerging information technology. On the other hand, an integrated unified
view that binds these differences, which Avison and Fitzgerald [6] referred to as a method jungle,
i.e., a seemingly impenetrable maze of competing ideas, is also required for consensus creation
and standard knowledge sharing regarding domain-specific ISDMs. The same axiom holds true
for ISDMs in the blockchain domain. Most existing studies (see section 2.2) provide various
means of implementing systems that leverage blockchain platforms. However, they often remain
overly general, limited to a specific development phase, focused solely on technical concerns, or
restricted to platform choices (e.g., Ethereum, Hyperledger Fabric, and EOSIO). In contrast, our
framework systematically consolidates the essence of all classes of ISDMs for the blockchain
domain instead of individual instances [65], providing a distinction between essences and
accidents. This is an important contribution as it encourages a comprehensive understanding of
the range of key aspects and method fragments that can facilitate the institutionalization of
integrated blockchain system development, which has not been attempted in the previous
literature.
Moreover, Goldkuhl et al. [19] called for the need to design ISDMs using proper research
frameworks that meet the standards in both rigor and relevance. Our framework is a first response
to their call and, in the context of blockchain, it supports and guides researchers (especially

34
novices) in the design and evaluation of ISDMs. The framework assists researchers in evaluating
their newly proposed ISDMs or framing emerging ones in the literature in terms of three aspects:
the development process, roles, and modeling. Therefore, our framework provides a more
comprehensible theoretical foundation for organizing ISDMs for blockchain technology.
6.2. Practical contributions
Beyond its theoretical contributions, our study provides important practical contributions as well.
First, to increase the likelihood of successful blockchain adoption, the framework can identify
deficiencies in the in-house ISDM of an organization. More specifically, the framework provides
several indications of what went wrong in the implementation of a blockchain system that failed,
experienced costly security errors, and did not attain the expected goals of its stakeholders. For
example, if a blockchain system is implemented but does not operate as planned, the framework
can identify the aspects that have not been covered or adequately operationalized during the
development lifecycle. For example, in the Token Exchanger case study, the post-mortem review
of the project sprints revealed a lack of attention to the requirements analysis and identification
of actual users of smart contracts before the design and implementation of smart contracts. This
highlighted that the in-house ISDM had to reemphasize the feasibility and requirements analysis
method fragments in further sprints. Without such a framework, organizations are left unprepared
to trace the sources of system development errors and rectify them when things go wrong. Our
framework unites the current body of knowledge to guide organizations that are interested in
defining new ISDMs for blockchain development.
Moreover, the framework can be used as a guide to identify the required method fragments when
defining a new or augmenting an existing ISDM. For example, to determine which tasks and
outputs should be included in an ISDM covering the blockchain system architecture design,

35
blockchain practitioners can take steps to incorporate relevant method fragments under the
development process and modeling aspects; that is, the preliminary design phase of the
framework, as suggested by the framework, into the ISDM.
Evaluation frameworks within the IS field have inspired a consistent research stream in the IS
literature [67]. These frameworks help to identify the strengths and weaknesses, and facilitate the
comparison and selection of appropriate ISDMs for specific projects. A long trajectory of ISDM
evaluation framework variants [5],[24],[68],[69],[67],[70] with well-established constructs is
available for analyzing the characteristics of ISDMs, including structured, object oriented, and
agile. Neither key blockchain elements (such as smart contracts) nor essential blockchain-specific
method fragments were defined in these studies. However, one may be interested in knowing
when the adoption of a specific ISDM (or a combination of them) occurs in a real-world scenario
of blockchain system development [71]. Without a sound evaluation, the choice of an ISDM for
blockchain development may be merely assumed to work without any evidence. The proposed
framework allows the ISDM selection process to occur in a consistent manner. An important
caveat to note here, in conjunction with the falsifying one-size-fits-all socio-technical blockchain
characteristics [72], is that some ISDMs may merely focus on certain features and ignore others.
In this spirit, the concepts of method engineering suggest that ISDMs should be tailored to
particular circumstances to obtain organizational alignment for use [73],[74]. In this regard, our
framework provides a repository of method fragments that can be reused to construct bespoke
ISDMs or to augment an existing one to meet the requirements of a given blockchain project.
7. Conclusions and future work
This study needs to be understood in light of some shortcomings that open avenues for future
research. First, our framework can be scrutinized from the scope perspective. Although the

36
framework provides an integrated reference to blockchain-specific ISDMs, the manner in which
it can be tailored with respect to situational factors and boundary conditions related to a
blockchain project scenario has yet to be addressed. Situational factors relevant to blockchain
adoption have been discussed in the literature [16],[75]; however, the manner in which such
factors circumscribe ISDM tailoring has not yet been investigated. Extending the framework to
include supplementary customization guidance and tailoring techniques [76],[77] will enhance its
applicability and ensure its relevance and effectiveness in diverse blockchain development
scenarios. This will certainly be a fruitful area for future work that will aid in the situational
configuration of the development process, roles, and modeling in the framework.
Second, given that blockchain technology is still in the introductory stage and adopters are
concerned about its lack of technical immaturity and well-established business models [28], it was
challenging to find domain experts and comprehensive case studies that could effectively
demonstrate the application of our framework for an extended duration. However, we attempted
to achieve an optimal sample size of interviewees and carefully selected two case studies that met
certain criteria. For example, the selection of interviewees in the 2nd iteration of the framework
creation (Table 4) was based on their extensive years of real-world experience in blockchain
adoption, industry background, geographical representation, and diverse domain expertise to offer
varying feedback on the framework quality and prevent attrition bias. However, we do not claim
generalizability of our proposed framework application or that it is an exhaustive representative
of all blockchain practitioner opinions and application domains. Future research can be oriented
towards statistically validating the framework to reinforce and expand its application within
boundary conditions.

37
Third, a potential issue related to our 3rd DSR iteration, which could have affected the framework
artifact design and validation, is the retrospective nature of the personal interviews. As a
countermeasure to alleviate the critique of recall-precision errors and post-hoc project
rationalizations in retrospective responses [78], we aimed to have multiple follow-up
conversations with the interviewees to avoid misunderstanding of comments or missed method
fragments. For example, we shared the final version of the framework after refinement and our
case analysis report with the interviewees to increase the accuracy of our data analysis. We also
cross-checked our interviews with the research data from the 1st iteration to ensure that the
framework was consistently refined with the interpretations of others over time.
Fourth, our framework contributes significantly to the IS blockchain literature by enriching the
scientific underpinnings of ISDMs for the blockchain domain, upon which new ISDMs can be
constructed, evaluated, and extended. Ideally, we can empirically apply the framework throughout
the entire project lifecycle to observe its perceptual efficacy in developing blockchain systems.
However, such an evaluation is impractical because of the different timeframes in the selected
case studies and the time constraints of our study. We acknowledge that this is a limitation of our
study and that a more prolonged and periodic longitudinal evaluation is required.
Overall, the proposed framework artifact can be viewed as a method for accumulating existing
knowledge from previous literature as well as empirical findings on developing systems using
blockchain platforms. The framework establishes a holistic view of the ISDM for blockchain,
which has been overlooked in previous studies.
Acknowledgment
The authors thank the guest editors, associate editors, and reviewers for their feedback and helpful
suggestions. The authors would also like to thank Martin Ng from the IBM Corporation for his

38
constructive comments on our research project. The authors acknowledge that, in the preparation of
this work, they used generative AI-assisted technologies, such as ChatGPT, to address some writing
issues. After using this service, the authors reviewed and edited the content as needed and take full
responsibility for the content of this publication.
Appendix A
List of selected studies used in 1st iteration of framework creation
Note: J: Journal, C: Conference, S: Symposium, W: Workshop, B: Book chapter, M: Magazine, V: Multi-vocal literature
#
Author and title
Channel
Source
Year
Validation
technique
Relevant method fragment(s)
Process
Role
Model
[S1]
C. Lin, D. He, X. Huang, BSeIn: A blockchain-
based secure mutual authentication with fine-
grained access control system for industry
J
Elsevier
2018
Simulation
√
√
-
[S2]
L. Hang, D.H. Kim, Design and
implementation of an integrated IoT
blockchain platform for sensing data integrity
J
Sensors
2019
Simulation
√
-
√
[S3]
M. Marchesi, L. Marchesi, R. Tonelli, An agile
software engineering method to design
blockchain applications
C
ACM
2018
Example
scenario
-
√
-
[S4]
I. Karamitsos, M. Papadaki, N.B. Al
Barghuthi, Design of the blockchain smart
contract: A use case for real estate
J
Scientific
Research
Publishin
g
2018
Example
scenario
√
-
-
[S5]
M. Jurgelaitis, V. Drungilas, L. Ceponiene, R.
Butkiene, E. Vaiciukynas, Modeling
principles for blockchain-based
implementation of business or scientific
processes
C
IVUS
2019
Example
scenario
-
√
-
[S6]
Y. Shi, Z. Lu, R. Tao, Y. Liu, Z. Zhang, A
trading model based on legal contracts using
smart contract templates
C
Springer
2019
Example
scenario,
Theoretical
evaluation
√
-
√
[S7]
A. Badr, L. Rafferty, Q.H. Mahmoud, K.
Elgazzar, P.C. Hung, A permissioned
blockchain -based system for verification of
academic records
C
IEEE
2019
Simulation
√
-
√
[S8]
G. Destefanis, M. Marchesi, M. Ortu, Smart
contracts vulnerabilities: a call for blockchain
software engineering?
W
IEEE
2018
Case study
√
-
√
[S9]
P. Chakraborty, R. Shahriyar, A. Iqbal, A.
Bosu, Understanding the software
development practices of blockchain
projects: a survey
C
ACM
2018
Survey of
practitioners
√
-
√
[S10]
C. Udokwu, H. Anyanka, A. Norta, Evaluation
of Approaches for Designing and Developing
Decentralized Applications
C
ACM
2020
Case study,
Theoretical
evaluation
√
√
√
[S11]
Y. Yuan, F.Y. Wang, Towards
blockchainbased intelligent transportation
systems
C
IEEE
2016
Example
scenario
√
-
-
[S12]
W. Dai, C. Wang, C. Cui, H. Jin, X. Lv,
Blockchain-Based Smart Contract Access
Control System
C
IEEE
2019
Simulation
√
-
√
[S13]
W. Zou, D. Lo, P.S. Kochhar, X. D. Le, X. Xia,
Y. Feng, Z. Chen, B. Xu, Smart contract
development: Challenges and opportunities
J
IEEE
2019
Survey and
semi-
structured
interview of
practitioners
-
√
-
[S14]
A.Y.L. Chong, et al. Business on chain: A
comparative case study of five blockchain-
inspired business models
J
Associati
on of IS
2019
Case study
√
-
√
[S15]
B. Marino, A. Juels, Setting standards for
altering and undoing smart contracts
S
Springer
2016
Example
scenario
-
√
√
[S16]
K. Yue, Blockchain-augmented organizations
C
AIS
Library
2020
Example
scenario
√
-
-
[S17]
L. Luu, D.-H. Chu, H. Olickel, Making smart
contracts smarter
C
ACM
2016
Simulation
-
-
√

39
[S18]
R. Bettín-Díaz, A.E. Rojas, Methodological
approach to the definition of a blockchain
system for the food industry supply chain
traceability
C
Springer
2018
Case study,
industrial
experience
√
-
-
[S19]
X. Xu, Q. Lu, Y. Liu, L. Zhu, H. Yao, A.V.
Vasilakos, Designing blockchain-based
applications a case study for imported
product traceability
J
Elsevier
2019
Case study
√
-
√
[S20]
W. Cai, Z. Wang, J.B. Ernst, Z. Hong, C.
Feng, V.C. Leung, Decentralized
applications: The blockchain-empowered
software system
J
IEEE
2018
Industrial
experience
-
-
√
[S21]
N.B. Truong, K. Sun, G.M. Lee, Y. Guo,
GDPR-compliant personal data
management: A blockchain-based solution
J
IEEE
2019
Example
scenario
√
√
-
[S22]
A. Bosu, A. Iqbal, R. Shahriyar, P.
Chakraborty, Understanding the motivations,
challenges and needs of blockchain software
developers: a survey
J
Springer
2019
Survey of
practitioners
√
-
√
[S23]
L. Marchesi, M. Marchesi, R. Tonelli,
ABCDE—Agile blockchain DApp engineering
J
Elsevier
2020
Example
scenario
-
-
-
[S24]
B.A. Scriber, A framework for determining
blockchain applicability
J
IEEE
2018
Semi-
structured
interviews
√
√
-
[S25]
L. Cocco, A. Pinna, G. Meloni, A Blockchain
Oriented Software Application in the Revised
Payments Service Directive context
W
IEEE/AC
M
2020
Example
scenario
√
-
√
[S26]
X. Xu, C. Pautasso, L. Zhu, Q. Lu, I. Weber,
A pattern collection for blockchain-based
applications
C
ACM
2018
Theoretical
evaluation
√
-
-
[S27]
G. Al-Mazrouai, S. Sudevan, Managing
blockchain projects with agile methodology
C
Springer
2020
Example
scenario
-
√
-
[S28]
L. Wang, et al. Value creation in blockchain-
driven supply chain finance
J
Elsevier
2022
Case study
√
√
-
[S29]
Q. Lu, A. Tran, I. Weber, Integrated model-
driven engineering of blockchain applications
for business processes and asset
management
J
Wiley
2020
Example
scenario
-
-
√
[S30]
I. Weber, X. Xu, R. Riveret, G. Governatori,
Untrusted business process monitoring and
execution using blockchain
C
Springer
2016
Simulation
√
-
-
[S31]
P. Garamvölgyi, I. Kocsis, B. Gehl, A. Klenik,
Towards model-driven engineering of smart
contracts for cyber-physical systems
C
IEEE/IFIP
2018
Example
scenario
√
√
-
[S32]
T. Górski, J. Bednarski, Applying model-
driven engineering to distributed ledger
deployment
J
IEEEE
2020
Example
scenario
√
√
√
[S33]
F. Glaser, Pervasive decentralization of
digital infrastructures: a framework for
blockchain enabled system and use case
analysis
C
IEEE
2017
Theoretical
evaluation
√
√
-
[S34]
A. Mavridou, A. Laszka, E. Stachtiari, A.
Dubey, VeriSolid: Correct-by-design smart
contracts for Ethereum
C
IEEE
2019
Example
scenario
√
-
√
[S35]
P. Zhang, J. White, D.C. Schmidt, G. Lenz,
Design of blockchain-based apps using
familiar software patterns with a healthcare
focus
C
ACM
2017
Case study
√
-
-
[S36]
M. Wöhrer, U. Zdun, Design patterns for
smart contracts in the Ethereum ecosystem
C
IEEE
2018
Simulation
√
√
-
[S37]
Y. Liu, Q. Lu, X. Xu, L. Zhu, H. Yao, Applying
design patterns in smart contracts
C
Springer
2018
Case study,
Industrial
experience
√
√
-
[S38]
H.D. Bandara, X. Xu, I. Weber, Patterns for
blockchain data migration
C
ACM
2020
Theoretical
evaluation
√
-
√
[S39]
M. Wohrer, U. Zdun, Smart contracts:
security patterns in the Ethereum ecosystem
and solidity
W
IEEE
2018
Theoretical
evaluation,
Example
scenario
√
-
-
[S40]
M. Bartoletti, L. Pompianu, An empirical
analysis of smart contracts: platforms,
applications, and design patterns
C
Springer
2017
Case studies
√
-
-

40
[S41]
J. De Kruijff, H. Weigand, Understanding the
blockchain using enterprise ontology
C
Springer
2017
Theoretical
evaluation
-
√
√
[S42]
H.M. Kim, M. Laskowski, Toward an
ontology
‐
driven blockchain design for supply
‐
chain provenance
J
Wiley
2018
Example
scenario
√
-
-
[S43]
O. Choudhury, N. Rudolph, I. Sylla, N.
Fairoza, A. Das, Auto-generation of smart
contracts from domain-specific ontologies
and semantic rules
C
IEEE
2018
Case study
√
-
-
[S44]
H. Baqa, N.B. Truong, N. Crespi, G.M. Lee,
F. Le Gall, Semantic smart contracts for
blockchain-based services in the Internet of
Things
S
IEEE
2019
Example
scenario
√
√
-
[S45]
G. Governatori, F. Idelberger, Z. Milosevic,
On legal contracts, imperative and
declarative smart contracts, and blockchain
systems
J
Springer
2018
Example
scenario,
Theoretical
evaluation
√
-
-
[S46]
M. Giancaspro, Is a smart contract ‘really a
smart idea? Insights from a legal perspective
J
Elsevier
2017
Expert
validation,
industrial
experience
-
√
√
[S47]
W.D. Du, S.L. Pan, D.E. Leidner,
Affordances, experimentation and
actualization of FinTech: A blockchain
implementation study
J
Elsevier
2019
Interview
√
-
-
[S48]
A.M. Langer, Blockchain analysis and design
B
Springer
2020
Example
scenario
-
√
√
[S49]
C. Hebert, F. Di Cerbo, Secure blockchain in
the enterprise: A methodology
J
Elsevier
2019
Example
scenario
√
√
-
[S50]
J. Plansky, T. O’Donnell, K. Richards, A
strategist’s guide to blockchain
M
PWC
2016
Industrial
experience
√
-
-
[S51]
S. Almeida, A. Albuquerque, A. Silva, An
approach to develop software that uses
blockchain
C
Springer
2018
Example
scenario,
Theoretical
evaluation
√
-
-
[S52]
G. Fridgen, J. Lockl, A solution in search of a
problem: a method for the development of
blockchain use cases
C
AIS e-Lib
2018
Case study
√
√
-
[S53]
H. Rocha, S. Ducasse, Preliminary steps
towards modeling blockchain oriented
software
W
IEEE
2018
Example
scenario
√
√
-
[S54]
X. Xu, C. Pautasso, L. Zhu, V. Gramoli, A.
Ponomarev, S. Chen, The blockchain as a
software connector
W
IEEE
2016
Industrial
experience
-
√
-
[S55]
X. Xu, I. Weber, M. Staples, A taxonomy of
blockchain-based systems for architecture
design
C
IEEE
2017
Theoretical
evaluation
√
-
-
[S56]
A. Takyar, Blockchain development process
– A complete guide for innovators
V
-
2022
Experience
report
√
-
-
[S57]
C.K. Frantz, M. Nowostawski, From
institutions to code: Towards automated
generation of smart contracts
W
IEEE
2016
Example
scenario
√
√
-
[S58]
G. Vaia, et al. Digital governance
mechanisms and principles that enable agile
responses in dynamic competitive
environments
J
Elsevier
2022
Case study
√
-
√
[S59]
W. Zhang, et al. Beyond the block: A novel
blockchain-based technical model for long-
term care insurance
J
Taylor &
Francis
2021
Experiment
-
√
√
[S60]
C.T.B. Garrocho, et al. A Complete Step-by-
Step Methodology for Defining, Deploying
and Monitoring a Blockchain Network in
Industry 4.0
C
Springer
2021
Prototype
√
-
√
[S61]
S. Demi, M. Sánchez‐Gordón, M.
Kristiansen, Blockchain for requirements
traceability: A qualitative approach
J
Wiley
2022
Interview
√
-
-
[S62]
D. Geroni, 7 Stages of New Blockchain
Development Process
V
-
2021
Experience
report
√
-
-
[S63]
R. Stambolija, Blockchain Development
Lifecycle Explained
V
-
2020
Experience
report
√
-
-
Percentage (aspect / total number of studies)
50/63
25/63
24/63

41
References
[1] W. Zhang, C.-P. Wei, Q. Jiang, C.-H. Peng, and J. L. Zhao, "Beyond the block: A novel blockchain-based technical
model for long-term care insurance," Journal of Management Information Systems, vol. 38, no. 2, pp. 374-400,
2021.
[2] M. Rossi, C. Mueller-Bloch, J. B. Thatcher, and R. Beck, "Blockchain research in information systems: Current
trends and an inclusive future research agenda," Journal of the Association for Information Systems, vol. 20, no.
9, p. 14, 2019.
[3] Bloomberg, Available at: https://www.bloomberg.com/news/articles/2022-03-29/hackers-steal-590-million-
from-ronin-in-latest-bridge-attack?leadSource=uverify%20wall (last access Dec 2022), 2022.
[4] S. Matook, G. Lee, and B. Fitzgerald, "MISQ Research Curation on Information Systems Development," MIS
Quarterly Research Curation, 2021.
[5] K. Siau and M. Rossi, "Evaluation techniques for systems analysis and design modeling methods–a review and
comparative analysis," Information Systems Journal, vol. 21, no. 3, pp. 249-268, 2011.
[6] D. Avison and G. Fitzgerald, Information systems development: methodologies, techniques and tools. McGraw
Hill, 2003.
[7] N. Ahituv, M. Hadass, and S. Neumann, "A flexible approach to information system development," MIS
quarterly, pp. 69-78, 1984.
[8] K. A. Kozar, "Adopting systems development methods: an exploratory study," Journal of Management
Information Systems, vol. 5, no. 4, pp. 73-86, 1989.
[9] R. Ziolkowski, G. Miscione, and G. Schwabe, "Decision problems in blockchain governance: Old wine in new
bottles or walking in someone else’s shoes?," Journal of Management Information Systems, vol. 37, no. 2, pp.
316-348, 2020.
[10] O. Labazova, "Towards a Framework for Evaluation of Blockchain Implementations," in ICIS, 2019.
[11] R. Beck, M. Avital, M. Rossi, and J. B. Thatcher, "Blockchain technology in business and information systems
research," ed: Business & information systems engineering, Springer, 2017.
[12] R. Richard, H. Prabowo, A. Trisetyarso, and B. Soewito, "Smart Contract Development Model and the Future of
Blockchain Technology," in 2020 the 3rd International Conference on Blockchain Technology and Applications,
2020, pp. 34-39.
[13] Z. Shao, L. Zhang, S. A. Brown, and T. Zhao, "Understanding users' trust transfer mechanism in a blockchain-
enabled platform: A mixed methods study," Decision Support Systems, vol. 155, p. 113716, 2022.
[14] L. Marchesi, M. Marchesi, and R. J. a. p. a. Tonelli, "ABCDE--Agile Block Chain Dapp Engineering," 2019.
[15] O. Labazova, T. Dehling, and A. Sunyaev, "From hype to reality: A taxonomy of blockchain applications," in
Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS 2019), 2019.
[16] M. Fahmideh et al., "Engineering Blockchain Based Software Systems: Foundations, Survey, and Future
Directions," ACM Computing Surveys, 2022.
[17] J. Mendling et al., "Blockchains for business process management-challenges and opportunities," ACM
Transactions on Management Information Systems (TMIS), vol. 9, no. 1, pp. 1-16, 2018.
[18] B. Henderson-Sellers and J. Ralyté, "Situational Method Engineering: State-of-the-Art Review," Journal of
Universal Computer Science, vol. 16, no. 3, pp. 424-478, 2010.
[19] G. Goldkuhl and F. Karlsson, "Method engineering as design science," Journal of the Association for Information
Systems, vol. 21, no. 5, p. 4, 2020.
[20] R. Baskerville, A. Baiyere, S. Gregor, A. Hevner, and M. Rossi, "Design science research contributions: Finding a
balance between artifact and theory," Journal of the Association for Information Systems, vol. 19, no. 5, p. 3,
2018.
[21] R. Agarwal and H. C. Lucas Jr, "The information systems identity crisis: Focusing on high-visibility and high-
impact research," MIS quarterly, pp. 381-398, 2005.
[22] S. Gregor and A. R. Hevner, "Positioning and presenting design science research for maximum impact," MISQ,
vol. 37, no. 2, pp. 337-356, 2013.
[23] G. A. Hindle and R. Vidgen, "Developing a business analytics methodology: A case study in the foodbank sector,"
European Journal of Operational Research, vol. 268, no. 3, pp. 836-851, 2018.
[24] M. Fahmideh and D. Zowghi, "An exploration of IoT platform development," Information Systems, vol. 87, p.
101409, 2020.

42
[25] M. Fahmideh, F. Daneshgar, F. Rabhi, and G. Beydoun, "A generic cloud migration process model," European
Journal of Information Systems, vol. 28, no. 3, pp. 233-255, 2019.
[26] S. Brinkkemper, "Method engineering: engineering of information systems development methods and tools,"
Information and software technology, vol. 38, no. 4, pp. 275-280, 1996.
[27] E. White Baker, "Why situational method engineering is useful to information systems development,"
Information Systems Journal, vol. 21, no. 2, pp. 155-174, 2011.
[28] E. Toufaily, T. Zalan, and S. B. Dhaou, "A framework of blockchain technology adoption: An investigation of
challenges and expected value," Information & Management, vol. 58, no. 3, p. 103444, 2021.
[29] A. Perdana, A. Robb, V. Balachandran, and F. Rohde, "Distributed ledger technology: Its evolutionary path and
the road ahead," Information & Management, vol. 58, no. 3, p. 103316, 2021.
[30] A. Kumar, R. Liu, and Z. Shan, "Is blockchain a silver bullet for supply chain management? Technical challenges
and research opportunities," Decision Sciences, vol. 51, no. 1, pp. 8-37, 2020.
[31] J. Lindman, V. K. Tuunainen, and M. Rossi, "Opportunities and risks of Blockchain Technologies–a research
agenda," Proceedings of the 50th Hawaii International Conference on System Sciences (HICSS), 2017.
[32] Y. Liu, Q. Lu, G. Yu, H.-Y. Paik, and L. Zhu, "Defining blockchain governance principles: A comprehensive
framework," Information Systems, p. 102090, 2022.
[33] J. Werner, S. Frost, and R. Zarnekow, "Towards a taxonomy for governance mechanisms of blockchain-based
platforms," 28th European Conference on Information Systems (ECIS), 2020.
[34] R. Beck, C. Müller-Bloch, and J. L. King, "Governance in the blockchain economy: A framework and research
agenda," Journal of the Association for Information Systems, vol. 19, no. 10, p. 1, 2018.
[35] L. M. De Rossi, N. Abbatemarco, and G. Salviotti, "Towards a Comprehensive Blockchain Architecture
Continuum," in Proceedings of the 52nd Hawaii International Conference on System Sciences, 2019.
[36] W. D. Du, S. L. Pan, D. E. Leidner, and W. Ying, "Affordances, experimentation and actualization of FinTech: A
blockchain implementation study," The Journal of Strategic Information Systems, vol. 28, no. 1, pp. 50-65, 2019.
[37] L. Wang, X. R. Luo, F. Lee, and J. Benitez, "Value creation in blockchain-driven supply chain finance,"
Information & Management, vol. 59, no. 7, p. 103510, 2022.
[38] T.-P. Liang, R. Kohli, H.-C. Huang, and Z.-L. Li, "What drives the adoption of the blockchain technology? A fit-
viability perspective," Journal of Management Information Systems, vol. 38, no. 2, pp. 314-337, 2021.
[39] N. Raddatz, J. Coyne, P. Menard, and R. E. Crossler, "Becoming a blockchain user: understanding consumers’
benefits realisation to use blockchain-based applications," European Journal of Information Systems, pp. 1-28,
2021.
[40] G. Fridgen and J. Lockl, "A solution in search of a problem: a method for the development of blockchain use
cases," AMCIS (Vol. 1, No. 1, pp. 1-11). 2018.
[41] C. T. B. Garrocho, K. N. Oliveira, C. F. M. da Cunha Cavalcanti, and R. A. R. Oliveira, "A Complete Step-by-Step
Methodology for Defining, Deploying and Monitoring a Blockchain Network in Industry 4.0," in International
Conference on Enterprise Information Systems, 2022: Springer, pp. 86-106.
[42] S. Demi, M. Sánchez‐Gordón, and M. Kristiansen, "Blockchain for requirements traceability: A qualitative
approach," Journal of Software: Evolution and Process, p. e2493, 2022.
[43] M. Marchesi, L. Marchesi, and R. Tonelli, "An agile software engineering method to design blockchain
applications," in Proceedings of the 14th Central and Eastern European Software Engineering Conference Russia,
2018, pp. 1-8.
[44] D. Geroni, "7 Stages Of New Blockchain Development Process," 101 Blockchains, no. Available at:
https://101blockchains.com/blockchain-development-process/ (last access Oct 2022) 2021.
[45] R. Stambolija, "Blockchain Development Lifecycle Explained," Available at:
https://mvpworkshop.co/blog/blockchain-development-lifecycle-explained/ (last access Nov 2022), 2020.
[46] A. Takyar, "Blockchain development process– A complete guide for innovators," Available at:
https://www.leewayhertz.com/guide-to-blockchain-development-process/ (last access Nov 2022).
[47] V. Morris et al., Developing a Blockchain Business Network with Hyperledger Composer using the IBM
Blockchain Platform Starter Plan. IBM Redbooks, 2018.
[48] "Using blockchain to drive supply chain transparency ": Deloitte.
[49] A. R. Hevner, S. T. March, J. Park, and S. Ram, "Design science in information systems research," MISQ, vol. 28,
no. 1, pp. 75-105, 2004.

43
[50] A. Schwarz, M. Mehta, N. Johnson, and W. W. Chin, "Understanding frameworks and reviews: a commentary to
assist us in moving our field forward by analyzing our past," ACM SIGMIS Database: the DATABASE for Advances
in Information Systems, vol. 38, no. 3, pp. 29-50, 2007.
[51] R. C. Nickerson, U. Varshney, and J. Muntermann, "A method for taxonomy development and its application in
information systems," European Journal of Information Systems, vol. 22, no. 3, pp. 336-359, 2013.
[52] G. M. Karam and R. S. Casselman, "A Cataloging Framework for Software Development Methods," Computer,
vol. 26, no. 2, pp. 34-45, 1993, doi: 10.1109/2.191987.
[53] B. Kitchenham and O. Pearl Brereton, "Systematic literature reviews in software engineering – A systematic
literature review," Information and software technology, vol. 51, no. 1, pp. 7-15, 2009.
[54] C. Selltiz, L. S. Wrightsman, S. W. Cook, G. I. Balch, R. Hofstetter, and L. Bickman, "Research methods in social
relations," 1976.
[55] R. L. Kumar and A. C. Stylianou, "A process model for analyzing and managing flexibility in information systems,"
European Journal of Information Systems, vol. 23, no. 2, pp. 151-184, 2014.
[56] N. R. Hassan and L. Mathiassen, "Distilling a body of knowledge for information systems development,"
Information Systems Journal, vol. 28, no. 1, pp. 175-226, 2018.
[57] O. C. Robinson, "Sampling in interview-based qualitative research: A theoretical and practical guide,"
Qualitative research in psychology, vol. 11, no. 1, pp. 25-41, 2014.
[58] K. E. Weick, "Theory construction as disciplined imagination," Academy of management review, vol. 14, no. 4,
pp. 516-531, 1989.
[59] C. Wohlin, "Guidelines for snowballing in systematic literature studies and a replication in software
engineering," in Proceedings of the 18th international conference on evaluation and assessment in software
engineering, 2014: ACM, p. 38.
[60] L. M. Maruping, S. L. Daniel, and M. Cataldo, "Developer centrality and the impact of value congruence and
incongruence on commitment and code contribution activity in open source software communities," MIS
Quarterly, vol. 43, no. 3, pp. 951-976, 2019.
[61] K. Conboy, S. Coyle, X. Wang, and M. Pikkarainen, "People over process: key people challenges in agile
development," IEEE Software, 2011.
[62] J. E. Kendall and K. E. Kendall, "Metaphors and methodologies: Living beyond the systems machine," MIS
quarterly, pp. 149-171, 1993.
[63] K. Siau and M. Rossi, "Evaluation of information modeling methods-a review," in System Sciences, 1998.,
Proceedings of the Thirty-First Hawaii International Conference on, 1998, vol. 5: IEEE, pp. 314-322.
[64] M. M. Al-Debei and D. Avison, "Developing a unified framework of the business model concept," European
journal of information systems, vol. 19, no. 3, pp. 359-376, 2010.
[65] J. Iivari, R. Hirschheim, and H. K. Klein, "A dynamic framework for classifying information systems development
methodologies and approaches," Journal of management information systems, vol. 17, no. 3, pp. 179-218,
2000.
[66] F. K. Chan and J. Y. Thong, "Acceptance of agile methodologies: A critical review and conceptual framework,"
Decision support systems, vol. 46, no. 4, pp. 803-814, 2009.
[67] J. Iivari, R. Hirschheim, and H. K. Klein, "A paradigmatic analysis contrasting information systems development
approaches and methodologies," Information systems research, vol. 9, no. 2, pp. 164-193, 1998.
[68] M. A. Colter, "A comparative examination of systems analysis techniques," MIs quarterly, pp. 51-66, 1984.
[69] R. D. Hackathorn and J. Karimi, "A framework for comparing information engineering methods," MIS Quarterly,
pp. 203-220, 1988.
[70] S. Yadav, B, R. Bravoco, R, A. Chatfield, T, and T. Rajkumar, "Comparison of analysis techniques for information
requirement determination," Communications of the ACM, vol. 31, no. 9, pp. 1090-1097, 1988.
[71] N. Kannengießer, S. Lins, T. Dehling, and A. Sunyaev, "What does not fit can be made to fit! Trade-offs in
distributed ledger technology designs," in Proceedings of the 52nd Hawaii international conference on system
sciences, 2019.
[72] C. Walsh and P. O'Reilly, "New kid on the block: a strategic archetypes approach to understanding the
Blockchain," in 2016 International Conference on Information Systems, ICIS 2016, 2016: Association for
Information Systems. AIS Electronic Library (AISeL), p. 6.
[73] K. Conboy, B. Fitzgerald, and Methodology, "Method and developer characteristics for effective agile method
tailoring: A study of XP expert opinion," ACM Transactions on Software Engineering and Methodology (TOSEM),
vol. 20, no. 1, p. 2, 2010.

44
[74] B. Fitzgerald, G. Hartnett, and K. Conboy, "Customising agile methods to software practices at Intel Shannon,"
European Journal of Information Systems, vol. 15, no. 2, pp. 200-213, 2006.
[75] N. Upadhyay, "Demystifying blockchain: A critical analysis of challenges, applications and opportunities,"
International Journal of Information Management, vol. 54, p. 102120, 2020.
[76] B. Fitzgerald, N. Russo, and T. O'Kane, "An empirical study of system development method tailoring in practice,"
ECIS 2000 Proceedings, p. 4, 2000.
[77] B. Henderson-Sellers, J. Ralyté, P. J. Ågerfalk, and M. Rossi, "Situational method engineering," Springer, 2014.
[78] W. H. Glick and G. P. Huber, "Studying changes in organizational design and effectiveness: Retrospective event
histories and periodic assessments," Organization Science, vol. 1, no. 3, pp. 293-312, 1990.