Digital Trade Infrastructures: A Framework for Analysis

. In global supply chains, information about transactions resides in fragmented pockets within business and government systems. The lack of reliable, accurate and complete information makes it hard to detect risks (such as safety, security, compliance and commercial risks) and at the same time makes international trade inefficient. The introduction of digital infrastructures that transcend organizational and system domains is driven by the prospect of reducing the fragmentation of information, thereby enabling improved security and efficiency in the trading process. This article develops a digital trade infrastructure framework through an empirically grounded analysis of four digital infrastructures in the trade domain, using the conceptual lens of digital infrastructure.


Introduction
This article contributes knowledge about digital infrastructures that was obtained through our participation in the CORE EU-funded project; it is based on the working paper [1], a short version of which was presented at the BIR 2017 conference [2].In global supply chains, information about transactions resides in fragmented business and government systems.Parties are often reluctant to share data, or are even legally prevented from doing so [3], [4].As a result, the flow of goods is accompanied by information streams of poor quality; and end-to-end supply chain visibility is extremely challenging to achieve [3].The lack of reliable, accurate and complete data makes it hard to detect risks (such as safety, security, compliance and commercial risks); and at the same time makes international trade inefficient.
Governments and interested organizations involved in international trade are increasingly recognizing that the resolution of information fragmentation is one of the key challenges in improving conditions for international trade.In the EU, the adoption of digital technologies to reform control processes was a strategic ambition in the continuously revised multi-annual strategic plan (MASP) for customs development [5].The digital enablement of trade has also been the focus of a stream of EU-funded research and development projects (e.g.CORE, CASSANDRA, CONTAIN, INTEGRITY, ITAIDE, etc.).Common to several of these initiatives is that they seek in various ways to promote the development of digital trade infrastructures (DTIs).In the digital trade context, several digital trade infrastructure concepts have emerged, such as single window, national community hubs, and data pipelines (see [6], [7], [8]).Recently, data pipelines have been further conceptualized as thick or thin, depending on whether actual documents are exchanged in the data pipeline or whether only limited event-related data is exchanged [9].
A digital infrastructure (DI) can be seen as a system-of-systems [10], [11] that transcends organizational and system domains, reducing information fragmentation.A DI is an open, dynamic, complex and networked artifact; it contains a finite number of constituent systems which are independent and operable.These are also networked together for a period of time to achieve a higher goal.In the area of trade, it has been argued that DIs that transcend the current information silos can enable more efficient risk assessment, supply chain optimization, and cost savings [3], [4], [8], [12], [13], [14], [15].In demonstration installations of infrastructural innovations such as single window, national community hubs and data pipelines, it has indeed been shown that a range of benefits can be derived from reducing information fragmentation in the area of trade [6], [8].
However, outside the controlled environment of demonstration installations, the adoption and growth of DTIs has been limited.Accounts from the field show that conflicts related to data sharing, standards, financing and benefits distribution cause infrastructural initiatives come to a halt [7].Some of the reported problems correspond to issues of technological complexity and actor enlistment, which are known challenges within the DI literature.Other issues seem to be specific to the trade domain, with its intricate interplay of governments at national and international level to control the flow of goods and influence decisions related to infrastructural initiatives [2], [15].This limited amount of cumulative knowledge development concerns the specific challenges of developing infrastructures in the areas of trade or DTIs'.In consequence, even less is known how these challenges can be mitigated in the design and implementation processes.
For instance, Tilson et al. [16] put out a call to the information systems (IS) research community to focus further research efforts on understanding the phenomena of DIs, and researchers have responded to this call.If we look into this response based on Scopus citations, we see that the majority of papers focus on mobile applications and healthcare solutions; this is not surprising, as readers can easily relate to these two domains.Only 11 papers (of the 185 we examined) touch upon the arena of international trade.It is clear that international trade has received very limited attention.To some extent, this is surprising, bearing in mind the complexity of trade processes; on the other hand, it is also understandable, since international trade, to some extent, appears remote and abstract, compared to healthcare and mobile applications.Yet goods and services are products of international trade activities and form an integral part of our daily life, for instance, the fruits that we eat or the flowers that we set on the coffee table.Thus, although the processes by which these goods and services reach the consumer remain to a large extent hidden behind the scenes, these processes (and the DIs supporting them) are important, and deserve further attention.
One important aspect of building an understanding of why and how digital trade infrastructural initiatives in the trade domain frequently stall is an understanding of the specificity of an initiative, that is, the ways in which the many attributes of a DI are configured in this specific instance.Only when this specificity is understood, it is possible to contrast different digital trade infrastructural initiatives; that makes it possible to learn across attempts, and to eventually understand the challenges faced in developing DTIs and the ways of overcoming these.
Therefore, the aim of this article is to identify the components of a DTI.It should be seen as a stepping stone in the efforts to increase our understanding and provide grounds for cumulative learning regarding DTIs, with the ultimate goal of better understanding the challenges faced by DTI initiatives and how these can be overcome, in order to move such initiatives from initiation to implementation and adoption.
To this end, this article develops the DTI framework through an empirically grounded analysis using the conceptual lens of DIs.The DTI framework is built around the three dimensions identified in the DI literature, namely, architecture, process, and governance; these are further detailed specifically for the DTI domain by contrasting four attempts to build DIs within the trade domain.As such, the framework (and more specifically its architectural dimension) also carries an understanding of what sets infrastructural development in the trade domain apart from the development of DI in general.The resulting framework can be applied to characterize specific DTI initiatives in cross-case comparisons of DTI initiatives and to outline further research directions for further articulating problems and developing tools to advance the understanding of the issues faced by such initiatives.This is a necessary first step in the development of instruments to address issues related to DTIs, and to create a basis for these initiatives to be further advanced towards their implementation and adoption.

