Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Complex Systems Informatics and Modeling Quarterly (CSIMQ)
eISSN: 2255-9922
Published online by RTU Press, https://csimq-journals.rtu.lv
Article 80, Issue 14, March/April 2018, Pages 1–21
https://doi.org/10.7250/csimq.2018-14.01
Digital Trade Infrastructures: A Framework for Analysis
Boriana Rukanova1*
, Stefan Henningsson2, Helle Zinner Henriksen
2, and
Yao-Hua Tan1
1 Department of Technology, Policy and Management, Delft University of Technology,
Building 31, Jaffalaan 5, 2628 BX Delft, The Netherlands 2 Department of Digitalization, Copenhagen Business School, Solbjerg Plads 3,
DK-2000 Frederiksberg, Denmark
[email protected], [email protected], [email protected], [email protected]
Abstract. 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.
Keywords: Information infrastructures, Global supply chains, International
trade.
1 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
* Corresponding author
© 2018 Boriana Rukanova et al. This is an Open Access article licensed under the Creative Commons Attribution License
(CC BY 4.0), https://creativecommons.org/licenses/by/4.0
Reference: B. Rukanova, S. Henningsson, H. Z. Henriksen, and Y.-H. Tan, “Digital Trade Infrastructures: A Framework for
Analysis,” Complex Systems Informatics and Modeling Quarterly, CSIMQ, no. 14, pp. 1–21, 2018. Available:
https://doi.org/10.7250/csimq.2018-14.01
Additional information. Authors ORCID iD: B. Rukanova – orcid.org/0000-0003-0254-5787, S. Henningsson – orcid.org/0000-
0003-3865-7086, H. Z. Henriksen – orcid.org/0000-0003-0123-3546. PII S225599221800080X. Received: 29 January 2018.
Accepted: 9 April 2018. Available online: 30 April 2018.
2
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.
3
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.
2 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
4
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 socio-
technical, 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
5
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.
3 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.
3.1 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
6
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.
3.2 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.
Table 1. Data collection for the four cases
Case 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.
3.3 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
7
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 sub-
dimensions 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.
8
4 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.
Table 2. The DTI framework
Dimension Category Values
Architecture Levels National, international, global.
Actors Business/government/intermediary; direct/indirect.
Interactions Business-to-business (B2B); business-to-government (B2G);
government-to-government (G2G).
DTI type Data pipeline (thick/ thin); national hub.
Process DTI development
phases
Initiation; operation and maintenance; new services.
Governance
Infrastructure
governance
Formal/ Informal.
Decision rights Constitutional rights;
collective choice rights;
standards;
cost-benefit sharing;
data access;
operational rights.
Figure 1. Visualization of the DTI framework
The framework is structured around the three components identified in the DI literature
(architecture, process, and governance) as overarching dimensions; it also includes further sub-
categories 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-to-
business (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
9
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.
5 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).
10
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.
Figure 2. Use of the architecture component of the DTI framework to describe the four cases
11
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.
6 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.
7 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
12
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) cost-
benefit 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
13
infrastructure development. The analysis of collective action processes can be an interesting
conceptual lens to further examine such processes [42].
8 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.
14
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
15
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.
Acknowledgements
This research was partially financed by the CORE Project (nr. 603993), which is funded by the
FP7 Framework Program of the European Commission. Ideas and opinions expressed by the
authors do not necessarily represent those of all partners.
References
[1] B. Rukanova, S. Henningsson, H.Z. Henriksen, and Y.-H. Tan, “The Anatomy of Digital Trade
Infrastructures,” in Institutional Repository (working paper), 2016. Available:
https://doi.org/10.4233/uuid:59931d65-26d5-4255-973b-04fe395bfbc7
[2] B. Rukanova, H.Z. Henriksen, S. Henningsson, and Y.-H. Tan, “The Anatomy of Digital Trade
Infrastructures,” in Perspectives in Business Informatics Research, BIR 2017, Lecture Notes in Business
Information Processing, vol. 295, Springer, pp. 184–198, 2017. Available: https://doi.org/10.1007/978-3-319-
64930-6_14.
[3] T. Jensen and R. Vatrapu, “Shipping information pipeline: initial design principles,” in At the Vanguard of
Design Science: First Impressions and Early Findings from Ongoing Research Research-in-Progress Papers
and Poster Presentations from the 10th International Conference, DESRIST 2015, Dublin, Ireland, pp. 17–24,
2015.
[4] T. Jensen and R. Vatrapu, “Ships & Roses: A Revelatory Case Study of Affordances,” in International Trade,
ECIS 2015, Completed Research Papers. Paper 88.
[5] TAXAUD (2008). Electronic Customs Multi-Annual Strategic Plan – TAXUD/477/2004, Rev. 8, EN.
Brussels, Belgium, European Commission.
[6] D. Hesketh, “Weaknesses in the supply chain: Who packed the box?” World Customs Journal, vol. 4(2), pp. 3–
20, 2010.
[7] A. J. Klievink, E. Van Stijn, D. Hesketh, H. Aldewereld, S. Overbeek, F. Heijmann, and Y.-H. Tan,
“Enhancing visibility in international supply chains: The data pipeline concept,” International Journal of
Electronic Government Research, vol. 8(4), pp. 14–33, 2012. Available:
https://doi.org/10.4018/jegr.2012100102
[8] Y.-H. N. Tan, N. Bjorn-Andersen, S. Klein, and B. Rukanova, Accelerating Global Supply Chains with IT-
Innovation, Springer, 2011. Available: https://doi.org/10.1007/978-3-642-15669-4
[9] M. S. Janssen, S. van Engelenburg, and Y.-H. N. Tan, “Comparing a Shipping Information Pipeline with a
Thick Flow and a Thin Flow,” working paper, 2015.
16
[10] O. Hanseth, E. Monteiro, and M. Hatling, “Developing Information Infrastructure: The Tension between
Standardization and Flexibility,” Science, Technology, and Human Values, vol. 21(4), pp. 407–426, 1996.
Available: https://doi.org/10.1177/016224399602100402
[11] O. Hanseth and K. Lyytinen, “Design theory for dynamic complexity in information infrastructures: the case of
building internet,” Journal of Information Technology, vol. 25(1), pp. 1–19, 2010. Available:
https://doi.org/10.1057/jit.2009.19
[12] Z. Baida, B. Rukanova, R. T. Wigand, and Y.-H. N. Tan, “The Story of How Heineken’s Supply Chain
Benefits from Tight Collaboration with Government,” Supply Chain Management Review, vol. 11(8), pp. 11–
12, 2007.
[13] Z. Baida, B. Rukanova, J. Liu, and Y.-H. N. Tan, “Preserving control in trade procedure redesign–The Beer
Living Lab,” Electronic markets, vol. 18(1), pp. 53–64, 2008. Available:
https://doi.org/10.1080/10196780701797656
[14] B. Rukanova, E. van Stijn, H. Z. Henriksen, Z. Baida, and Y.-H. N. Tan, “Understanding the influence of
multiple levels of governments on the development of inter-organizational systems,” European Journal of
Information Systems, vol. 18(5), pp. 387–408, 2009. Available: https://doi.org/10.1057/ejis.2009.28
[15] S. Henningsson, U. Gal, N. B. Andersen, and Y. H.-N. Tan, “The next generation information infrastructure for
international trade,” Journal of Theoretical and Applied Electronic Commerce Research, vol. 6(1), pp. 1-15,
2011. Available: https://doi.org/10.4067/S0718-18762011000100002
[16] D. Tilson, K. Lyytinen, and C. Sørensen, “Research Commentary – Digital Infrastructures: The Missing IS
Research Agenda,” Information Systems Research, vol. 21(4), pp. 748-759, 2010. Available:
https://doi.org/10.1287/isre.1100.0318
[17] J. Damsgaard and K. Lyytinen, “The role of intermediating institutions in the diffusion of electronic data
interchange (EDI): How industry associations intervened in Denmark, Finland, and Hong Kong,” Information
Society, vol. 17(3), pp. 195–210, 2001. Available: https://doi.org/10.1080/01972240152493056
[18] C. Sauer and L. Willcocks, “Unreasonable expectations – NHS IT, Greek choruses and the games institutions
play around mega-programmes,” Journal of Information Technology, vol. 22(3), pp. 195–201, 2007. Available:
https://doi.org/10.1057/palgrave.jit.2000108
[19] J. Hedman and S. Henningsson, “The new normal: Market cooperation in the mobile payments ecosystem,”
Electronic Commerce Research and Applications, vol. 14(5), pp. 305–318, 2015. Available:
https://doi.org/10.1016/j.elerap.2015.03.005
[20] J. Rodon and L. Silva, “Exploring the Formation of a Healthcare Information Infrastructure: Hierarchy or
Meshwork?” Journal of the Association for Information Systems, vol. 16(5), article 1, 2015. Available:
https://doi.org/10.17705/1jais.00395
[21] P. Edwards, S. Jackson, G. Bowker, and C, Knobel, “Understanding infrastructure: dynamics, tensions, and
design,” NSF Report of a Workshop: History and theory of infrastructure: lessons for new scientific
cyberinfrastructures, 2007.
[22] E. Monteiro and O. Hanseth, “Social shaping of information infrastructure: on being specific about the
technology,” in Information technology and changes in organizational work, Springer, Boston, MA, 1996, pp.
325–343. Available: https://doi.org/10.1007/978-0-387-34872-8_20
[23] C. Ciborra and O. Hanseth, “Introduction,” in From Control to Drift, Oxford, UK, Oxford University Press,
2000, pp. 1–12.
[24] S. L. Star and K. Ruhleder, “Steps toward an ecology of infrastructure: Design and access for large information
spaces,” Information systems research, vol. 7(1), pp. 111–134, 1996. Available:
https://doi.org/10.1287/isre.7.1.111
[25] O. Henfridsson and B. Bygstad, “The Generative Mechanisms of Digital Infrastructure Evolution,”
Management Information Systems Quarterly, vol. 37(3), pp. 907–931, 2013. Available:
https://doi.org/10.25300/MISQ/2013/37.3.11
[26] S. Henningsson and O. Hanseth, “The essential dynamics of information infrastructures,” presented at the
International Conference of Information Systems (ICIS), Shanghai, 2011.
[27] S. L. Star, “The ethnography of infrastructure,” American Behavioral Scientist, vol. 43(3), pp. 377–391, 1999.
Available: https://doi.org/10.1177/00027649921955326
17
[28] T. A. Sanner, T. D. Manda, and P. Nielsen, “Grafting: Balancing Control and Cultivation in Information
Infrastructure Innovation,” Journal of the Association for Information Systems, vol. 15(4), pp. 220–243, 2014.
Available: https://doi.org/10.17705/1jais.00356
[29] U. Gal, K. Lyytinen, and Y. Youngjin, “The Dynamics of IT Boundary Objects, Information Infrastructures,
and Organisational Identities: The Introduction of 3D Modelling Technologies into the Architecture,
Engineering, and Construction Industry,” European Journal of Information Systems, vol. 17(3), pp. 290–304,
2008. Available: https://doi.org/10.1057/ejis.2008.13
[30] M. Aanestad and T. B. Jensen, “Building nation-wide information infrastructures in healthcare through
modular implementation strategies,” The Journal of Strategic Information Systems, vol. 20(2), pp. 161–176,
2011. Available: https://doi.org/10.1016/j.jsis.2011.03.006
[31] P. Constantinides, Perspectives and implications for the development of information infrastructures, IGI
Global, 2012. Available: https://doi.org/10.4018/978-1-4666-1622-6
[32] E. Ostrom, Governing the commons: The evolution of institutions for collective action, Cambridge University
Press, 1990. Available: https://doi.org/10.1017/CBO9780511807763
[33] K. Reimers, M. Li, B. Xie, and X. Guo, “How do industry wide information infrastructures emerge? A life
cycle approach,” Information Systems Journal, vol. 24(5), pp. 375–424, 2014. Available:
https://doi.org/10.1111/isj.12034
[34] J. Braa, E. Macome, J. C. Mavimbe, J. L. Nhampossa, J. L. da Costa, A. Manave, and A. Sitói, “A study of the
actual and potential usage of information and communication technology at district and provincial levels in
Mozambique with a focus on the health sector,” The Electronic Journal of Information Systems in Developing
Countries, vol. 5(1), pp. 1–29, 2001. Available:
https://doi.org/10.1002/j.1681-4835.2001.tb00031.x
[35] B. Eaton, J. Hedman, and R Medaglia, “Three different ways to skin a cat: financialization in the emergence of
national e-ID solutions,” Journal of Information Technology, vol. 33(1), pp. 70–83, 2018. Available:
https://doi.org/10.1057/s41265-017-0036-8
[36] M. Q. Patton, “Qualitative research,” in Encyclopedia of Statistics in Behavioral Science, John Wiley & Sons,
Ltd, 2005. Available: https://doi.org/10.1002/0470013192.bsa514
[37] A. Bryant and K. Charmaz, The Sage handbook of grounded theory, Sage, 2007. Available:
https://doi.org/10.4135/9781848607941
[38] B. Rukanova, R. W. Wigand, E. van Stijn, and Y.-H. N. Tan, “Transnational Information Systems: A Multi-
level, Conflict Management Perspective,” Government Information Quarterly, vol. 32, pp. 182–197, 2015.
Available: https://doi.org/10.1016/j.giq.2014.12.003
[39] J. M. Bryson, “What to do when stakeholders matter. Stakeholder Identification and Analysis Techniques,”
Public Management Review, vol. 6(1), pp. 21–53, 2004. Available:
https://doi.org/10.1080/14719030410001675722
[40] B. Rukanova, R. W. Wigand, and Y.-H. N. Tan, “From National to Supranational Government Inter-
Organizational Systems: An Extended Typology,” in Proceedings of eGov 2009, LNCS, vol. 5693, Springer,
pp. 317–327, 2009. Available: https://doi.org/10.1007/978-3-642-03516-6_27
[41] P. Constantinides and M. Barrett, “Information Infrastructure Development and Governance as Collective
Action,” Information Systems Research, vol. 26(1), pp. 40–56, 2014. Available:
https://doi.org/10.1287/isre.2014.0542
[42] B. Rukanova, H. Z. Henriksen, A. von Raesfeld, E. van Stijn, and Y.-H. Tan, “A Collective Action Perspective
on Technological Innovation in Business/Government Networks,” in EIS 2008 Proceedings, paper 3. Available
online: http://aisel.aisnet.org/eis2008/3
18
Appendix
Table A1. The architecture component of the DTI framework and links to the four cases and the references of the article
Cases/literature
links
References
in the
article
Alpha initiative UK case Flower case Global
initiative
Cross-case observations
DTI architecture
Levels (national;
international;
global)
[14], [38] National. National
International.
International. Global. The cases cover initiatives that vary in
scope from national to international, to
global.
Meaningful comparisons:
Comparison of national hub initiatives
(i.e. Alpha initiative and the national
hub part of the DTI in the UK case);
Comparison of the data pipeline
component of the UK case DTI, Flower
case, DTI, and Global initiative DTI.
Actors
Actor (business
(B); government
(G);
intermediary(I);
direct, indirect)
[39] B, G, I
Primarily indirect actors.
B, G, I
Direct actors.
B, G, I
Direct actors.
B, G, I
Direct actors.
Although in three of the four cases
direct actors are main drivers of the
DTI initiatives, in the Alpha initiative
the indirect actors (the associations) are
the key drivers.
In all initiatives, business, government
and intermediary actors are involved.
Interactions (B2B;
B2G; G2G)
[40] B2B; B2G; G2G. B2B; B2G; G2G. B2B; B2G;
G2G.
B2B; B2G;
G2G.
In all four cases, the DTI involves B2B,
B2G, and G2G interactions.
DTI type (national
hub; data pipeline
(thin; thick)
[6], [7], [9]
National hub. National hub
(Two initiatives set
up to act as a
national hub:
Destin8 (private);
OneGov (public)).
Thick data pipeline
for international
B2B interactions
and links to the
national hub.
Thick data
pipeline
(trade-lane-
specific).
Thin data
pipeline.
The cases represent initiatives with
different architectural configurations,
ranging from a national hub, thick, thin
and trade-lane-specific data pipelines.
19
Table A2. The process component of the DTI framework and links to the four cases and the references of the article
Cases/ literature
links
References
in the
article
Alpha initiative UK case Flower case Global
initiative
Cross-case observations
DTI process
Phase (initiation;
operation and
maintenance; new
services)
[30] Alpha initiative is in an
initiation phase.
There are discussions
about how gain sharing
will look in the operation
phase, as well as
possibilities for
development of apps on
top of the infrastructure
in the new services
phase.
Operation phase
(national hub,
private).
Operation phase
(data pipelines;
private).
Initiation phase
(national hub,
public).
Initiation
phase.
Initiation phase
A prototype of a
smart app
offered to gain
insights into
possible new
services that can
be offered on
top of the
Global initiative
once in
operation.
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
Cases/ literature
links
References
in the
article
Alpha initiative UK case Flower case Global
initiative
Cross-case observations
DTI governance
Infrastructure
governance
Formal/ informal
[31], [41] Formal (government
board).
Informal. Informal. Informal. Only in the Alpha initiative there is a
formal governance board; in all the
other initiative there are informal
governance structures at the moment.
Decision rights [31], [41] Details below. Details below. Details below. Details below. As most of the initiatives are in
Initiation phase and their governance is
often still informal, understanding
governance issues related to DTI
remains challenging and needs to be
further explored.
Constitutional
rights
Defined for the members
of the governance board.
Defined for the
private pipelines
and the private hub.
Not formally
defined; there
is a steering
committee
Not formally
defined; two
key partners in
the lead but
20
Cases/ literature
links
References
in the
article
Alpha initiative UK case Flower case Global
initiative
Cross-case observations
with decision
makers from
key partners
involved but
roles are
informally
defined.
formal
structures not
yet defined.
Operational rights Not yet defined. Defined for the
private pipelines
and the private
Hub.
Not yet
defined.
Not yet defined.
Collective choice
rights
Rights to decide which
projects to fund.
Broadly defined themes
around technology,
communities and
application areas. The
key decision areas below
are also identifiable for
the Alpha initiative.
Not formally
defined.
The key decision
areas below are
identifiable in the
UK case.
Not formally
defined.
The key
decision areas
below are
identifiable in
the Flower
case.
Not formally
defined.
The key
decision areas
below are
identifiable in
the Global
initiative.
Key decision areas
(standards; cost-
benefit sharing;
data access)
[7] See details below. See details below. See details
below.
See details
below.
In all initiatives, key decision areas
include standards, data access and cost-
benefit sharing.
Standards Links to global
standards.
Development of
standards for information
sharing on national level.
Choice of global
standards for data/
document
exchange.
Choice of
global
standards for
data/
document
exchange.
Choice of global
standards for
exchange of
event
information.
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
21
Cases/ literature
links
References
in the
article
Alpha initiative UK case Flower case Global
initiative
Cross-case observations
standards that can exchange event
information.
Cost-benefit
sharing
Key issue in Alpha
initiative; search for
models for:
- initial funding of the
infrastructure;
- fair models for gain
sharing.
The private
pipelines and the
private national hub
have viable
business models.
The public hub
needs to be
developed and
financed. It is yet to
be seen how the
availability of the
national hub will
affect the cost-
benefit models of
the private hub/
private pipeline
initiatives that are
now pursued.
Private data
pipeline.
Current focus
on running the
technical
demonstrator;
preparation
work on cost-
benefit is done
at the moment;
discussions on
cost benefit
will be carried
out in the next
phase of the
case.
Key issue:
- Initial
financing of the
infrastructure;
- Choice for a
common good
approach.
The cost-benefit issue is important in
all initiatives. In the Alpha initiative
and the Global initiative, a key issue is
how to finance the infrastructure
development in the initiation phase.
A second key cost-benefit issue is to
find models for cost-benefit sharing
once the infrastructure is available
(operation and maintenance phase).
Data access Key issue in Alpha
initiative.
Information
between pipelines is
not shared.
Data access
secured for the
pilot; it is yet
to be seen how
this could be
arranged
beyond the
pilot.
Information
about events
and links to the
data source can
be shared.
Access rights to
the data to be
arranged among
the parties
themselves.
Decisions about data access are needed
in all the initiatives. In the Alpha
initiative, this is one of the key
discussion points. In the UK case, there
was an explicit choice not to share data
between pipelines; in the Global
initiative, event information and links
to documents can be shared (but the
actual document exchange is out of
scope).