Blockchain and network governance: learning from applications in the supply chain sector

Abstract

Blockchain applications have the potential to greatly improve operational efficiency and effectiveness along the supply chain. Although we know what the barriers to the adoption of blockchain are, we know little about how firms overcome these barriers to reap the benefits of the technology. A particular challenge in adopting blockchain applications is the need to build and implement them among a network of users, requiring firms to collaborate. To manage and advance such collaborative efforts, blockchain projects install a centralised leadership. There is thus a tension between the need for centralised leadership and decentralised control to justify the use of blockchain technology. In this study, we investigate how blockchain projects navigate this tension. We employ a multiple case study methodology to compare five collaborative blockchain applications that are live today. Our findings indicate that the case applications all combine centralised management with decentralised oversight in a similar manner. We argue that this combination of centralised and decentralised control is a great benefit for the successful development and implementation of blockchain applications. The results underline that to benefit from blockchain technology in supply chain applications, an important collaborative organisational effort is necessary.

Keywords:

• Blockchain
• governance
• supply chain
• multiparty IT systems
• case study

Introduction

Today’s supply chains suffer from a reliance on disparate, organisation-specific information environments. Information sharing and coordination are often possible only if one firm is willing to link to the information environment of another, which may require a trustful relationship between the two firms (Baihaqi and Sohal 2013; Fosso Wamba et al. 2015; Saberi et al. 2019). The scaling of this approach to an entire supply network is difficult to imagine. If it were possible to share data across supply networks or even industries without concerns about data privacy and validity, the benefits for operational efficiency and effectiveness would be immense.

Blockchain technology may be the foundation to put into practice such industry-wide data-sharing ideas (Helo and Hao 2019; Wang et al. 2019). As an immutable distributed ledger, blockchain offers a pathway towards trusted data in environments where network members do not inherently trust each other (Kumar, Liu, and Shan 2020). Several areas of application have been proposed in a supply chain context to improve operational efficiency and effectiveness (Kshetri 2018; Schmidt and Wagner 2019). They primarily revolve around supply chain transparency and digitisation, including tracing and tracking products, automation, and supply chain finance (Durach et al. 2021; Gurtu and Johny 2019; Hastig, Mohan, and Sodhi 2020; Saberi et al. 2019).

The promised benefits of blockchains may look attractive on paper (Fosso Wamba et al. 2020). However, building and implementing a functioning application is an entirely different story. Over the past couple of years, many blockchain projects have failed, and few have become operational (Babich and Hilary 2020; Disparte 2019; van Niekerk 2020). It is therefore important to understand how such applications are developed and implemented successfully (Cole, Stevenson, and Aitken 2019). This constitutes an important gap in the literature, as little research has specifically investigated the steps necessary to develop and implement a blockchain application on live examples (Fosso Wamba and Queiroz 2022; Hennelly et al. 2020).

With this study, we focus on one key aspect of implementing a blockchain application: the inherent need for a network of multiple entities. Blockchain is meaningful only when implemented as a multiparty system (Babich and Hilary 2020; Kumar, Liu, and Shan 2020). In the supply chain context, many current blockchain projects are consortia, co-owned by multiple firms (Kouhizadeh, Zhu, and Sarkis 2020). A recent example is the Global Shipping Business Network (GSBN). Nine ocean carriers and port operators are joining forces to develop and implement a platform that uses blockchain to standardise and digitise data exchange among stakeholders along the supply chain. GSBN is a non-profit organisation owned by the nine participating firms (The Maritime Executive 2020). The logistics technology specialist CargoSmart serves as a technology provider and operator of the platform (CargoSmart 2019). As this example shows, several firms, including competitors, collaborate. Together, they create a new organisation with the purpose of advancing the development of their blockchain application and establishing a network governance to specify decision-making structures, rules to enforce them, and ways to verify their enforcement (Babich and Hilary 2020). We observe that a technology, which supposedly is a driver of decentralisation and disintermediation (Catalini and Gans 2016; Tönnissen and Teuteberg 2020), leads firms to create new organisations – a seeming contradiction. We argue that it is important to address such a contradiction to clarify if and how firms can realise the potential of blockchain technology as a driver of decentralisation and disintermediation. To make a first contribution in this regard, we ask the following research questions:

RQ1: How do firms organise to jointly develop and implement blockchain applications in a supply chain context?

RQ2: What role does network governance play in supporting the development and implementation of blockchain applications?

To answer these research questions, we study five cases of blockchain applications. The developed applications are now live – at least locally. All of them are being developed in a collaborative effort of multiple firms; they all are or resemble ‘blockchain consortia’. The five case applications aim to improve operational efficiency and effectiveness in the fields of product tracking and tracing, trade finance, and supplier management. Data on the development of blockchain applications is scarce because it is a novel phenomenon. For this reason and because our research interest revolves around a multifaceted phenomenon, we opt for a qualitative methodology (Eisenhardt 1989). We collected data through semi-structured interviews.

Our analysis provides insights into how firms organise the adoption of blockchain in a supply chain context. A dedicated organisation leads the development and implementation of the blockchain application, which is jointly controlled by several member firms. This setup combines centralised with shared control. A centralised management team coordinates member involvement, resolves conflicts, and builds consensus. The member firms share control by sending representatives to decision-making bodies, such as boards and general assemblies, and by engaging in working groups and trials. This collaborative approach to application development has several advantages over both centralised and decentralised approaches to application development. First, the management team provides target-oriented leadership and takes an important role in marketing the application. Second, the sharing of control among member firms makes an application more attractive for firms to join, as dependency concerns are mitigated. Third, the application benefits from the combined funding, expertise, and aggregated market power that comes with the involvement of many stakeholders.

With this study, we contribute to the emerging research on applications of blockchain technology in a B2B setting and, more specifically, in a supply chain context. We are among the first to investigate how firms organise to collaboratively develop and operate a blockchain application. We provide a contrasting perspective to the research on the potential benefits of the technology by describing the important organisational effort that is necessary to build applications of the technology in the first place. Member firms’ engagement is intensive; trustful relationships develop. Blockchain is, therefore, not a technology that reduces the need for central administration and that functions in a trust-free environment. At least in the application development phase, it seems to be quite the opposite. New organisations are founded and intensive one-on-one engagement among a multitude of stakeholders is necessary to develop valuable applications of the technology.

The paper is structured as follows. In the background section, we offer an overview of the relevant research on blockchain technology, specifically, and multiparty information systems, more generally. In the methodology and results sections, we describe our case study methodology and the results of our analyses. We close the paper with a discussion on our contributions and the limitations of the study.

Background

We approach the phenomenon of interest from two sides. We begin with the relevant literature on blockchain technology. We then draw a connection to research on the governance of inter-organisational systems. We conclude the section with a discussion of blockchain governance.

Blockchain technology

Blockchain is a form of distributed ledger of transaction records (Pilkington 2016). The data stored on the ledger exists across multiple nodes in multiple locations instead of being stored at one central location (Hastig, Mohan, and Sodhi 2020). Control is shared among multiple independent parties without the need for a central authority (Lumineau, Wang, and Schilke 2021). Data entry onto the blockchain is consensus-based, and the data on the blockchain are quasi-immutable (Nakamoto 2008). Through public-private key cryptography, data can only be decrypted by the target recipient, ensuring privacy (Pilkington 2016). These features of blockchain technology enable direct peer-to-peer exchange, even in the absence of a trustful relationship between the exchange partners. Without blockchain, such exchanges require an intermediary, which often accumulates important market power (Catalini and Gans 2016). Blockchain also promises to drive automation by means of smart contracts (Buterin 2014; Kshetri 2018). For a more detailed description of the technology and how it can be used in a supply chain context, we refer to Babich and Hilary (2020) and Kumar, Liu, and Shan (2020).