Digital Infrastructure Design
Until recently, IT artifacts covered by the term DI have been seen and approached as large-scale or global types of IT systems; and related methodologies and approaches have been tailored to address problems with the development of IT systems.However, a range of cases in the public domain have very poignantly demonstrated both the fundamental difference between DIs and global IT systems and the inadequacies of the approaches used for systems development to address the specific problems of DIs [17], [18], [19], [20].Based on the fundamental argument that these new IT solutions need particular attention, researchers started to investigate the DI as a new type of socio-technical IT artifact.Technically, a DI was seen as comprising a set of heterogeneous, interoperable IT-systems that support processes and actions [11].Socially, DIs were described to extend beyond mere materiality and predefined human skills to encompass social, organizational, and moral elements [11], [21], [22].
Looking back at the main characteristics described in the research exploring the nature of DIs, Hanseth and Lyytinen [10, p. 4] define a DI "as a shared, open (and unbounded), heterogeneous and evolving socio-technical system (which we call installed base) consisting of a set of IT capabilities and their user, operations and design communities."This is the definition of a DI adopted in this study.
In the search for explanations and solutions for effective DI development, the extant research portrays the DI development challenge as two-fold.One part of the challenge originates in the inertia of the installed base.The installed base refers to the pre-existing components of the DI that constitute the starting point for any development attempt; these include existing work practices, human resources, standards, technological artifacts and organizational commitments [10], [22], [23].Since in the development process, it is rarely possible to redesign the DI from scratch, development always "wrestles with the inertia of the installed base and inherits strengths and limitations from that base" [23, p. 113].Inertia to change may come from technical elements, human habits and social norms that are resistant to transformation [21] and this limits the direction of a development trajectory [11], [25], [26].
The other part of the explanation relates to the coordination of the diverse set of actors, each of whom is responsible for a part of the DI.The coordination challenge of DI development originates from the fact that most DIs are distributed across a diverse set of actors, who must each mandate change in the socio-technical components that they control.As a consequence of this dispersed and distributed ownership, a lack of centralized control is a fundamental attribute of DI development [23].Typically, different actors develop the DI "in modular increments, not all at once or globally" [27, p. 382].This incremental process is also highly political, with struggles for influence and control [28].
In view of the dual challenge of installed base inertia and the coordination of distributed control, the general conclusion in the extant literature is that the effective development of DI requires approaches that are different from traditional methods of system development [10], [16].As noted by Edwards et al. [21, p. 369], particular stakeholder groups "rarely if ever 'build' infrastructure; they must nurture it and, if they are lucky, help it to grow".Thus, DI development generally draws on the metaphor of cultivation.Following this metaphor, approaches to DI development provide guidance on "how to 'cultivate' an installed base and promote its dynamic growth" [10, p. 15].Generally, suggestions on how to cultivate DI focus on three design domains: architecture, governance and process.
The architectural design of DI is the aspect that has received the most attention in research.Architecture refers to the components of the DI and how they are connected.Since DIs are sociotechnical, any DI will contain both social and technical components.The social components include stakeholders and practices for using the DI [21].Gal et al. [29, p. 18] state: "Technically, the construction of an infrastructural system requires the establishment of protocols and standards that enable the system to be used and seamlessly connect with other systems.Socially, its construction necessitates the elaboration of a system of classifications that symbolically represent and organize things in society: people, classes, geographical areas, religions, civil status, and so on." It is also noted that the DI architecture shapes the way DI's evolution is organized and managed [30].Solutions that are based on tightly coupled architectures, tend to create complex systems that are challenging to realize in practice, require a high degree of stakeholders' coordination, and may be too expensive to change in future adaptations [30].In contrast, highly modular architectures that allow gradual scaling and growth are more flexible in seizing opportunities and facing uncertainties.
Regarding the governance of DIs, there is an extensive body of research demonstrating the shortcomings of traditional IT management strategies, including hierarchical organizational structures and the distribution of decision rights, careful planning, and the execution of plans for the management of DIs (see, e.g.[23]).However, the research on what kind of governance approaches actually work is largely lacking, with a few exceptions including the research on the evolution of the Internet presented above [17].Another exception is Constantinides' [31] research, in which he draws extensively upon Elinor Ostrom's research on "Governing the Commons" [32].Based on Ostrom's research, Constantinides [31] describes three kinds of property or decision rights related to a DI: constitutional, collective choice, and operational.Operational rights refer to those related to access and the contribution and extraction of resources, that is, rights to access a DI.Collective choice refers to rights of removal, management and exclusion of users, while constitutional rights refer to who may or may not participate in making collective choices.Constantinides [31] sees the allocation of these three categories of rights as being central to the governance of DIs.
Commonly in the DI literature, governance is seen as a combination of interactions between top-down and bottom-up driven processes.For instance, the Catalan electronic prescription information infrastructure (II) was shaped through the joint efforts of Catalan Health Services (representing the Catalan Ministry of Health) that initiated it and initially set the functional specifications for the building of the II and the Catalan Council of Pharmacists that ensured the effectiveness of the II for the regional pharmacies [20].Similarly, Reimers et al. [32] note that the government's willingness and ability to set standards, enforce inter and intra-organizational IS, and regulate the industry, led to II emergence in a de facto combination of top-down and bottom-up processes.
Process design refers to how the DI is built, and is a complementary view of DI design.Henfridsson and Bygstad [25] have reviewed and reinterpreted all DI cases reported in IS journals.They found 41 different cases, of which they considered 17 to be unsuccessful and 24 successful.All successful infrastructures started small and evolved into large ones.Approaches for growing an infrastructure, from an initial setup solving a very specific problem for a minor group of stakeholders to a more generic solution that is adopted by a larger group of users, include the creation of an 'attractor' [34], adherence to design principles that enable growth [10], incremental functional deployment [30], promotion of generative evolutionary mechanisms [25], and the establishment of 'killer apps' [35] for active management of the growth of the installed base.