Some scholars argue that this technology will have a profound impact on how firms interact, suggesting that established management theories may have to be reconsidered with regard to buyer-supplier relationships (Roeck, Sternberg, and Hofmann 2020; Saberi et al. 2019; Schmidt and Wagner 2019; Wang et al. 2019). Despite the apparent benefits and the potential to bring radical change, the impact of the technology on real-world processes has been limited (Sternberg, Hofmann, and Roeck 2021). The successful implementation of blockchain turns out to be difficult. The research on the barriers to blockchain adoption has started to address the reasons for firms’ struggles to adopt the technology (Kurpjuweit et al. 2021; Orji et al. 2020; Saberi et al. 2019; Sternberg, Hofmann, and Roeck 2021; van Hoek 2019). Multiple barriers relate to the topic of our study; relational governance (Kurpjuweit et al. 2021), problems with collaboration or lack thereof (Lohmer and Lasch 2020; Saberi et al. 2019), a complex setup and a large number of involved stakeholders (Kurpjuweit et al. 2021; Lohmer and Lasch 2020; van Hoek 2019). However, none of them explicitly discuss the organisation and governance necessary to enable the coordination among stakeholders.

A key influencing factor on how the technology is implemented and a major barrier to its adoption is the scope of the network of adopters. The network effects of blockchain are so strong that the development of applications rather takes place on an industry level, not on a firm level (Kumar, Liu, and Shan 2020). Even on the industry level, interoperability concerns would pose an obstacle to adoption, let alone on the firm level. Hence, the barriers to adoption may resemble those of other general purpose technologies, such as the internet (Catalini and Gans 2016), and not so much those of enterprise IT solutions, such as Electronic Data Interchange (EDI) (Lumineau, Wang, and Schilke 2021).

Organisation and governance of multiparty information systems

With the inherent need for a network of multiple parties, blockchain technology provides the foundation for a multiparty information system (Kumar, Liu, and Shan 2020). To study the organisation and governance of blockchain applications, it is therefore worthwhile to consult research on the organisation and governance of such multiparty systems. They involve a network of firms that ‘work together to achieve not only their own goals but also a collective goal’ (Provan and Kenis 2008). The collaboration among firms allows resources to be used more efficiently; it promotes learning, product quality, competitiveness, and the capacity to address complex problems (Brass et al. 2004; Provan and Kenis 2008). To ensure collective and mutually supportive action, multiparty information systems need a governance. It must specify the institutions involved in and the structure of the governing body as well as the distribution of the decision rights, the decision procedure, and the accountability framework (Provan and Kenis 2008; Ross and Weill 2004).

For multiparty networks, governance can be designed to be anywhere between entirely decentralised and fully centralised (Provan, Fish, and Sydow 2007; Provan and Kenis 2008). In the former case, all member firms jointly govern the network without the need for a centralised broker organisation. In the latter case, a single member firm governs the network in a centralised manner. Decentralisation is important to enhance member commitment. The more intensively member firms can participate and the more symmetrical the power distribution is, the more they commit to the goals of the network (Provan and Kenis 2008). This comes at the cost of relatively inefficient decision-making and engagement of member firms. In contrast, centralising decision-making powers at a lead organisation enhances administrative efficiency (Chen, Pereira, and Patel 2021; Provan and Kenis 2008). A lead organisation also adds stability. It is, however, in a position to misuse its position of power; a threat that deters others from collaborating (Chen, Pereira, and Patel 2021; Markus and Bui 2012).

In choosing a governance form, the members of a multiparty information system must strike a balance between the benefits of more centralised leadership and the benefits of more shared control (Chen, Pereira, and Patel 2021; Provan and Kenis 2008; Tilson, Lyytinen, and Sørensen 2010). To reap the benefits of both, an intermediate degree of centralisation can be selected. The network can be governed by a dedicated organisation that is set up with the sole purpose of doing exactly that. This organisation, not a member firm by itself, is called a network administrative organisation (NAO) (Provan and Kenis 2008). Oversight of NAOs is commonly ensured with a board that includes all or some of the member firms. Having laid out the role of centralisation and decentralisation in the governance of multiparty information systems, we now apply these concepts to blockchain applications.

Network governance of blockchain applications

The tension between centralised and decentralised network governance matters for blockchain applications (Chen, Pereira, and Patel 2021). On the one hand, blockchain is a force for decentralisation. It creates conditions in which the actions of independent agents cohere without any need for centralised leadership (Benkler 2006; Lumineau, Wang, and Schilke 2021; Pilkington 2016). Decentralised governance would, therefore, fit well the core idea of blockchain. On the other hand, the development and implementation of a blockchain application may benefit from a target-oriented and efficient management, supporting the case for more centralised governance forms (Chen, Pereira, and Patel 2021). The different approaches to network governance of multiparty systems, introduced in Section ‘Organisation and governance of multiparty information systems’, may serve to structure different approaches to network governance of blockchain applications, as shown in Table 1.

Table 1. Network governance of blockchain applications.

	Centralised	NAO-approach	Decentralised
Lead organisation	Yes	Broker	No
Description	A lead organisation owns and controls the application. Governance is centralised (Provan and Kenis 2008)	NAO (either for-profit or non-for-profit organisation) is tasked with the governance of the network. It is distinct from members (Chen, Pereira, and Patel 2021; Provan and Kenis 2008)	Governance is fully decentralised. Example in blockchain-space: Decentralised Autonomous Organisations (DAO) (Lumineau, Wang, and Schilke 2021; Ziolkowski, Miscione, and Schwabe 2020)
Blockchain example	Other technologies may be better suited (Furlonger and Uzureau 2019)	GSBN (The Maritime Executive 2020)	Bitcoin (Nakamoto 2008)
Strengths	Efficient decision-making, stability (Provan and Kenis 2008)	Scalability of network size, inclusiveness (Provan and Kenis 2008)	Inclusiveness, internal legitimacy (Provan and Kenis 2008)
Weaknesses	Members are dependent on lead organisation	Resource-intensiveness	Inefficient decision-making, inefficient member engagement

Although conceivable, whether a fully centralised governance is meaningful in connection with blockchains remains to be seen in the future. If a single entity controls a blockchain, other technologies may provide better alternatives, as they achieve the same at lower costs (Furlonger & Uzureau, 2019; Kumar, Liu, and Shan 2020). Such alternatives are readily available; for instance, data sharing through an intermediary, centralised storage, and EDI (Babich and Hilary 2020). In line with the notion that centralised governance is maladapted for blockchain applications, Ziolkowski, Miscione, and Schwabe (2020) propose to either use the decentralised or the brokered (NAO) approaches. For cryptocurrencies, Chen, Pereira, and Patel (2021) find a U-shaped relationship between the degree of decentralisation of platform governance and market performance, making a case for an intermediate degree of centralisation. While the fully decentralised approach is well-represented in applications, such as Bitcoin (Nakamoto, 2008), for enterprise blockchain projects, the NAO-approach seems more common.

Methodology and case description

Blockchain applications are a novel phenomenon without much research and data available. We, therefore, choose a multiple case study approach (Barratt, Choi, and Li 2011; Ketokivi and Choi 2014). Case studies enable context-rich observations in real-life scenarios (Eisenhardt and Graebner 2007), yielding deep insights into multifaceted phenomena, such as the organisation of blockchain application development.

Research design

We follow the case study design outlined by Eisenhardt (1989). To be selected as one of our cases, the application must fulfil the following criteria: (1) it must make use of blockchain technology, (2) it must be live, (3) it must be owned by more than one firm and involve multiple adopters, (4) it must be aimed at increasing operational excellence along the supply chain. All of our case applications are being managed by organisations founded specifically for that purpose. These organisations are or resemble a consortium and are often called that. Not all of them legally are consortia. We will, therefore, refrain from using that term to describe the organisational form of the study cases. We focus on the supply chain sector, which is relevant to study blockchain applications for two reasons. First, there is great potential for increased operational efficiency and effectiveness along supply chains, which blockchains may tap into. Second, processes along supply chains naturally involve multiple firms. This leads to such multiparty projects being created out of necessity.

The population of all blockchain applications that meet our three criteria is still small. To ensure that the cases are information-rich, we adopted an intensity sampling approach (Patton 2014). Our approach to identifying possible blockchain applications to study was iterative. Starting from a small set of well-known projects, we researched websites renowned in the supply chain sector and news sites that report on blockchain-related topics. Over the course of conducting the first interviews, we were able to add projects through input from informants. We aimed to include a broad variety of different blockchain applications in our study while maintaining comparability among cases. We guaranteed confidentiality and pseudonymity to our participants.

Potential informants can be clustered into three categories: (1) employed directly by the organisation that manages the application (NAO); (2) employed by one of the member firms; (3) independent experts involved in the case (e.g. journalists, industry experts, scholars). To gain a varied perspective on the applications, we included informants from more than one category per case. Table 2 provides an overview of informants by case.

Table 2. Overview of informants per case.

Study case	Informant role	Affiliated with organisation	Interview duration^a
Appl-1	Executive	NAO	0:57
	Executive	NAO	0:58
	Advisor	NAO	0:49
	Project manager	Technology provider	0:37
Appl-2	Executive	NAO	0:55
	Product manager	Member firm	0:59
	R&D manager	Member firm	0:28
	Senior reporter	Specialist publication	0:52
Appl-3	Executive	NAO	1:04
	Business development manager	Technology partner	0:53
Appl-4	Analyst	NAO	1:04
	Executive	NAO	0:33
	Executive	NAO	0:27
Appl-5	Product manager	NAO	1:12
	Technology specialist	NAO	0:54
	Executive	Member firm	0:56
	Engineer	University	0:51
	Senior editor	Specialist publication	0:53
Pre-study	Managing consultant	Management consultancy	0:51
Pre-study	Professor	University	0:43
Pre-study	Product Manager	Logistics company	1:01
Pre-study	Managing consultant	Blockchain consultancy	0:40
Pre-study	Executive	Blockchain start-up	0:53

^aThe interview duration is measured in hours:minutes.

To collect data through semi-structured interviews, we prepared an interview guide (Appendix A.6), which served as an orientation during the interviews regarding both lines of questioning and time. This ensured the coverage of all important topics while leaving room to dive more deeply into specific topics when they arose during the conversation (Eisenhardt 1989). The guide covered four overarching topics: (1) the informant’s background and involvement with the blockchain application; (2) general information about the application, such as goals, members, and technical properties; (3) the organisation, governance, and operation of the application; and (4) further questions on informants’ opinions regarding the future development of the application.

Data collection

We conducted a first round of data collection in 2018. At that time, blockchain projects had not developed enough for their organisation and governance to be studied. As a result of the prematurity of the phenomenon of interest, we used the first round of five interviews as a pre-study to inform the latter, major data collection for the main study.

We adopted a parallel approach with data collection and analysis overlapping, collecting data from spring to summer 2020. After a first phase of pure data collection, we then started analysing interview transcripts while still conducting additional interviews. As part of the main data collection effort, we conducted 18 interviews across five distinct case applications (see Table 2). We prepared documents and conducted interviews with an English-first approach. All informants agreed to using English as interview language, as English is the spoken language among all cases. We conducted all interviews remotely. The Covid-19 pandemic precluded the possibility of in-person interviews. We used Zoom, Microsoft Teams and phone calls, depending on the informants’ preferences and their companies’ IT guidelines.

We recorded and transcribed the interviews and compared transcripts and audio files to correct spelling mistakes, remove duplicated words, and modified sentence structures where necessary. Handwritten notes complement the transcripts. While not subject of in-depth analysis, they were helpful during the interview process. We also collected data from openly available information about the cases to ensure consistency. This provided additional information on general aspects of the cases, not for organisation-related topics, which were seldom disclosed.

Data analysis

We conducted two rounds of coding with two coders working independently of each other. The focus of the first round lay on descriptive codes (Saldaña 2015). The first goal was to understand the purpose of the applications, as well as ownership, membership, and user networks. Based on the literature on governance of multiparty information systems, we aimed to understand the governance of the blockchain applications. This mirrors the first research question. The second round of coding was more inductive than the first, as we intended to inform our codes from the data (Patton 2014). The focus shifted to understanding the relationship between organisation and governance, and the adoption of blockchain, using thematic codes. Table 3 provides examples of codes from the second round of coding. To answer the second research question, we focussed on understanding the role of centralisation and decentralisation in organising blockchain adoption, and on how the organisation and governance of blockchain applications change during the adoption process. We used MAXQDA for interview coding.

Table 3. Coding strategy.

Code	Case	Example quote
Decentralisation	Appl-1	So the Walmart, the FoodTrust one is an easy one because you design a blockchain network and you tell your suppliers to connect and […] your work is done. But it is not a collaboration. What we are doing is through collaborations. So I need to convince everybody to work together in this infrastructure. [Executive]
Decentralisation	Appl-2	No there is a difference. Those members who have a board seat have the biggest say. […] Those organisations who are shareholders but do not have a board seat, obviously, have lesser say. And then those who are licensees only, they are licensees only. [Executive]
Decentralisation	Appl-4	And then, obviously, […] it is a shared solution […]. It is not a siloed solution; blockchain is never one. [Analyst]
Decentralisation	Appl-5	I mean, you have got a network of different participants - blockchain does not make any sense if you make just blockchain for yourself - so it is a decentralised system. [Engineer at University]
Transformation	Appl-1	And of course, of course, I imagine - now it is a cosy club of nine or something. But when we have an audience of 100 in specific areas, we have to rearrange this stuff. [Executive]
Transformation	Appl-2	[It was] set up as a standalone entity in 2018. Now, this is something that we are seeing a lot with a lot of the other consortia, you know: they start out just being a consortium and then, because they need to have that kind of governance structure and the ability to take decisions by CEO and not by committee, they are setting up a standalone legal entity. [Senior reporter at specialist publication]
Transformation	Appl-3	So, at the beginning, when we founded the association a year ago, we were the sole master on board. And little by little, and that started with the first general assembly of the association, we started letting go some of power to the [member firms]. [Executive]
Transformation	Appl-5	[T]o my understanding […] they gave the other carriers both […] power over governance and also some sort of revenue, ability to drive revenue as well. So it wasn’t just [shareholder 1] setting the rules and [shareholder 1] purely monetising this and other companies sort of having to be involved. […] And then once [the other carriers] were involved, it naturally was seen as less of a purely [shareholder 1]-driven initiative. [Senior editor at specialist publication]