Methodology
Given the nascent stage of knowledge on a DTI, we approach our research objective using a method similar to analytic induction [36].Analytic induction starts deductively, within the formulation of a guiding framework that is empirically validated and extended by an analysis of case data.In this study, we use the three design domains of a DI (architecture, governance and process) as a general theoretical framework for analyzing cases in international trade, to establish the relevant sub-dimensions of each design domain.

Case Background
In line with our analytic inductive approach, we searched for cases that would allow us to reveal contextual elements influencing work with DIs in international trade.As a basis for our analysis we took four international trade infrastructure initiatives, referred to here as the UK case; the Flower case (sea and air trade lanes from Kenya to the Netherlands); the Global initiative, involving a global carrier and a global IT provider; and the Alpha initiative of the Netherlands.
The UK case focused on demonstrating how supply chain partners can use data pipelines to exchange documents with each other and with the authorities.This case focused on exchanging actual documents via the data pipeline and a lot of efforts were spent on standardization.Two scenarios were tested on how information can be made available to the authorities from the data pipeline: via the Port Community System or via a government portal.The case demonstrated that the data pipelines can bring clear benefits and cost savings for businesses; and authorities can get better information to cross-validate, e.g.customs declarations.
The Flower case focused on importing flowers from Kenya to the Netherlands via sea and air.The data pipeline makes it possible to obtain information from the exporting country (such as pro-forma invoice) and this information can be used by Customs to perform customs risk assessment earlier while the goods are still in the air.A second interesting aspect in this case is that in the import of flowers, next to Customs, also the Plant Health authorities are involved.There is a sequential dependency among the risk assessment done by Customs and the selection procedures of the Plant Health authorities.Through the use of the data pipeline it was demonstrated that the procedures can be redesigned from sequential to parallel.This leads to clear benefits for businesses, as the importer knows whether the goods will be inspected or not already before the plane lands (as opposed to the current situation when part of the risk assessment processes can start only after the goods have arrived).As a result, for 95% of the goods which are not selected for inspection the onward transport can be planned in advance, which leads to logistics optimizations and cost savings.
The Global initiative focused on developing a global data pipeline.Initially it started with the idea to exchange only events and links to documents rather than the actual documents.However, during the demo block-chain technology was introduced to the demo and the scope of the Global initiative was expanded to include two components of the global data pipeline: one that focusses on capturing and making logistics events available to the supply chain partners and the authorities.The other block-chain enabled component allows for exchanging documents in a very secure way.During the demo it was demonstrated that the data pipeline developed by the Global initiative is able to handle large volumes of data and this data can be made available to the authorities.
The Alpha initiative is a national initiative in the Netherlands that aims to facilitate the information sharing between parties in the supply chain and the authorities nationally by promoting the development and use of standards and agreements to facilitate information sharing.Better information sharing among terminals, freight forwarders, trucking companies, barge companies, shippers, and the authorities can allow for more efficient logistics processes, faster clearance and other related benefits.This is of strategic importance for the competitive position of The Netherlands in Europe.