Validity and reliability of case studies are common concerns of both case study researchers and the research community at large (Gibbert, Ruigrok, and Wicki 2008). In the following, we briefly describe the measures we took to increase both the validity and reliability of our research. To ensure a comprehensible and neutral interview guide, we iterated it multiple times among authors and obtained feedback from peer researchers. In the interview guide, the term ‘governance’ appears several times. We expected different informants to understand the term in different ways. In the interviews, we established a common understanding by first letting the informants explain their understanding of the term and then finding a common base in a brief discussion. We ensure a transparent process from data collection to the findings, through detailed case reports and extensive documentation for each of the cases. The descriptive case reports informed the second round of coding. We triangulated the statements from different informants of the same case.

Case description

In this section, we introduce the five multiparty blockchain applications in the supply chain sector that we study. They are all, at least locally, live at the time of writing. We first introduce each case. Table 4 provides an overview. The more detailed case descriptions are shown in Appendices A1–A5.

Table 4. Overview of cases.

Name	Application	Members	Ownership	Blockchain type
Appl-1	Track and trace in finished vehicle logistics	<10: logistics providers  and bank	<10 logistics providers	Permissioned
Appl-2	Trade finance	10–20: banks and  technology provider	>10 banks	Permissioned
Appl-3	Digital identity for luxury goods	>20: luxury brands and  technology provider	Member firms hold tokens and no financial stakes	Permissionless
Appl-4	Supplier information management	>20: firms from  various industries	Blockchain consultancy and technology provider	Permissioned
Appl-5	Global shipping platform	>100: logistics companies,  service providers,  terminals, customs  authorities	Logistics company and technology provider	Permissioned

Appl-1. Operated by a group of logistics providers, Appl-1 provides transparency on the location and status of finished vehicle shipments, as well as load capacity management to optimise the utilisation of logistics fleets. It addresses the lack of holistic, real-time information along the supply chain of finished vehicles due to siloed, paper-based processes and a low degree of digitisation of logistics service providers in the space.

Appl-2. Appl-2 offers supply chain finance solutions for SMEs and is operated by a group of banks. Trade finance as an industry remains paper-based to a large extent, meaning that information is siloed and processes are inefficient. Digital and standardised trade execution would contribute to efficiency gains. Banks integrate the application into their own trade finance products that they sell to their customers.

Appl-3. This application helps to create digital identities of products on the blockchain for the luxury fashion industry. Such digital identities offer proof of authenticity and proof of ownership. In addition, a record of item-specific events, such as sales or repairs, can be kept. Member firms can both use these functionalities for internal process improvements, as well as integrate them into their products. Appl-3 was founded and is still managed by a group of entrepreneurs.

Appl-4. Appl-4 develops a supplier information management tool that improves supplier selection, validation, onboarding and lifecycle management. Although it is owned by a technology provider and a blockchain consultancy, a wide range of firms from industries, such as electronics, fast-moving consumer goods, pharma, and telecom, are involved in developing the application. Suppliers make the documents and information required for standard onboarding processes available on the platform offering buyers a central database to navigate the supplier space. Third-party providers offer services on the platform, such as auditing and validation.

Appl-5. Owned by a logistics company and a technology provider, this application aims to address multiple inefficiencies along the information flows of the global shipping industry that suffers from siloed information ecosystems. Appl-5 offers a platform for document sharing. This platform helps digitise work processes that are currently paper-based and lay the basis for automation of repetitive tasks. In addition, having all parties engaged in the shipping of goods coordinate on the same platform helps speed up processes and reduce errors (e.g. at customs).

Results

In this section, we examine the evidence that the five cases of blockchain applications jointly provide to address our research objectives; understand the organisation and governance of collaborative blockchain projects and how they aid the adoption of the technology.

Organisation and governance of blockchain applications

The five cases have similar organisational structures (Table 5). The centrepiece is a standalone organisation that was founded for the purpose of developing and operating the blockchain application. This organisation takes the role of a network administrative organisation (NAO, see Table 1) (Provan and Kenis 2008), and we will call it that throughout this section. The NAO is led by a management team, which can be made up of founding individuals, dedicated hires, or be staffed with representatives from the shareholders. An NAO may be made up of just a management team or have dozens of employees. Additionally, all NAOs have some sort of governance bodies with oversight and decision-making responsibilities – in most cases, a board and a general assembly. These bodies provide the formal ways for the involvement of member firms. As Table 5 shows, different factors determine whether firms qualify for a board seat. Working groups provide the format for representatives of member firms to jointly develop features of the strategy or the application itself.

Table 5. Organisational structure of cases.

Name	Management team	Board	General assembly	Working groups
Appl-1	Team of industry experts. Responsible for operations and coordination between members	Board and general assembly are the same. Executives of member firms and Appl-1 management team. Responsible for strategic decisions and product roadmap		Established working groups with experts from member firms
Appl-2	Team of industry experts. Responsible for operations and coordination between members	Executives from large shareholders and Appl-2 management team. Responsible for strategic decisions	Representatives from all member firms. Informal extension to board	Established working groups with experts from member firms
Appl-3	Team of founding individuals. Responsible for application development and operations	Reserved seats for big industry players; additional members elected by assembly. Currently, little responsibilities	Representatives from all member firms and technology partners. Input on application development; elects board members	Established working groups with experts from member firms
Appl-4	Dedicated team from major shareholding blockchain consultancy. Responsible for operations, business development, and coordination between members	Executives from 10 ‘industry leaders’ from different industries. Responsible for strategic decisions	Representatives from all member firms. Coordinates working groups	Established working groups with experts from member firms
Appl-5	Large dedicated organisation associated with the two major shareholders. Responsible for operations, business development, and coordination between members	Two bodies to be instituted: One is an association encompassing major competitors in one value chain echelon. The other is a board with representatives from a cross-section of member firms	–	Working groups not established

In all cases, the member firms not only have formal, but also informal channels available to engage with the NAO. In informal meetings, member firms interact one-on-one with representatives of the NAO and its management team. The exchanges between member firms and the NAO can be frequent and close.

So, I got a handful of relations at [Appl-2]. I simply give [them] a call and say, ‘has anyone considered this?’ […] I think the way how I apply it is informal, and I think there is a formal way as well. [Product Manager at member firm, Appl-2]

[I]t’s more now a one-to-one connection between project manager and ourselves to really discuss additional features […]. [Business development manager at technology partner, Appl-3]

While the organisational structures may resemble each other among cases, the ownership structures differ (see Table 4). Appl-1 and Appl-2 are owned by a rather large group of founding firms. There are no or few member firms that are not co-owners. The owners of Appl-1 and Appl-2 are mostly firms from one echelon of the entire value chain. They integrate the application into the products they sell to their customers.

The customers are not paying anything. [Appl-2] is a platform, from their point of view. They don’t have to bother whether there is a specific company or a joint venture company, or if it’s owned to equal parts by the [member firms]. [R&D manager at member firm, Appl-2]

In contrast, majorities of Appl-4 and Appl-5 are owned by a pair of firms only, of which one is the technology provider. There is a large number of non-shareholding member firms. Member firms integrate the application in their own business processes and may or may not incorporate them into products they sell. The number of members far exceeds the number of owners. Among the cases, Appl-3 is the only one that was financed through an initial coin offering (ICO) and uses tokens. A traditional shareholder structure does not exist.

Tied with the ownership structure is the monetisation strategy. Fundamentally, three types of beneficiaries seem to be distinguishable. Any firm that builds a functionality for the platform and offers it to be used by others can monetise that usage.

What’s also unique about the solution is the integrated marketplace, apps that we have. [A]ll of this information that is provided by the suppliers […] will need to be verified and tested […] by third-party verifiers […]. So, [Appl-4] provides a seamless integration with all of these third-party verifiers. [Analyst, Appl-4]

In addition, member firms pay a membership fee for access to the application’s functionalities. They benefit inasmuch as the application may help improve operational efficiency and effectiveness. Alternatively, should the application be integrated into their products, member firms benefit from an improved value proposition to their customers. Finally, owners of the applications may realise a wider range of benefits. We did not gain a clear picture from the data of how owners would monetise their status in the long term. After all, these blockchain applications still require large investments without generating much revenue.

All of the cases show how firms that are willing to engage with this novel technology invest in organising and governing the collaborative effort to develop a valuable application. Developing an application collaboratively among a larger group of firms instead of independently within or among a small group of firms comes with important benefits. If different firms, competitors in particular, join forces, they aggregate market power. This makes it more likely that their application will prevail to achieve critical mass.

[A lot of companies] put a team together to investigate different blockchain technologies, put their head around it and try to figure out, ‘Okay, how could you possibly leverage this?’ The problem is, if they go too far, they start developing some kind of solution, then they are completely isolated, then they’re like, ‘Okay, how do we actually scale up to bring other people in?’ [Technology specialist, Appl-5]

The involvement of a multitude of industry players aggregates expertise. Each member brings in perspectives from another home market, experiences with a different set of customers and regulatory environments. A technology provider may suffice to contribute the necessary technological expertise. To build an application that caters to the needs of a broad base of firms from different value chain echelons, business expertise is at least as important.

Why I joined this consortium. It’s because I think that I’ve seen many blockchain projects. And most of them are initiated from a tech side. And tech people don’t know how to sell a platform. They […] build it from a technology point of view and not from a perspective of how to use it. [Advisor, Appl-1]

Impact of network governance on blockchain adoption

In this section, we examine how the cases’ network governance aids technology adoption. In reference to Table 1, all of our cases follow the NAO-approach, using an NAO for network governance. Below, we will introduce two benefits this approach holds over the two alternative approaches to organise blockchain adoption.

A first major feature is shared control, distinguishing the network governance of the cases we study from a centralised lead organisation governance. Sharing control entails that no single firm can easily influence application development in its favour. Could one single or few firms do this, other firms would be reluctant to join due to a fear of competitive disadvantages and out of dependency concerns. Shared control is a major selling point to prospective new members. The opportunity to steer the development of the application as a group is a safeguard against opportunistic behaviour by a few. With the credible promise to take into account different member firms’ specific needs in application development, new member firms are easier to attract. The network may grow and the application may become the front-runner in a race for network size.

[W]e’re trying to […] change processes and procedures that have been predominantly paper-based for tens or hundreds of years. And to do that, you need to have a common methodology in order to make it work. And hence, it requires everybody to be on the same page. So, one organisation can’t do it themselves because you need to get the collective buy-in to do it in a particular way. That’s why the consortium model is being adopted. [Executive, Appl-2]

With large-scale adoption of blockchain applications, interoperability concerns are reduced. The aspiration to become the leading application within at least an industry is common among cases – and an important marketing tool. Achieving the standard as a joint effort makes an application attractive for more firms to join.

And then regardless of if in the future it is blockchain […], a cloud database, or whatever it is, we will at least have standardized this and made this into something that can be technology agnostic. [Senior reporter at specialist publication, Appl-2]

So we need to get to production, […]. It’s another two years of building the whole infrastructure. I think once it’s there, we have the more or less monopoly position in the market, which we aim to get, be the winner that everybody flocks to. [Executive, Appl-1]

Several informants (Appl-1, -3, -5) voiced their concerns that a platform provider from outside the industry (e.g. Amazon, Uber, Google, etc.) could build their own application and, thereby, threaten the business models of incumbents. They might not make use of blockchain technology, opting for a centralised solution instead (Chen, Pereira, and Patel 2021). The attempt to develop a blockchain application collaboratively is intended to pre-empt such threats.

[Selling the application] to Amazon or Alibaba […] or Google is [the member firms’] biggest fear. And they’ve already spent the last decade being subjects of those big platforms. And when you tell them, ‘Hey, we have a solution, we’re trying to build something that will free you of the shackles of Amazon and Google and Facebook’, they're extremely interested and fascinated. [Executive, Appl-3]

A second important benefit of the cases’ approach to network governance, is that it allows for some centralised decision-making. Unlike the aspect of shared control, which distinguishes the cases’ network governance from more centralised approaches, the aspect of centralised decision-making distinguishes it from a fully decentralised approach (see Table 1). All cases have an NAO that is led by a management team. A major task of the NAO is marketing and network growth.

[The] CEO and marketing [of the NAO] are really focusing on developing the consortium, at which they do a great work. [Business development manager at technology partner, Appl-3]

Internally, the management team is the coordinating force among involved stakeholders, facilitating the communication with and between members, building consensus, and driving a target-oriented development of the application. Members of that team build relationships with representatives from member firms to build the trust needed to push collaborative application development forward.

I would say the social talk within the consortium is as important as the governance structure because, basically, governance structures are just about ‘okay, did you check the boxes, and is everybody behaving accordingly? […]’ But this inter-human relationship […], this is the main thing. And especially when you have competitors in the room, it’s trust. Well, you can only get trust in the blockchain if you have trust in your consortium. [Executive, Appl-1]

In summary, the cases provide examples of how firms collaboratively develop blockchain applications in a multiparty context that suits the collective needs of many stakeholders. They benefit from aggregated market power, shared expertise and capital. Shared control, which mirrors blockchain’s technical requirement of decentralised control over the validation of entries, is an important safeguard against opportunistic behaviour of those in control. It legitimises an application’s claim to an industry standard. Finally, a management team exerts some centralised control to coordinate between member firms and drive forward application development in a targeted manner.

Navigating the conflict between centralisation and decentralisation

Above, we argue that the cases’ approach to network governance combines the strengths of shared and centralised control. These two features may clash. In this section, we describe how the cases handle such conflicts by adapting their network governance.

We observe that the applications’ network governance, particularly the degrees of centralisation, do not remain stable over time. It seems that the initial approach to network governance does not necessarily cater to the needs of the applications later in their development and implementation. There are two directions of shifts in the degree of centralisation among the cases: from a decentralised beginning towards more centralisation of control, and from a centralised beginning towards more decentralisation of control. Table 6 provides an overview of the two directions of shifts that we observe.

Table 6. Observed shifts in the degrees of centralisation.

Direction 1: towards centralisation
Appl-1	Initially, group of firms sharing control. Since, creation of an NAO and formalised governance	[N]ow it’s a cosy club of nine or something. But when we have an audience of 100 in specific areas, we have to rearrange this stuff. […] Then you have members and members; basically people just participating in the network transacting and doing nothing, but just using it. [Executive, Appl-1]
Appl-2	Initially, group of firms sharing control. Since, strengthening of the management team and decrease of the involvement of member firms	How this has evolved is that the [Appl-2] organisation […] has taken a more firm grip […]. I really welcome that I don’t need to have a say in all questions. […] So, the [Appl-2] organisation as of today is much more effective and efficient compared to just one or two years ago. [Product manager at member firm, Appl-2]
Direction 2: towards decentralisation
Appl-3	Initially, centralised governance by a group of entrepreneur founders. In a step-by-step process, the founders relinquish their decision-making monopoly to the member firms	[A]t the beginning, when we founded the association a year ago, we were the sole master on board. And little by little – and that started with the first general assembly of the association – we started letting go some of power to the [member firms]. [Executive, Appl-3]
Appl-5	Initially, powerful NAO to push for fast network growth, which it accomplished. In order to get competitors of the main owner on board, there has been a recent move towards decentralising control somewhat	For the [firms], we have a consortium, […]. It’s kind of a bigger group of all different big [firms] within this industry. […] I think we have all top seven worldwide [firms] which will be onboarded within this group, within this association. [Product manager, Appl-5]