Data Collection
For each of the cases, we collected data within the broadly defined streams of DI research.The data collection is summarized in Table 1.

Data collection UK case
Data regarding the UK case was collected between 2014 and 2016 as part of the CORE project.Data was collected through documentation provided by project partners, and through regular communication (e-mails, face-to-face meetings, conference calls, interviews) with partners involved in the UK case.Flower case Data collection took place predominantly in the period 2014 to 2018, as part of the CORE project.Two of the authors of this article were involved in various roles including project coordination and analysis, and provided input for key project deliverables.This involvement included continuous communication (face-to-face, phone, and e-mail) and collaboration with the other project participants, participation in key meetings and events, and access to primary and secondary data.

Global initiative
Data collection took place within in the period 2014 to 2018, as part of the CORE project.Three of the authors of this article were involved in various roles including project coordination and analysis, and provided input for key project deliverables.This involvement included continuous communication (face-to-face, phone, and e-mail).

Alpha initiative
The Alpha initiative was external to the CORE project.One of the members of the research team is a member of the Sounding Board of this initiative and followed it from its initiation.This includes regular participation in meetings (approximately 6 times per year) for the duration of the initiative.
The data collection relied on participation in face-to-face meetings, discussions, workshops, and interviews, and the authors had access to rich project documentation (emails, project reports, and evaluations).Two of the authors actively participated in the Flower case and the three of the authors actively participated in the Global initiative.In their project roles they had responsibilities for writing key project deliverables related to these cases.As such they had deep insights into these projects.The link to the UK case was more remote, where deliverables were used as a starting point to familiarize with the case.Follow-up presentations, interview and extensive collaboration with the UK partners were developed also in the context of working on joint deliverables related to public-private governance, where members of the UK case also participated and provided input.The Alpha initiative was followed via regular meetings (approximately 6 times per year) where one of the authors is a member of the Sounding board and has been following the development since the initiation.

Data Analysis
We examined and analyzed this data using the three dimensions of DI research discussed in Section 2 (architecture, process, and governance), guided by the logic underlying the analysis strategies associated to less procedural versions of the methodology of grounded theory [37].At the core, we started with the three dimensions identified in theory (architecture, process, and governance) and used "constant comparative analysis" to identify sub-categories; we then attempted to link this evolving set of concepts to the higher-level categories [37].Eventually, the higher-level categories and the sub-categories identified from the cases were consolidated into the emergent DTI characterization framework.
During the data analysis, we used our own observations, accumulated through our continuous engagement in the project, and reviewed project documentation such as the deliverables, reports and meeting notes from the cases.Two of the authors engaged in a number of sessions to discuss the findings from contrasting and comparing the cases.The third author played the role of a critical reviewer of these findings.
When looking at the architectural component, we compared and contrasted the cases and tried to identify common dimensions that could be used to characterize the DTI initiatives.Although the initiatives were quite different, they all aimed to facilitate international trade processes, which involved interactions between business and government actors.By comparing and contrasting the cases, we also identified actors such as port community systems, which played a role in facilitating these interactions.We therefore included the concept of intermediary actors.Following this, when comparing and contrasting the initiatives, we saw that in some cases the actors who were directly involved in supply chain initiatives (such as shippers, freight forwarders, and carriers) were driving the DTI development, while in other cases the associations took the lead.We therefore made an explicit distinction among direct and indirect actors.
In our analysis of the four cases, we also saw that some initiatives aimed to introduce national hubs, while others aimed at thin or thick data pipelines.To capture this diversity, we introduced the concept of DTI type, in which we distinguished between (thick/thin) data pipelines and national hubs.Through this continuous comparing and contrasting, we also saw differences in the scope of the initiatives: while some focused on a national level, others had international scope (two or more countries) and other global ambitions.We therefore also introduced the concept of levels under the architecture dimension of our framework.
Regarding the process dimension, we again compared and contrasted the cases.We saw clear differences, in that some initiatives were in the early initiation phases, whereas others were already in the operational phase.Following this, we distinguished new services as a separate phase, since in two of the cases there were prominent discussions about the development of smart apps as new services that could be offered on top of the infrastructure once it was operational.The issues related to these phases were quite different, and we therefore decided to introduce phases and sub-categories within the process dimension.
Finally, when looking at infrastructure governance, we found that while this was considered an important dimension in all cases, in three of the four cases the governance was informal, and only in one case was there a formal board.We therefore introduced formal and informal subdimensions to indicate the maturity level of the development of governance structures for the DTI initiatives.Since governance was considered important, although the governance structures in these cases were not well developed, we introduced the analytical categories of decision rights [31] in order to give further structure to the governance dimension; these were, as discussed above, constitutional, collective choice, and operational rights.Looking back at the cases, we identified (based on earlier research [7] and empirically from the four cases) that in all cases cost-benefit sharing, standards and data access were key decision areas.We included these as sub-categories of collective choice rights, since these pointed to specific decision areas related to DTI initiatives.
In the process of development of the DTI we gained empirical insights in a grounded way by comparing and contrasting the cases; we also iteratively went back and forth between the case findings and the literature.As a result, we also further sharpened our thoughts and linked our findings to concepts and findings from the literature.Detailed tables (Table A1, Table A2, and Table A3) linking the dimensions of the framework to the four cases and the relevant literature are shown in Appendix.The resulting DTI framework is presented and illustrated in the next section of this article.