Among the cases, in all but Appl-4, there is evidence of shifts towards more centralised or more decentralised control. Appl-1 and Appl-2, which both started out in a decentralised manner, are shifting more responsibilities to the NAO. Appl-3 and Appl-5, which were founded with a strong centralised team, are moving towards a more decentralised structure by ceasing some control to the larger member base. There is indication of a trend towards a more similar distribution of control among cases – despite different ownership structures and starting points. Blockchain projects that start out decentralised (Appl-1, -2) face the challenge of scaling up the organisation, while keeping the benefits of decentralisation. To make decision-making more efficient, central management is strengthened. In addition, with network growth, distinguishing different membership tiers becomes necessary, with some members having more power than others. In contrast, blockchain projects that start out centralised (Appl-3, -5) face the challenge of recruiting new members and securing member buy-in. Fears of dependency on the organisations in control make potential members reluctant to join. In addition, stakeholder buy-in is a concern if member firms are only marginally involved in application development.

Discussion

Implications for research

With this study, we aim to shed light on how firms jointly organise the development and adoption of a technology application for the supply network and the wider industry context. It helps us go beyond the barriers and enablers to the digitisation of supply chains (Gupta et al. 2021; Orji et al. 2020; Saberi et al. 2019) and study real-life examples of how firms collaboratively overcome some of these barriers, which has been called for (Hennelly et al. 2020). We study five blockchain applications, all of which promise more effective and efficient operations in industries that operate in information siloes or lag behind in digitisation. Although none of the applications have reached widespread adoption yet, all of them are currently at least locally live at some member firms.

The approach to network governance we described as part of the analysis resembles what Provan and Kenis (2008) call ‘network administration organisations’ (NAO). It combines a centralised organisation, dedicated to furthering the member firms’ common cause, and decentralised oversight and decision-making bodies that ensure member firm involvement. The governance form of the case applications thus combines aspects of centralisation and decentralisation. We argue that both, more centralised and more decentralised approaches to organising the development and implementation of blockchain applications may not be as appropriate for such a task. More centralised approaches may put member firms in a position of dependency with regard to the lead organisation. In addition, a lead organisation may struggle to incorporate sufficiently broad industry knowledge to build applications that cater to the needs of a varied user base. In contrast, in fully decentralised approaches to building blockchain applications, decision-making becomes inefficient with a growing number of participants.

We motivated this study with the observation that adopting a technology that is associated with disintermediation and decentralisation leads firms to create new organisations with a centralised management, trust-based relationships, and large-scale collaboration – a seeming contradiction. The case analysis shows why collaboration among large numbers of firms and the creation of new organisations for network governance may be key to adopting blockchain technology. In order to realise the important benefits blockchain may bring, it seems necessary to build applications for entire industries from the onset. The technical and business aspects of an application must be developed in sync. Some form of centralised control may be necessary to achieve that. This is in line with previous research on cryptocurrencies, promoting organisational forms that incorporate both broad participation among members and some centralised leadership (Chen, Pereira, and Patel 2021). The following quote illustrates our argument:

[W]e have this new technology, it’s got some interesting features, there’s plenty of applications we can imagine doing with this. And now the question is, how do you actually make it happen? And that’s where the governance of those consortia comes into play. And without it, it just doesn’t work. You know, you can be at the business level and see a vision on how you could leverage that technology, can have all the technology with all the goodies, all the features you can possibly imagine. But if you don’t have that glue in between on how to build the network and run it successfully, you’re screwed. [Technology specialist, Appl-5]

Among our cases, we observe that the network governance does not remain stable over time, but evolves. At the outset, blockchain projects resemble start-ups. They organise to agilely develop proofs-of-concept among a small group of individuals or interested firms. To gain legitimacy and benefit from network effects, network growth is the major target. The growing network soon changes the nature of the blockchain projects; a formalised governance needs to be set up, coordination costs rise, member involvement becomes more difficult. In this phase, it is important to simultaneously promote application development and network growth, as well as remain attractive for new firms to join. The former is linked to a strong management, the latter to a collaborative approach and shared control. This is the phase in which the applications we studied currently are.

Departing from this standpoint, we may dare a look into the future of blockchain applications. In a mature state, which no enterprise blockchain project has reached yet, the organisation of a blockchain application may become less elaborate again and mostly focus on administrative tasks. Functionality development is expected to take place on the platform by various actors simultaneously. This development is driven by competition between different ideas without the need for centralised control.

Implications for practice

The notion that blockchain is the wrong technology for many intra-firm projects or projects among a closely associated group of firms is well-established by now (Furlonger and Uzureau 2019). Applications of the technology are meaningful where they involve a network of users (Kumar, Liu, and Shan 2020). If the application is developed internally within a firm, scaling and interoperability become obstacles that are hard to overcome. Competing applications that are developed collaboratively by groups of firms are likely stronger; they cater to the needs of a larger variety of firms, aggregate more funding, expertise and market power. For decision-makers that are enticed by the promises of blockchain technology, it might thus be worth to watch out for the collaborative blockchain projects and be reluctant to start new blockchain projects within the limits of the firm or its immediate environment.

Being part of the effort to build an infrastructure that is based on blockchain requires firms to collaborate with other firms. They must commit to collaborating with competitors, making compromises, and, finally, integrating a jointly developed application into their own processes. This commitment is an important cost associated with adopting blockchain technology and realising the benefits associated with it. As such, blockchain technology is only the trigger for the collaborative effort. The novel technology increases decision-makers willingness to engage in collaboration and make the commitments mentioned above. The aim may ultimately rather be standardisation than using blockchain technology specifically.

On the long journey to developing an application that creates value for its users, the organisational hurdles may be greater than the technological hurdles. Making competitors collaborate to jointly develop an application for themselves and many others to use, and securing sufficient stakeholder buy-in to integrate the application in their respective internal processes, is an important organisational feat. Practitioners should be wary of blockchain projects that do not invest in a solid network governance. How seriously the owners of an application are willing to engage non-shareholding member firms in oversight and decision-making may give an indication for who the ultimate beneficiaries of the application are intended to be.

Future research and limitations

We observe that the organisation and network governance employed in our cases are not fundamentally novel or specific to blockchain. Any collaborative projects unrelated to blockchain may be set up in a similar manner from an organisational point of view. This may change in the future if blockchains can be used for network governance also (Lumineau, Wang, and Schilke 2021). Self-sovereign identity solutions can provide the technological basis for such applications of blockchains (Ishmaev 2021). The Sovrin foundation is an example (www.sovrin.org). Adopting such a design can mitigate issues of trust between participants and make incentive systems more efficient. It is important to differentiate blockchain-supported governance and the governance of blockchain applications. We only addressed the latter in this study. We leave the study of the former and the combination of the two for future research.

Prior studies argue that blockchain technology will change the way firms interact. Disintermediation, for instance, may render certain business models superfluous (Catalini and Gans 2016). The focus lies on the impact of operational blockchain applications on firms and industries. It may be interesting for future research to also investigate how the organisational features of a blockchain application impact firms and industries. Does the role that firms play in building an application impact their benefits? Does it matter whether the application was developed under a centralised management with decentralised oversight in contrast to more centralised or decentralised approaches? How does the monetisation strategy of blockchain applications influence the benefits firms draw from using them? These are just a few questions that may be relevant to address in the future to understand the effects of blockchain technology more fully, as its adoption spreads.

This study has the following limitations. First, the case selection and focus of our study only give a partial view of how firms organise to adopt blockchains. We laid the focus on five blockchain applications developed collaboratively by multiple firms. Other approaches to organise the development of blockchain applications may also be employed. We do not investigate them and instead focus on the one form that seems most relevant for applications of the technology in a supply chain context. In addition, we cannot measure success due to a lack of dependent variables and the immaturity of the cases. The novelty of the phenomenon justifies such a study focus and a relatively descriptive approach to analysing them. Second, the depth of our data is limited by our collection approach. We collected data in phone interviews with a few representatives from each of the five cases. We aimed to speak with a broad spectrum of stakeholders to strike a balance between the depth of the understanding of each case and the breadth of cases in our study. For an in-depth understanding of how each of these cases function, however, we would have had to spend more time with each of them, talking to more stakeholders and talking to them several times. To fulfil the study’s purpose – to provide an early examination of the organisational aspects necessary to adopt blockchain applications – we argue that our data set is rich and meaningful.

Conclusion

This study shows that developing and implementing blockchain applications in a supply chain context is associated with an important organisational effort. In the five case applications we investigated, it is this organisational aspect of collaboratively building blockchain applications that stands out with regard to its complexity and resource intensity. Jointly organising the implementation of a technology among a group of firms has been difficult in the past and will be difficult in the future. Blockchain technology is no exception. Despite all the buzz around blockchain as a novel and potentially disruptive technology, the requirement to involve many stakeholders in building blockchain applications makes it a difficult technology to implement.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Notes on contributors

Stefan Naef

Stefan Naef is a research associate and PhD candidate at the Chair of Logistics Management at the Swiss Federal Institute of Technology Zurich (ETH Zurich). His research interests revolve around how firms organise innovation in the digital age. He holds an MSc in Management of Technology from the Swiss Federal Institute of Technology Lausanne (EPFL).

Stephan M. Wagner

Stephan M. Wagner is a Professor, holds the Chair of Logistics Management, and is Faculty Director of the HumOSCM Lab at the Swiss Federal Institute of Technology Zurich (ETH Zurich). Current research interests include the management of start-ups as suppliers, supplier innovation, digitalisation, supply chain sustainability, and humanitarian operations and supply chain management. His work has been published in management journals, such as the Academy of Management Journal, Journal of Management, or Journal of Business Research, as well as operations management journals, such as Production and Operations Management, Journal of Operations Management, Decision Sciences, Journal of Supply Chain Management, or Journal of Business Logistics.

Christian Saur

Christian Saur is an Associate at AssemblyVentures, a German-American venture capital fund investing in mobility. He holds a Master’s in Industrial Engineering & Management from Karlsruhe Institute of Technology. His focus areas include governance in multilateral partnerships, platform economics and incentive systems.

Notes