Results: Digital Trade Infrastructure Framework
Table 2 and its visual representation in Figure 1 present the DTI framework derived by the analysis process described in Section 3.  The framework is structured around the three components identified in the DI literature (architecture, process, and governance) as overarching dimensions; it also includes further subcategories of these dimensions, based on the four cases and insights from the literature.
Under architecture, we distinguish between (a) levels (national, international, global); (b) actors (business, government, intermediary; direct, indirect); (c) interactions (business-tobusiness (B2B), business-to-government (B2G), government-to-government (G2G)); and (d) DTI types (national hub, data pipeline (thick/thin)) † .† The thick and thin data pipelines are included here to capture the analytical concepts.The thick and thin data pipelines represented in Figure 1 suggest one possible positioning (e.g.thick data pipeline limited to business-to-business actors), although other configurations are also possible.The figure also includes Under the process, we make a distinction between three phases: initiation, operation and maintenance, and new services.Under governance, we distinguish between infrastructure governance (formal/informal) and decision rights (constitutional, collective choice, operational).We further identify standards, data access, and cost-benefit sharing as sub-categories of collective choice rights.
Tables A1 to A3 in Appendix provide a summary of the analysis by listing the concepts of the DTI framework, links to literature, findings from the four cases, and cross-case observations.In Sections 5 to 7 the findings regarding the architecture, process, and governance dimensions are discussed further.

DTI Architecture
The architectural dimension of the DTI framework enabled us to represent the four different initiatives using the same concepts and to visualize them in a similar way (see Figure 2).This enables us to reason in a structured way about the focus of each initiative and enables us to look for architectural similarities and differences.
From Figure 2, we can see that the initiatives range from national to international, to global, and that they also differ in terms of the DTI type that they try to establish.The Alpha initiative and the national hub components of the UK case (the private hub Destin8 and the public attempt (OneGov) to establish such a hub) are all examples of initiatives that try to establish a national hub to optimize information exchanges between the businesses involved in international trade in that country and the government authorities involved.It would be meaningful to compare these initiatives, in order to gain further insights into the issues related to setting up national hub infrastructures.
The UK case, the Flower case, and the Global initiative all focus on data pipeline DTI.However, different choices are made about the infrastructure types: the UK case focuses on a thick data pipeline (where actual documents are exchanged) and has ambitions for international coverage; the Flower case also focuses on a thick data pipeline, but it is limited to a specific trade lane; and the Global initiative focuses on a thin data pipeline (exchanging only event information and links to documents rather than the documents themselves) and has a global ambition.
The architectural component of the framework also helps us to see how different initiatives fit together.A global data pipeline initiative like the Global initiative aims for global coverage, but this relies on the existence of other parts of the infrastructure, such as the availability of national hubs to connect national governments in different countries, as well as thick data pipelines which can further facilitate the actual document exchange between parties if needed.
Thus, the architectural component can be useful both in looking for meaningful comparison cases (e.g.comparison of national hub DTI initiatives or of thick data pipeline initiatives) and in identifying complementarities between different DTI initiatives and how they can be combined as parts of a larger DTI.
It is also notable that the levels in the architectural component can be used in different ways.The most obvious of these is that they can be used to characterize the scope of the initiative.three national hubs connecting business and government actors; however, depending on the scope and ambition of the infrastructure initiative, the role and number of national hubs may vary.A national hub is used here as an organizational configuration that enables exchanges between business and government actors on a national level, and does not involve a particular technical architecture (i.e. the technical architecture can vary).

DTI: UK case Scope: International
Aim: To illustrate the development of a thick data pipeline that links to a national community hub in the UK (Destin8 is a private hub; OneGov is a public hub under development).

DTI: Global initiative Scope: Global
Aim: To illustrate a global thin data pipeline that connects businesses and government actors (public good philosophy).

DTI: Flower case Scope: International
Aim: Trade-lane-specific thick data pipeline facilitating information exchange related to the export of flowers from Kenya to the Netherlands.This is particularly interesting, as it shows how a DTI can enable coordinated border management between customs and phyto-sanitary inspection agencies at national as well as international levels (across inspection agencies between Netherlands and Kenya).

DTI: Alpha initiative
Scope: National Aim: The focus is on the development of a national community hub to facilitate information sharing among business and government actors in the Netherlands.However, they can be also useful in reflecting on developments at other levels with influence on the DTI initiative.For instance, international regulations, global standards or actors with global influence may influence the development path of national initiatives.An anecdotal example from the Alpha initiative (a national initiative) is that although significant effort and time were put in to developing data sharing concepts that are useful for both the business and government actors involved, later in the process it was discovered that these concepts could not be implemented due to restrictions at a higher level (restrictions imposed by the EU, as part of the EU privacy law).As a result, a great deal of effort, time and positive momentum was lost, and the initiative was put on hold, blocking it from further implementation.It is therefore important to keep these different levels in mind in order to trace possible external influences on the DTI initiatives, and to consider these influences when defining strategies for action.

The DTI Process
The second component of the DTI framework focuses on the process.As discussed in Section 3, comparing and contrasting the initiatives highlighted a need to differentiate conceptually between three phases, namely: (a) initiation; (b) operation and maintenance; and (c) new services.Particularly for the Global and Alpha initiatives, we see that many complications arise from the initial investment and the question of who will invest in the infrastructure.In the initiation phase, issues related to cost-benefit and infrastructure governance are related to the question of how to get stakeholders on board and convince them to invest in and commit to adopting the DTI.
Once such an infrastructure is up and running (the operation phase), and the governance and cost-benefit issues become quite different, since they relate to the development of business models for operation and maintenance.In the UK case, for instance, the initial investments had already been made in the past by commercial parties, and in the operation phase the pipelines are now commercially run with a viable business model behind them, where users pay fees for services offered by the infrastructure providers.
In the cases analyzed, most of the initiatives are still in the initiation phase; however, discussions about the new services phase are ongoing.In the Global initiative case, a new service app was developed before the infrastructure was in place to increase users' interest and experience.In the Alpha initiative, the parties were eager to develop new apps, but were waiting for the infrastructure to be in place so that they could offer their new services.At the same time, most of the initiatives that we analyze here are still trying to gain financing for the initiation phase or are searching for business models for the operation and maintenance phase.These business models are not directly obvious, due to the different parties and the public and private interests involved.The issue of fair cost-benefit sharing (part of the governance component of the DTI framework) bears repeating as a discussion point, especially in the Alpha initiative.The DTI is expected to bring savings and efficiency gains to the parties in the chain, but it is not obvious how these gains will be redistributed in the chain.In the cases analyzed, substantial efforts are put into addressing this issue.As we can see, the discussion of the DTI process links directly to issues related to DTI governance, and this illustrates the fact that these issues are very much interlinked.

DTI Governance
Governance is the third dimension of our framework.In the complex multi-actor network of stakeholders, the governance is very important, but remains a challenging issue to address.Only one out of the four cases (the Alpha initiative) had a formal governance structure in the form of a governance board; in all the other cases the governance was informal.In the UK case, the private providers of data pipelines and the private hub had an internally organized governance, but the collaborations between the pipelines and national hubs (Destin8 and OneGov) were managed informally.The Flower case is still in the early demonstrator phase; there is a steering group of decision makers from the key partner organizations, which oversees the process at the moment, but their role is informally defined.The Global initiative case is driven mainly by a global carrier and a global IT provider, but formal governance structures are yet to evolve.
One observation that we can make regarding the governance dimension is that although it is very important to address this, governance is still a complex area that needs to be further understood.
As discussed earlier, Constantinides [31] sees the allocation of three categories of rights (i.e.constitutional, collective choice, and operational) as a central issue in the governance of DIs.To recap, operational rights refer to the access, contribution and extraction of resources, i.e. rights to access a DI.Collective choice rights refer to the removal, management and exclusion of users, while constitutional rights refer to who may or may not participate in making collective choices.These categories can help us to reflect further on these four cases and derive insights for further research.
Reviewing these four cases and looking at these decision rights in relation to the phases identified here, we can say that the decision rights as defined by Constantinides [31] mostly apply to the operation and maintenance phase, as they seem to assume the existence of the DI.It is interesting, however, to explore the possible links of the conceptual categories of decision rights in relation to the case findings, as well as the other phases defined here.
Constitutional rights refer to who may or may not participate in making collective choices.In the Global initiative, the global carrier and the global IT provider are driving the initiative, and the key challenge is how to mobilize a collective action to secure further funding and ensure wider adoption for this initiative.It is likely that the parties making decisions in the initiation phase are different from those in the operation and maintenance and new services phases.In the new services phase, new parties may enter who also gain decision rights and become players in the decision-making process.Thus, it would be meaningful to extend the notion of constitutional rights to the initiation and the new service phases, to see if new findings can be derived from this.
As discussed earlier, collective choice rights refer to the removal, management and exclusion of users.This definition is very much centered around the subject of users.If we broaden the view that parties who have constitutional rights will need to make collective choices related to a number of areas (of users could be one, for instance), then we can further explore and identify the specific areas related to the DTI for which collective choices need to be made (i.e. the collective choice rights could be exercised).Our case findings reconfirmed findings from prior research that important choices for the DTI relate to (a) standards; (b) data access; and (c) costbenefit sharing.
Operational rights, as discussed earlier, refer to access and contribution to and extraction of resources (i.e.rights to access a DI).Again, this assumes the existence of the DI, and raises the question of what the meaning would be if expanded to the other two phases.For the initiation phase, this may be linked to the investments needed for the setup of the infrastructure and possible return on investment (in the cases analyzed here, we see that initial investment is crucial and that securing such an initial investment is a difficult process).In the new services phase, the operational rights may relate to the rights of app providers to provide apps on top of the infrastructure, as well as the value exchanges related to the use of the infrastructure and the offering of new services.
Another observation that we need to make is that the rights discussed above assume that such rights are easily defined.In our case findings, however, we see that most of the initiatives (all except one) used informal governance, and the rules were not explicitly defined.Furthermore, although these categories can help to bring further structure to key decision-making processes, the process dimension needs to be further conceptualized and explored in terms of how the actors come together, how constitutional rights are obtained, who drives and shapes this process and how the actor configuration changes and evolves through the different phases of the infrastructure development.The analysis of collective action processes can be an interesting conceptual lens to further examine such processes [42].