1 [APPL-X] is a placeholder for the name of the application (e.g., Global Shipping Business Network (GSBN)

Appendix

A.1 Case summary – Appl-1

Appl-1 was founded in 2019 and is live. It develops an application to provide end-to-end tracking and tracing of finished vehicle shipments, as well as a load capacity management to optimise the utilisation of logistics fleets. Appl-1 addresses the lack of holistic, real-time information along the supply chain of finished vehicles due to siloed, paper-based processes and low degree of digitisation of logistics service providers in the space. The current members include several logistics services providers and a provider of financial services. Users of the solution include both OEMs and sellers.

Appl-1 uses a permissioned blockchain. Only references to the hashed data are shared on the blockchain. Users keep ownership of the data, as the data remains stored in the users’ own data centres. Only the intended recipients of the data can decrypt it. A platform on top of the blockchain network allows for development of functionalities that use the shared data.

Appl-1 is incorporated as two separate legal entities, one owning the IP and one for the exploitation of the platform. A dedicated team manages both. The founding firms jointly own both entities. Membership is possible without a financial stake, and, hence, without any claim to a share of the revenues of the platform. Appl-1 works closely with a technology partner which is a collaborator but has no ownership.

[W]e have the IP company who owns the IP of the platform – and that’s where all the shareholders are in right now – and the operational company for the exploitation of the platform. And if a new party comes in with a new functionality, which will enrich the platform, then we are willing to offer them shares in the exploitation company, but not in the IP company. [Advisor, Appl-1]

A board serves as the main decision-making body with representatives from the shareholders and Appl-1’s management team. Votes are linked to ownership shares; unanimous decisions have been the norm. Working groups focus on specific topics to devise desired functionalities and prepare the decisions to be made in the board. The working groups are open for any member firm to send their experts to.

The management team aims to reduce its dependence on member firms to make certain decisions more freely. While decisions on functionalities benefit from member involvement, decisions on monetisation may become the exclusive responsibility of the management team. This will enable them to better reflect market realities and react to changes in the environment with greater speed and flexibility.

[T]he company is already independent from the shareholders in such a way that they don’t have that much influence on it. The only influence that they have is they bring in the investment capital at the moment. And it’s always like that: the one who pays wants to decide as well. But that’s something what should become less and less and less. [Advisor, Appl-1]

A.2 Case summary – Appl-2

Appl-2 was founded in 2017 by a group of banks. Current members include more than a dozen European banks and a technology provider. The application is live today with more than 500 firms using it. It develops a supply chain finance application targeted at SMEs. Trade finance as an industry remains largely paper-based, which means information is siloed and processes are inefficient. Digital and standardised trade execution would contribute to efficiency gains.

Appl-2 uses a permissioned blockchain. Banks licence the application to offer it to their customers through their own platforms. The licencing is regulated by a rulebook that each member firm agrees to before joining Appl-2.

And that rulebook is the legal and regulatory basis on which the trades occur on our platform […] and it is the same exact rulebook for every member organisation. [Executive, Appl-2]

The legal entity of Appl-2 is owned by the majority of member banks. It features a dedicated management team and a board. All members with a share in Appl-2 above a certain threshold are entitled to a seat in the board. The board is the main decision-making body; the management team aims to build a consensus among board members before decisions are taken. Regular meetings among member firms and the management team allow member firms to provide input on strategic questions. Several working groups focus on specific topics on technology, development, and marketing. They are staffed by experts from member firms.

From the outset, Appl-2 chose to share control among founding members. A dedicated legal entity with a management team was only created later in the development process. Over time and with the support of member firms, the management team has taken over more responsibility to make certain decisions more freely. The reasoning is that the management team is closer to the actual application and should be able to make swift decisions.

So, how this has evolved is that the [Appl-2] organisation of the people working there has taken a more firm grip […] and only asked for input on timing issues and priorities of initiatives that are coming up, and I really welcome that I don’t need to have a say in all questions. [Product manager at member firm, Appl-2]

A.3 Case summary – Appl-3

Appl-3 was founded in 2019 by a group of entrepreneurs with several member firms currently industrialising the application. The focus lies on creating digital identities of products on the blockchain for the luxury fashion industry across a variety of uses. It now numbers more than 25 members, including luxury brands and technical partners, which use the protocol to offer their services to other member firms.

And so, what we do is really a protocol that creates the digital passports for products, on the blockchain. And those digital passports for valuable products ensure you can fulfil three basic needs. It’s a proof of authenticity, meaning that it proves that you actually have a real product. And it’s a proof of ownership. It proves that you’re the actual owner of that real product, that authentic product. And third, it’s a way to actually record information on events. [Executive, Appl-3]

The blockchain protocol is open source and the access to the blockchain is public. Only an encrypted reference to the shared data is stored on the blockchain. The actual data is kept on decentral servers. The technical partners provide functionalities with the data on the platform. Members pay a membership fee based on their size.

In Appl-3, ownership and membership are distinct. The founders secured funding through an ICO; they remain the sole owners of the service platform used in the application. Firms join a non-profit organisation as members but do not become shareholders. They instead buy tokens, which are a means to conduct transactions on the blockchain protocol. Having tokens instead of shares incentivises the token owners to develop the network because tokens can only be spent there.

The founders make up the management team, responsible for the protocol and network growth. As governance bodies, Appl-3 has a board and a general assembly. The board consists of a pre-selected group of large industry players that have a reserved seat upon joining Appl-3 and, additionally, representatives that are elected by the general assembly. In the general assembly, all members have equal votes. Working groups, consisting of experts from the member firms, address technological and commercial aspects of application development.

Initially, the founding team had vast authority. This has since changed; in a formalised step-by-step process, the founders relinquish their decision-making monopoly to the member firms by strengthening the formal governance bodies – the board and the general assembly.

So, at the beginning, when we founded the association a year ago, we were the sole master on board. And little by little and that started with the first general assembly of the association, we started letting go some of power to the [member firms]. [Executive, Appl-3]

With these changes, the founders of Appl-3 aim for an organisation with more shared power and decentralised decision-making. Getting member firms to take on the responsibility and make them become more active in continuing to develop the application is challenging.

A.4 Case summary – Appl-4

Appl-4 was founded in 2019 by a technology provider and a blockchain consultancy. By now, the network has over 20 members from a variety of industries, such as electronics, fast-moving consumer goods, pharma, financial, and telecom. Appl-4 develops a blockchain-based supplier information management tool that improves supplier selection, validation, onboarding and lifecycle management. Suppliers make the documents and information required for standard onboarding processes available on the platform offering buyers a central database to navigate the supplier space. Several member firms integrated the application into their live workflows. Among the member firms are third-party providers of services, such as auditing and validation, which they offer on the platform.

The blockchain network is permissioned. The blockchain consultancy handles operations of the network, while the technology provider hosts the solution on its cloud. Sensitive data is stored off-chain; only a digital passport – a summary of the information provided – is stored on the blockchain. Except for firms that joined at the outset, all members pay a fee.

As main owners, the blockchain consultancy and technology provider are most active in managing and expanding the network, providing a dedicated management team. The board of Appl-4 is made up of representatives from member firms in different industries. The selection of firms to send representatives to the board lies with the management of Appl-4. This selection is aimed to include industry ‘thought leaders’ that have the standing in their respective industries to attract other firms to join. The board determines the overarching project strategy.

So, essentially the business participants or the organisations which are the members of [the board] have got a say in terms of determining the top-class features that they want as part of this product […]. And then they also decide the direction of the whole product. [Analyst, Appl-4]

Despite the decision-making power lying in the hands of the board, the blockchain consultancy can weigh in on decisions. A general assembly consisting of all member firms coordinates the engagement of member firms in the application development, which is carried out by working groups.

A.5 Case summary – Appl-5

Appl-5 was founded as the result of a series of research projects unrelated to blockchain in 2018 by a logistics company and a technology provider. The platform is live today. Currently, the ecosystem created by Appl-5 is just short of 200 members, which include ocean carriers, cargo owners, third-party logistics providers, freight forwarders, customs agencies, ports and terminals, and financial institutions, among others. The application aims to address multiple inefficiencies along the information flows of the global shipping industry that suffers from siloed information ecosystems. Appl-5 offers a platform for document sharing. Sharing such documents digitally would digitise work processes that are currently paper-based and lay the groundwork for the automation of repetitive tasks. In addition, having all parties engaged in the shipping of goods coordinate on the same platform would help accelerate processes and reduce errors (e.g. at customs).

The blockchain is permissioned. On top of the blockchain layer is a marketplace for member firms or third-party developers to provide functionalities that use the shared data. If member firms first build functionalities with the shared data for internal use, they can later still share and monetise them using the marketplace. Functionality development is thus driven simultaneously by many parties.

The two founding firms own majorities of the legal entities that develop and operate the application. In the first years of Appl-5’s existence, non-owner member firms were not involved in any formal governance bodies and most of their engagement was directly with representatives from the legal entities owned by the founders.

If there is a client coming tomorrow and saying, ‘Yeah, but I need this and this and this and this’, then they will absolutely look into it to see whether there are amendments possible to satisfy the client, but also to improve the product. [Executive at member firm, Appl-5]

Appl-5 was scrutinised for aiming to grow its network without decentralising control. Concerns were raised that the looming dependency would deter firms from joining an application that is owned and controlled by a big industry player and competitor. Despite this, the network of firms associated with Appl-5 has grown considerably. Recently, there have been moves towards decentralising control somewhat with the establishment of a board with representatives from a cross-section of member firms to channel their common interests. Another governance body will comprise all major competitors in one echelon of the value chain in global container logistics.

For the [firms], we have a consortium, […]. It’s kind of a bigger group of all different big [firms] within this industry. […] I think we have all top seven worldwide [firms] which will be onboarded within this group, within this association. [Product manager, Appl-5]

In the future, functionality development should take place freely in the marketplace, while the Appl-5 organisation focuses on network development.

A.6 Interview guide

1. Introductory questions

   1. What is your current position and how are you involved in blockchain projects?

   2. How did this involvement start?

2. The [APPL-X]¹

   1. Application: What obstacles does it address in current processes/workflows? What do the processes/workflows look like when the application is implemented?

   2. Membership: Could you give an overview of the different types of members of [APPL-X]?

   3. Technology: Checklist technical properties (Private/public network, consensus mechanism, kind of data, access to data/privacy)

3. Governance structures

   1. Governance: Please elaborate on your understanding of the term ‘governance’ in the context of blockchain applications?

   2. Governance structures: Could you describe the governance of [APPL-X]]?

      1. Are there different types of participating organisations? How do they each contribute?

      2. Let’s imagine that one or a group of members wants to add or change a functionality of the application. How would the process leading from proposing the change to its actual implementation look like?

   3. Governance over time: Could you quickly describe how the governance emerged? Has it changed over time?

   4. [in case of changes] What was the reason for this change?

4. Becoming a member and operation of [APPL-X]

   1. Rollout: How did [APPL-X] ensure the successful rollout of the blockchain application?

   2. Operation: How does [APPL-X] ensure the blockchain application is operated so that it achieves its goals and objectives?

   3. On the choice to join [APPL-X]: why did [EMPLOYER OF INFORMANT] decide to join the [APPL-X]?

   4. Allocation of benefits: Since joining, have you experienced any negative aspects of being part of [APPL-X]? Do you think other members experience the same/different kind of disadvantages?

5. Outlook

   1. What is the way forward in [APPL-X]?

   2. Do you expect the joint work in [APPL-X] to change over time?

   3. Are you planning to fully integrate the application into [EMPLOYER OF INFORMANT] core processes, or will it run separately?