Discussion and Conclusions
DTIs are perceived as promising solutions for enhanced supply chain visibility and risk assessment, as they enable cost savings and allow for trade facilitation [3], [4], [15].There are currently several efforts to set up DTIs at national, international and global levels.However, the process of setting up such infrastructures poses many challenges, as it involves multiple stakeholders (nationally and internationally) who represent the businesses and the governmental bodies controlling cross-border trade activities.Conflicts arising from issues related to data sharing, standards, and the questions of who will finance an infrastructure and how the costs and benefits will be shared may bring such initiatives to a halt; as a result, it is extremely difficult for DTIs to be developed and scaled up.At the beginning of this article, we argued that, in order to understand the problem at hand, we need a way to conceptualize the different infrastructure initiatives and where they stand in the development processes, so that we can better diagnose the problems and the challenges they bring.In this article, based on empirical insights from four such DTI initiatives, we develop a DTI framework to be used as a tool to reason about and compare different DTI initiatives, in order to enable a further accumulation of knowledge about DTI initiatives, what brings them to a halt and what are the mechanisms that unblock these processes and allow for further upscaling and uptake of DTIs.
So far, the DTI framework has been useful as a conceptual lens for reasoning about the architecture, process and governance components of DTI initiatives and their interrelationships.Our analysis also illustrates that the architectural, process and governance components are strongly intertwined, and an exploration of these dependencies is necessary to gain a better understanding of the complexities and problems at hand.The DTI framework allows us to characterize DTIs, and to look for meaningful comparisons of similar cases and complementarities.A deeper understanding of the complex interplay between the architectural configurations, processes and governance of DTIs will enable us to better understand the complex processes that drive a DTI from initiation to operation and further growth through the new services phase.Of all the components, the governance component (and its relationships to the other two components) seems to be the most challenging, as it is the complex interplay of actors and decision-making processes that brings a DTI to a halt or drives it to success.
Thus, this article should be seen as a stepping-stone for further empirical research on DTIs, which can be fed back to practice in terms of models, best practices, and insights.The different components of the framework and their interrelationships provide a basis for deriving further research questions to better enhance our understanding of DTI initiatives.For the process component, a possible area of research would be to delve more deeply into the initiation phase, to identify the factors that block these initiatives and put them on hold and the mechanisms that unlock these processes and allow the DTI initiatives to move towards implementation.Regarding governance, one possible question would be to explore the processes of how constitutional rights are obtained and whether and how they change as the infrastructure develops from initiation to operation and towards new services.Cost-benefit sharing is another interesting area in which further research can focus on identifying cost-benefit sharing models which are useful for supporting the business case in the initiation phase, including cost-benefit models to support the business model for the operational phase and cost-benefit models to allow app providers to access infrastructure.In terms of the architecture component, possible areas for research would be to carry out comparative studies and gain cumulative knowledge of the complexities related to setting up a specific DTI type (e.g.national hub, thick or thin data pipelines), and the lessons learned.To this end, the DTI framework and its utilization in this article to characterize four DTI initiatives advances our understanding of both DIs in general and what sets DTIs apart from other DI initiatives.
Regarding the general understanding of DI, our research reveals a need to reconsider DIs as heterogeneous rather than homogenous constructs.Extant research on DIs has generally searched to unravel the convergent characteristics and mechanisms uniting IIs across its wide range of manifestation.It is recognized that IIs span across a class of artifacts that presents substantial variation, but the variations within the artifact has never been brought to the forefront of DI theorization.In this research, we capture important variations in both what DI is used for and how the DI is configured to be effective in its use.
Under the assumption that there is not one single best way to configure a DI, but that the many possibilities to configure the DI must be adapted to the problem situation at hand, three important design findings emerge.Firstly, there is a tendency towards archetypical architectural DTI setups.In theory, choices at decision points of the infrastructure can be freely combined; in reality, however, it seems that some architectural design choices go more naturally together.These "natural fits" of architectural design choices indicate that there might be possible archetypical infrastructure setups of design attributes that align with each other.The implication of this finding is that anyone interested in the shaping of DIs cannot make independent choices regarding the architectural design, but must recognize the systemic dependencies between the choices; one specific choice will influence the possibility of choices in other design areas.
Secondly, the different archetypical DI setups seem to address different problems.Contrasting different setups is not about declaring one to be better than another; they are simply different tools, and are used in different scenarios.The scenario is defined by the infrastructure setup.Depending on the setup (level, actors, scope, etc.) a different archetypical setup is suitable.For instance, for the UK DTI with a more limited actor and geographical scope, it was decided that the best setup would be to exchange documents within the pipeline (and hence, adherence to data standards was of key importance) and to offer this as a commercial service.In contrast, the inclusive design (in terms of geography and actors) of the Global initiative, aiming for global scope, led to a decision on a minimalist standardization (i.e.not standardizing data elements) and a common-good philosophy.Critically, the choice regarding decision points in the UK case would not be suitable for the Global initiative, and vice versa.Thus, the question to answer in each specific case is: what is the problem to be solved, and how can we map the connectivity infrastructure setups according to this problem?The design of an infrastructure setup may be flawed, if the combination of attributes is not coherent, and the elements for the DTI framework are misaligned.For instance, combining an international ambition with the standardization of data elements is likely to be a futile exercise, since no global agreement can be made at this lower level.
Thirdly, each of the archetypes seems to have distinct "must-win battles", depending on the process (i.e. the phase of the DTI) and the governance choices.For the Global initiative, currently in its initiation phase, the critical "must-win battle" is to mobilize a mass of supply chain actors to join the initiative.This design is a subject to network effects; the more actors that join the initiative, the greater the benefits for all.However, there are initially no benefits to joining, in the same way that there would be no benefits to being the first (only) one with a telephone or a Facebook account.In the infrastructure literature, this is called the "bootstrapping problem" and should be addressed through pre-emptive strategies.This relates to the complexity of governance of a DTI in the initiation phase of the initiative.Prior research on mobilizing collective action can be used as inspiration for further research to address this problem [42].
The framework also offers an understanding of what sets infrastructural development in the trade domain apart from the development of DIs in general.This is mostly captured in the architectural dimension of the DTI framework.Specificity in the trade domain is largely related to two issues: (a) the very tight interactions of the supply chain actors with the authorities in international trade activities (e.g.submitting customs declarations and other documents for every shipment); and (b) the international and global dimension of the international trade activities, which makes the DTI development a subject to the direct influence of international regulations and standards.This sets DTI initiatives apart from other DI initiatives such as setting up a National Health Infrastructure.While it is certainly worthwhile carrying out comparisons and deriving findings from DI initiatives in other domains, the specificities of DTIs and the related additional complexities need to be kept in mind.
All research has limitations, so also our work.Most importantly, although our research is based on the inductive analysis of four different cases, the case-based methodology means that the findings we present are limited to the specific cases we analyze.Differences in use situation, geographical context and technologies employed could have rendered additional or even contradictory insights about the critical design decisions for DTI.In addition, as several of the cases analyzed were at the implementation or launch stages, it still remains to be seen whether the chosen designs are effective when put into use.While this limits the possibilities for us to be prescriptive of the design attributes that are applicable in specific situations, the analytical purpose of the DTI framework to espouse the decisions that have explicitly or implicitly been made is still met.
For future work, it will be important to advance the understanding of the archetypes of DTI architecture setups, building knowledge about which choices, governance decision points and processes go well together in coherent archetypes, which problems the archetypes can be used to solve, and what are the particular challenges of each archetype.In all initiatives, decisions about standards need to be made.All the initiatives consider global standards.In the Alpha initiative, there is also a focus on national standards development.
In the UK case and the Global initiative, there is a very distinct choice of international standards.There is a choice of different standards though.In the UK case, the focus is on standards for data/ document exchange; in the Global initiative the focus is on

Figure 1 .
Figure 1.Visualization of the DTI framework

Figure 2 .
Figure 2. Use of the architecture component of the DTI framework to describe the four cases

Table 2 .
The DTI framework

Table A2 .
The process component of the DTI framework and links to the four cases and the references of the article Most of the initiatives are in the initiation phase.In the UK case, the development of the public hub is also in an initiation phase, and the private pipelines and the private national hub are in an operational phase and have profitable business models.In the Alpha initiative and the Global initiative there are already a discussions about the development of smart apps on top of the infrastructure (new services phase).

Table A3 .
The governance component of the DTI framework and links to the four cases and the references of the article