Abstract
Interoperability promotes data-driven practices by enabling the aggregation and sharing of data from distributed information systems. It thus offers potential benefits to organizations for delivering more efficient and sustainable services. Despite its potentials, achieving interoperability remains a significant challenge. In this paper, we shed light on the obscure landscape of organizational challenges that lead to low interoperability. Based on a 3-year longitudinal single-case study of a public agency’s attempts to enhance interoperability, we uncover how three major categories of equivocality – scope, needs, and priorities – hinder approaches to interoperability at the data, software, and IT levels. We also reveal that entangled organizational tensions explain why such equivocalities emerge. By analyzing interoperability challenges from the combined concepts of equivocality and tensions, this paper offers a unique perspective on their intricate nature, making sense of the obscure landscape of challenges in various approaches to interoperability.
Introduction
Organizations and individuals generate large volumes of data on a daily basis, making interoperability an increasingly critical concern for organizations looking to take advantage of this wealth of data to deliver more efficient and sustainable services. Interoperability is ‘the ability of two or more systems or components to exchange information and to use the information that has been exchanged’ (IEEE, 2002: 42). It is an important organizational capability that allows communication between distributed information systems (IS) and fosters collaboration with partners in an ecosystem (Zhao and Xia, 2014). Aggregating and sharing critical data from heterogeneous information technologies (IT) are made possible through interoperability – hence, it offers potential benefits to organizations for addressing systemic issues in a holistic way (Addo, 2022; Irani et al., 2023).
Common approaches to interoperability target one of the three architectural layers to achieve interoperability: (i) data level, (ii) software level, and (iii) IT level (Hodapp and Hanelt, 2022). First level is the data, which is focused on ensuring that different systems have a common understanding of the data being exchanged. This requires attention to both semantic (meaning-based) and syntactic (structure-based) interoperability (Chen et al., 2008). Second level is the software, concerned with the interoperability of system interfaces, such as APIs, which allow different software applications to connect seamlessly despite differences in underlying technologies and environmental factors (Hodapp and Hanelt, 2022). Finally, the IT level involves establishing standards or platforms that facilitate communication between systems (Vergara et al., 2007). At any level, approaches to interoperability often involve new technology development (Hodapp and Hanelt, 2022), such as semantic web technologies for data interoperability (Rongen et al., 2023; Touré et al., 2023), middleware technologies for software interoperability (Esposte et al., 2019; Munonye, 2022), and microservices architecture for IT interoperability (Esposte et al., 2019; Siddiqui et al., 2023).
Hodapp and Hanelt’s (2022) review of interoperability literature revealed that there remains a noticeable gap in understanding the intricate relationship between the technical and organizational aspects of various approaches to interoperability. On the one hand, studies that have explored various approaches to interoperability often focused on their technical features but overlooked organizational dynamics that promote or hinder the adoption of interoperability standards. Legacy replacement projects aimed at adopting new digital technologies to increase interoperability have a high failure rate (Alexandrova and Rapanotti, 2020). The underlying reasons for the high failure rate are particularly difficult to address as they involve ‘a dynamic and fluid constellation of critical problems that typically may not be easily identified, understood and addressed’ (Baghizadeh et al., 2020: 132). Less attention has also been paid to the ‘obscure landscape of antecedents’ (Hodapp and Hanelt, 2022: 415) causing low interoperability in an organization. On the other hand, studies that took an organizational perspective subsequently disregarded the technical differences of various approaches to interoperability (de Reuver et al., 2018; Hodapp and Hanelt, 2022). A major problem is that management and business literature treats the various approaches homogenously; that is, most of the literature does not distinguish between data, software, and IT level approaches (Festila and Müller, 2022; Hodapp and Hanelt, 2022). There is therefore a lack of studies that consider the intersection between the technical features and the organizational dynamics that promote or hinder interoperability.
Addressing this gap is necessary to cultivate a broader understanding of the challenges to interoperability. This is echoed not only by previous studies on interoperability (Allen et al., 2014; Gottschalk, 2009; Margariti et al., 2022) but also by the European Union, which highlights the importance of incorporating organizational structures, business practices, and management techniques in achieving interoperability (European Union, 2017). In this paper, we aim to address this gap by answering the following research question: What are the organizational challenges associated with various approaches to interoperability, and why do these specific challenges arise?
We follow the suggestion of Arviansyah et al. (2015) and Sakka et al. (2016) to use the concept of equivocality from Weick (1995) as an analytical lens to capture the challenging and ambiguous aspects prevalent in new digital technology development for increasing interoperability. To explain why specific categories of equivocality arise, we also adopt typologies of organizational tensions (Smith et al., 2022; Smith and Lewis, 2011) as those are underlying sources of equivocality (Weick, 1995). By combining these analytical concepts, this paper offers a unique perspective on the intricate nature of the barriers to interoperability, shedding light on the underlying reasons behind these challenges.
This paper is structured as follows. First, we explain the study’s theoretical background and present the relevant literature on equivocality and underlying organizational tensions. Following this, we describe the research method adopted and the selected case study. Then, we present our findings, followed by a discussion of the results and their implications for research and practice. We conclude with a short synopsis of our study and provide recommendations for future research.
Theoretical background
Categories of equivocality
Equivocality is the presence of two or more conflicting interpretations of a given situation (Weick, 1995) and is signalled by confusion, conflict, and/or lack of consensus and/or understanding (Daft et al., 1987). Daft and Lengel (1986) also referred to this as ambiguity, although Weick (1995: 95) preferred the term equivocality as ‘it explicitly points to the presence of two or more interpretations as a trigger to sensemaking’. Extant literature proposes general categorizations of equivocality, which do not adequately convey what is equivocal or why. For example, Sandberg and Tsoukas (2015) proposed five broad categories of equivocal events, which range from major planned and major unplanned events (e.g. various forms of deliberate strategic change initiatives, and organizational crises and disasters, respectively) to minor planned and minor unplanned events (such as adjustments to existing policy and existing software, or small misunderstandings between actors, respectively) and hybrids of major/minor planned/unplanned events. This categorization can include an infinite number and types of events (Sandberg and Tsoukas, 2015), and consequently does not help in gaining insight into what about an event is equivocal or why.
A less broad categorization of equivocality is suggested in the literature on organizational change and IT/IS development, although they offer divergent conclusions on its impact on organizational change. Jiang et al. (2014) demonstrated how programs for Enterprise System implementation strove for radical changes in managerial and operational processes, which led to chasms between local goals and interpretations of global goals. These studies found that global goals are equivocal in that multiple interpretations are held by different stakeholders, who must then reach an agreement that benefits all parties (Jiang et al., 2014). Goal equivocality can be used as a rhetorical resource to accommodate multiple interests and enable collective organizational action (Jarzabkowski et al., 2010). This is similar to the findings of Gioia et al. (2012), who argued that goal equivocality enabled a sense of alignment between local and larger organizational goals, which sets organizations on the path to successful change. On the other hand, as reported by Abdallah and Langley (2014), equivocality in strategic goals only initially played an enabling role in enacting varying interpretations of a strategy but later led to internal contradiction and overextension. Denis et al. (2010) also found that when strategic equivocality becomes prevalent, it can lead to a gridlock of escalating indecisions in the long term. Existing studies thus offer contradictory conclusions on the mediating role of equivocality on development and organizational change, for example, in cases of interoperability approaches.
Using the concept of equivocality as an analytical lens helps us both in recognizing problematic situations associated with various approaches to interoperability and in defining what these problematic situations mean. In doing so, we aim to extend literature on this topic by identifying different categories of equivocality and describing how they impact various approaches to interoperability. To explain why specific categories of equivocality arise, we draw on the related concept of organizational tensions.
Typology of organizational tensions
Tensions are underlying sources of equivocality. They refer to opposing demands or sources of contradictions inherent in the organization, as organizational design and structure create divisions and boundaries that delineate dualities and foster oppositions (Lewis et al., 2014; Lewis and Smith, 2022). In their seminal review, Smith and Lewis (2011) identified four main typologies of tensions: performing, learning, belonging, and organizing. Performing tensions evolve from the clash of competing demands that stem from pursuing divergent organizational successes (Denis et al., 2007). Differing, and often conflicting, demands are fostered by a plurality of internal and external stakeholders (Lüscher and Lewis, 2008) and these result in competing organizational strategies and goals (Smith et al., 2022). Learning tensions pertain to the inhibition and facilitation of learning when dynamic systems change, renew, and innovate (Lewis, 2000). Learning is inhibited when actors use existing frames of references to make sense of their new experiences and choose interpretations that support these frames (Westenholz, 1993). Early studies on technology renewal found that learning tensions are exhibited when organizations try to find a balance between refining an existing technology and inventing a new one (Levinthal and March, 1981; March, 1991). This has received more recent support by Wimelius et al. (2021) who found that, in digital innovation processes, tensions between established and renewed technology usage manifested because users resisted the new technology to preserve established use patterns.
Belonging tensions pertain to tensions between the self and the other, or the individual and the collective, as actors strive for both self-expression and collective affiliation (Smith and Lewis, 2011). These tensions often intensify conflict and polarization (Lewis, 2000) and can result in recursive cycles in which ‘one side of the dynamic fuels the opposite, fostering emotional paralysis’ (Lüscher and Lewis, 2008: 232). According to a study by Danneels and Viaene (2022), belonging tensions arise in new digital technology development when top management tries to balance making individual employees feel part of the organization and aiming for a drastically different organizational future through digital innovation. Finally, organizing tensions arise when complex systems create competing designs and processes to reach a desired outcome (Smith and Lewis, 2011). Examples include tensions between control and flexibility (Lewis, 2000), between centralization and sub-unit autonomy (Ravn et al., 2022; Tatikonda and Rosenthal, 2000), and between striving to maintain stability and to create change (Lüscher and Lewis, 2008). In digital innovations, tensions between ‘deliberate and emergent renewal practices’ arise as the implementation of digital technologies must be both effectively facilitated by deliberate leadership and flexible towards emergent improvisations in response to unforeseen events (Wimelius et al., 2021: 202).
When there is a plurality of views, change, and scarcity of resources (Smith and Lewis, 2011), tensions surface as equivocality that demands sensemaking (Hargrave and Van de Ven, 2017; Jay, 2013; Weick, 1995). Conversely, when organizational actors encounter equivocality, it can indicate the presence of deeper organizational tensions. For example, conflicting interpretations of success among organizational actors can indicate sources of contradictory organizational goals embedded in organizational structures and systems (Putnam et al., 2016). Tensions are thus made observable through the lens of equivocality, while equivocality can signal underlying organizational tensions. On this basis, we posit that the combined concepts of equivocality and organizational tensions provide a suitable analytical lens for identifying organizational challenges associated with various approaches to interoperability and explaining why these specific challenges arise.
Research method
Research approach
To gain deep insights into the challenges to achieving interoperability and the ‘obscure landscape of antecedents’ (Hodapp and Hanelt, 2022: 415) leading to low interoperability, we carried out an in-depth, longitudinal single-case study (Pettigrew, 2012). This approach is very appropriate for studies that aim to better understand why approaches to interoperability fail by paying attention to problematic situations that arise in the course of implementing these approaches (Langley et al., 2013). As this constellation of problematic situations is typically not easily identified or understood (Baghizadeh et al., 2020), an in-depth case study approach is highly suitable. Moreover, it allows real-time observations of what organizational actors do and say, and how they interact with each other over time within their situated contexts and in relation to what happened before and after (Pettigrew, 2012). It was therefore important for our study to choose an organization that had recently initiated various approaches to increase interoperability so we could observe their course from an early stage to their conclusion.
We thus chose the case of AMOrg (a pseudonym), a public transport agency responsible for operating, managing, and improving national civil road and water transport infrastructures (termed here as assets). At AMOrg, we were able to gain early access to a new digital innovation program (DIP) initiated in 2019 that aimed to increase organizational interoperability by restructuring, integrating, and linking together the organization’s legacy systems to enable data-driven asset management. In this program, AMOrg aimed to develop new digital technology to increase interoperability at the data, software, and IT levels.
Case description
AMOrg commissions construction companies (here termed contractors) for the construction, replacement, and maintenance of its highways, waterways, and civil engineering structures. As the executive agency of the Dutch Ministry of Transport, the organization owns and manages more infrastructure assets than anyone else and therefore serves as the largest client for infrastructure projects in the country. The organization has an asset management line and a project-based line, which are mainly responsible for the construction, maintenance, and management of infrastructure assets.
The asset management line is divided into seven geographical regions, each headed by chief engineers who make decisions on regional development based on ministry policies. Each regional unit acts as an autonomous ‘state’ with its own subculture and authority over its own asset management methods and processes. At the local level, asset managers in regional districts attend to the daily upkeep and conservation of civil infrastructure within their area. Their tasks include monitoring the condition of assets through inspections and surveys, and managing the documents (e.g. inspection reports, design drawings, and inventory reports) as they are produced or revised due to these tasks. However, there is little uniformity between districts in how information management is implemented. The 150 legacy systems used by districts are heterogeneous and include databases for storing asset information (such as topographical and geographical data with administrative features such as legal documents, management plans, and manuals), an Engineering Documentation Management System (EDMS) for accessing and managing technical documents and drawings, various Geographic Information Systems (GIS) for managing operations and maintenance processes, and various other legacy systems for managing quality and performance information of assets (such as results of condition measurements, inspection results (functional, safety, and condition), malfunctions, and maintenance history).
When construction, replacement, or maintenance works are necessary, the relevant district will commission the project-based line to execute a project. The project-based line consists of specialists in purchasing and contract management, project management, and process management. Senior project managers manage a portfolio of projects grouped in terms of asset type (e.g. bridge, tunnel, or sea lock) and discipline (e.g. cables and pipes, industrial automation, and hydraulic engineering). For each project, a team of specialists is formed to manage the project and supervise the contractor. Contracts govern the relationship between AMOrg’s project team and the contractor. Contract requirements are stored and managed in model-based systems engineering software. Project teams also use this application for baselining, reporting, and contract control. Another application used by project teams is a Project Document Management System (PDMS) for storing and managing all documents related to a specific project.
The separation between the asset management and project-based lines has clearly influenced the ICT policies designed to support the asset management process and led to low interoperability: each regional district uses an array of applications designed for its own needs, and with varying but limited ability to communicate its electronically stored asset information to other districts or projects that need it. The array of applications used by a district amounts to a mix of solutions provided at the organizational level by AMOrg’s ICT department. Each district has its own customized set of applications, with unique entry fields, fill-in instructions, and asset management taxonomies and ontologies. A high degree of internal fragmentation and self-organization has led to complex data structures since the former siloed systems had developed data dependencies and links with a large variety of systems and data sources without any formal mechanisms to coordinate these dependencies (Brous et al., 2014). Although a vast quantity of asset data is available from districts, its retrieval for projects can be difficult and time-consuming as the nature, quality, structure, type, and precise location are often unknown. Projects will often be allotted a sizeable budget for gathering asset information from district databases and/or for commissioning engineering firms to provide missing asset information. Project teams then store the gathered asset information, which can range from 200 to 2000 files depending on project size and complexity, in their PDMS, which is not linked to the district’s legacy systems. Contractors also deliver asset information (stored in about 10,000 to 50,000 files) to project teams, usually as PDF files and CAD drawings, which is then distributed by project teams to relevant districts following a validation and verification procedure. Districts then input this distributed asset information into their own legacy systems.
Data collection
Our principal data set composes of observations collected by the first author from November 2019 and continuing until the digital innovation program’s conclusion in December 2022. Her first observations in November 2019 were of workshops organized by project teams to prepare the tender of two infrastructure projects participating in the program. Then, from May 2020 until December 2022, she was installed in the organization as a temporary employee, given an internal email address and access to the organization’s intranet, and invited to all the regular meetings of the new digital innovation unit (DIU) created for the planning and execution of the program. The unit was composed of a program director, a handful of top-level managers, and several sub-units, each headed by digital innovation managers who were responsible for the delivery of individual, but highly related, digital innovation projects within the program.
Timeline of observations.
Overview of archival data collected.
Data analysis
Our data analysis process began by composing detailed case narratives describing how AMOrg’s digital innovation program (DIP) had developed over time, following the guidelines produced by Pettigrew (2012). This narrative analysis first helped us in understanding the context of the organization and the multiple, intricately related digital innovation projects in the DIP. Second, it later helped us in tracing events that led to coded, equivocal situations that consequently aided us in uncovering the tensions behind these equivocalities (Langley and Abdallah, 2011).
The coding of the collected documented data (field notes, interview summaries, and archival material) went in parallel with creating the narratives following an open coding approach. For this, we used the qualitative data analysis software package ATLAS.ti. We began the coding by compiling a list of terms that could indicate equivocality, based on a broad definition used in the literature (Locke et al., 2020), such as ambiguous, confusing, unclear, unresolved, and vague. As data collection continued, we also began to code the disagreements and misunderstandings that we observed as equivocality. Similar equivocalities were grouped via axial coding. This was followed by iterative rounds of discussions of findings, coding, and regrouping equivocal situations, resulting in three main categories of equivocality: scope, needs and priorities.
Summary of approach to data analysis.
Summary of equivocalities and tensions in the approach to interoperability at the data level.
Summary of equivocalities and tensions in the approach to interoperability at the software level.
Summary of equivocalities and tensions in the approach to interoperability at the IT level.
To analyze the impact of equivocal events on approaches to interoperability, we tracked the progress of identified instances of equivocality over the course of the study to observe how actors coped with them and whether or not these equivocalities were resolved over time. We then drafted our report on the three categories of equivocality – scope, needs, and priorities – that persistently impeded AMOrg from achieving interoperability. We will delve into these categories in detail in the Findings section. Specifically, we will expound on how these equivocalities emerged in the three approaches to interoperability at the data, software, and IT levels. First however, in the section below, we describe AMOrg’s digital innovation program and outline three digital innovations that corresponded to the organization’s three approaches to interoperability.
AMOrg’s approaches to increase interoperability
In 2019, a Digital Innovation Program (DIP) was initiated with the goal of enhancing interoperability across the fragmented systems utilized by districts and projects, as detailed in the case description. This program aims to foster interoperability at the data, software, and IT levels, ultimately enabling data-driven asset management. An emergent strategy was adopted in which high levels of self-organization and coordination were left to the DIU’s sub-units in opting for an agile way of working. This meant that digital innovation managers would together decide on intermediate goals for one another and shape the planning for each sub-unit every 3 months (termed program increment planning). During these sessions, each digital innovation manager’s priorities and planned activities would be discussed and agreed upon.
The aim of the program was to develop three digital innovations that would link and integrate asset data in existing legacy systems at three different layers (data, software, and IT). These three digital innovations were (i) an Object Type Library (OTL) targeting the data level, (ii) an asset information needs repository (AIN Repository) targeting the software level, and (iii) an asset management platform (AM Platform) targeting the IT level.
The OTL aims to increase interoperability by offering a data standard and would contain modelling rules and relation types that would supplement global and national semantic agreements to account for all organization-specific concepts (see Figure 1). It would prescribe content and relationships (ontology) and hierarchical structure and terminology (taxonomy) for each object (i.e. asset type, such as road, bridge, tunnel, flood barrier, lock, or weir). Objects would contain attributes, relationships to components, geometric data, and metadata that would be uniform across the entire organization. By using the OTL, all the organization’s asset information that was stored and managed in the districts’ legacy systems would share the same meaning and structure. It could also increase interoperability between the PDMS to the legacy systems, streamlining the flow of asset information from regional districts to projects and to contractors and back. AMOrg had been developing the OTL for about 7 years prior to the start of this DIP and had already prescribed its use to contractors on ongoing infrastructure projects. This meant that contractors were obliged to deliver asset information that was structured according to the OTL. The OTL in relation to global and national semantic agreements and to the AIN Repository and AM Platform.
However, implementation had to date not been successful. The contractors found it too complex, and it was unclear both internally and externally how objects’ attributes should be correctly input, as the input specifications only defined input values without explaining the context for these values. Moreover, although the OTL was prescribed for external parties, the standard was not yet used internally by districts because the OTL failed to account for the differences in information management (at the semantic, syntactic, and software levels) followed by the districts. This issue made the OTL essentially nonfunctional in linking the PDMS and existing legacy systems. In this new digital innovation program, the digital innovation unit aimed to simplify the OTL and clarify how attributes should be correctly entered by linking them to the asset information needs of districts.
To link the OTL with the asset information needs of districts, an asset information needs repository (AIN Repository) was to be developed. As managers of infrastructure assets, AMOrg needs to know the configuration of assets in its territory (what is out there?) and their condition (do they still meet standards?). A distinction can be made between static information (e.g. dimensions, types of materials, and construction drawings) and dynamic information (e.g. decay, damage, and malfunctions). Contractors play a major role in delivering this information. The ‘asset list’, an extensive checklist indicating what information should be provided for each region, was commonly used to request information from contractors. The list also indicated in which legacy system the information is stored and in what format. Currently, it contained little dynamic information, even though this information is particularly relevant to asset managers for assessing performance. Moreover, information needs were expressed in terms of the software entry fields of the existing legacy systems. Consequently, the DIU aimed to uncover districts’ actual information needs independent of existing systems and develop a repository of needs that would be uniform across all districts. Interoperability can be increased at the software level by linking the legacy systems through their software entry fields. In the AIN Repository, needs would be defined for each asset type and related to asset information processes and products. This repository will then serve as the basis for the attributes included for each object in the OTL.
A new asset management platform (the AM Platform) was also being developed to replace the PDMS, which was not linked to the districts’ legacy systems. From this platform, asset information in the districts’ legacy systems could be accessed and filtered by project, and one would be able to directly enter information and update the legacy systems with new asset information delivered by contractors. Interoperability among the legacy systems can then be increased by the platform by combining the outputs from the different systems. In developing this platform, the digital innovation unit collaborated with the project-based line through two separate pilot projects (Pilot A and Pilot B). In this way, developers had direct access to project data, which they used to validate the platform, and project teams could shape the platform according to their needs.
By closely following AMOrg’s digital innovation program, we observed that underlying organizational tensions surfaced as three major types of equivocality: scope, needs, and priorities. Below, we describe in detail the equivocalities observed and relate these to the underlying organizational tensions during the development of three digital innovations: (i) OTL, (ii) AIN Repository, and (iii) AM Platform.
Findings
Tensions and equivocalities in the OTL (data level)
The biggest challenge to the development of the OTL was the autonomy of regional units in fulfilling their asset management tasks. AMOrg was able to prescribe the OTL to its external contractors through contractual stipulations. However, consensus among the regional units was needed to prescribe the OTL internally to the districts. Since national semantic agreements prescribed modelling rules only for the top-level ontology and for generic concepts, each regional district was free to fill in the specifics and thus ended up using varying structures and terminology for elements and construction parts. As such, each district’s legacy systems were set up with their own specific modelling rules. For example, one district had labelled an asset type as ‘viaduct’ and an element as ‘fulcrum’, while another district labelled these as ‘bridge – dry’ and ‘pillar’, respectively. Some districts modelled multiple fulcrums and grouped these under one pillar, while others modelled one fulcrum to represent the full set and placed it under one ‘support’. There were no clear uniform preferences across the whole organization. Districts resisted the OTL if it meant that they would have to make changes to the set-up of their legacy systems, a task for which they lacked the necessary resource capacity. Moreover, digital innovation managers found it difficult to organize a route to consensus because districts did not have a consistent role assigned for taxonomy management. Some districts had assigned this task to their data owners, others to their information provision managers, and some to nobody. As one digital innovation manager said: ‘You are dependent on the benevolence of the region since, formally, there is no one responsible for taxonomy management’. The autonomy of regional districts thus put a strain on centrally coordinating asset information through uniform organizational standards.
This organizing tension between centralization and sub-unit autonomy surfaced as equivocality in the priorities of the DIP. It was unclear to the digital innovation managers where the root of the interoperability problems lay and thus where to start addressing them. The development of the OTL was highly intertwined with more profound matters in the organization that needed to be resolved before the OTL could be further developed. One of these was the question as to what asset information AMOrg really needed, which was often raised during the DIU meetings we’ve observed. For example, to what extent should they break down their asset information (e.g. to the level of individual fulcrums or to the level of pillars) and which purposes does each piece of information serve?
Another challenge to the development of the OTL was its continuing evolution after being implemented in projects. Throughout the DIP, the OTL was continuously being revised and supplemented. New asset types, attributes, and relations were gradually added to the library (see, for example, an excerpt of the OTL object ‘viaduct’ in Figure 2). We observed during project tender preparations that project teams found it difficult to understand and estimate the consequences of ongoing modifications to the OTL on their own project, which we categorized as equivocality in the scope of the OTL. This equivocality required project managers to collaboratively construct a plausible sense of what would likely happen in order to define and organize their next course of action. Excerpt of an object in the OTL.
However, what these changes would be, how they were determined, and when they would take place remained unclear. The DIU often revised or supplemented the OTL if it received feedback from project teams that things were faulty or lacking in the OTL. Conversely, it was not always clear to a project team that the OTL should be augmented or modified because errors in asset information delivery could also be the mistake of the contractor. Furthermore, changes in the OTL often required changes in work procedures and the project contract, which were then vulnerable to contractor opportunism. As a digital innovation manager stated: ‘the contractor must come up with a transition plan for the moment that AMOrg is ready to migrate to the new situation [with a new version of the OTL]. A request for change can be submitted if the provisional posting turns out to be insufficient for the transition. But when is this moment?’ As such, it was equivocal to both the DIU and the project team where the boundaries lay in the scope of the OTL.
Underlying this equivocality in the scope of the OTL was an organizing tension between integration and adaptability between the DIP and construction projects. Project managers aimed to specify deliverables with clear boundaries so that contractors could accurately estimate associated costs and capacity. However, the development of the OTL – fraught with its ongoing augmentations and modifications – demanded flexibility and adaptability from the contractors, which came at a price. Determining strategic actions that best responded to this organizing tension required project managers and digital innovation managers to collectively make sense of the digital innovation process and determine its impact on a project, as well as define possible limitations on changes in the OTL.
To summarize, we observed two major equivocalities that disrupted the development of the OTL: equivocality in priorities of the DIP and equivocality in scope of the OTL (Table 4). Behind these equivocalities lay tensions in organizing that the DIU had to grapple with: centralization versus sub-unit autonomy and integration versus adaptability. These organizing tensions – occurring at the organizational and project levels – slowed progress with the OTL’s development and consequently challenged interoperability at the data level.
Tensions and equivocalities in the AIN Repository (software level)
A fundamental input for the OTL is the AIN Repository, a database of asset information requirements for each object (asset type) and its characteristics (attributes) used to connect heterogeneous software through their entry fields. Asset information requirements were dictated by asset managers of regional districts for the conservation and management of infrastructure assets. Through this repository, users (e.g. a project team or contractor) can gain insight into a needed piece of information’s purpose through an extensive overview of related information concepts. Information concepts are used in operational and tactical asset management processes and products (see, for example, an excerpt from the database entry for the ‘failure cause’ information concept in Figure 3). Objects in the OTL should be linked to the AIN Repository to provide clarity as to how the attributes of objects should be correctly entered (e.g. what, how detailed, in what form, and how often). Example of an information concept in the AIN Repository.
One of the challenges the digital innovation unit encountered in developing the repository was equivocality in the needs of asset managers. This equivocality in users’ needs meant that the information given by asset managers on their needs did not provide clarity as to what they actually needed. To overcome this, digital innovation managers had to edit and reframe the information provided to make sense of the asset managers’ needs. Behind this equivocality lay a learning tension between the old and new systems and, often, asset managers would frame their needs in terms of the legacy systems they were currently using. For example, asset managers referred to the asset list as a specification of their information needs. However, the list did not reflect the actual information needed for a particular object at a particular time. To determine the actual information needs, the DIU had to conduct numerous interviews with asset managers in various roles. Many interviews were necessary because it was unclear who in a district should specify the information need, with asset managers pointing fingers at one another. Some asset managers could not clearly indicate in which AM process a piece of information was used. As one digital innovation manager put it: ‘The distance between the daydreamer and the user is great. That remains a challenge… many users are still very traditional’. This made it time-consuming for the DIU to make sense of some users’ information needs.
Digital innovation managers criticized asset managers for equivocating over their information needs. Indeed, asset managers had the reputation within the DIU of not knowing what they want. Moreover, asset managers were also criticized by project teams for having incomplete and/or outdated information in their legacy systems. During the development of the AM Platform, one project team did not see the need to combine the output of the legacy systems since these had incomplete and/or outdated asset information. These criticisms of the asset managers intensified their resistance to the DIP. Asset managers tended to focus on getting their legacy systems up-to-date and put little or no resources into participating in the digital innovation process. In one case, a district went as far as to conduct their own inventory of their asset information needs instead of collaborating with the DIU. Recursive cycles proceeded from this tension over belonging, in which asset managers’ unwillingness to cooperate reinforced the negative opinions of digital innovation managers towards them. This belonging tension manifested in even greater equivocality in users’ needs, as it hindered digital innovation managers from discerning the needs of asset managers.
Summarizing, we observed that equivocality in users’ needs hindered the development of the AIN Repository (Table 5). More information about users’ needs does not necessarily resolve the equivocality. Rather, actors involved in the digital innovation must also make sense of their own needs and how they overlap or clash with those of others. When users’ needs conflict, clear priorities are required to determine which needs should be satisfied above others. Moreover, digital innovators must translate the needs of each user group based on the user’s current frame (needs based on existing routines) to the organization’s imagined future state (needs translated to software functionalities). Two tensions lay behind this equivocality: old versus new and self versus others. On the individual/team level, a learning tension – embedded in organizational routines – between old legacy systems and new digital tools and standards inhibited regional asset managers from learning how to adjust their information needs to the future situation. At the organizational level, a belonging tension surfaced as a gap between the asset managers and the digital innovation managers that made it harder for the latter to progress the AIN Repository’s development. These two categories of equivocality challenged the organization’s approach to interoperability at the software level.
Tensions and equivocalities in the AM Platform (IT level)
Once asset information is structured through the OTL, project teams can use the AM Platform to access and filter information they need for their projects. The AM Platform could then increase interoperability by combining the outputs of different systems in a shared platform. A pilot project (Pilot A) was started to identify users’ needs and determine which IT capabilities should be built into this platform. The plan was to develop a first version that would be ready a year later for use by Pilot A’s project team and its contractors. However, the AM Platform was not finished on time; the main obstacle being combining the outputs of the legacy systems. Before the AM Platform was further developed, a team of digital innovation managers worked together to test whether it was possible to combine the outputs of the legacy systems using the outputs made available by Pilot A.
The test results showed that most outputs could be combined, except for the outputs from one specific legacy system that used a significantly dissimilar asset management taxonomy from the others. Furthermore, the legacy systems’ outputs had to be tweaked to enable combination. From the perspective of some digital innovation managers with asset management backgrounds, this meant that the test resulted to a failure. As one of these digital innovation managers involved in the test noted in a meeting we’ve observed: ‘Should we make it work technically or let it work properly? Someone says it works technically, but does that help us? It was quite unclear what the purpose was. If you ask different people, the answer may be different. But, if the question is, is it usable? Then the answer is: not yet’. Another digital innovation manager similarly remarked in the same meeting: ‘In one legacy system it is [represented as] two lines, in another it is a point, and in another it is one line. What choice will you make? For the test, I made many decisions to make it work technically. However, the user of the information must determine what the information should look like. For example: do I want to have insight into different asphalt layers? Because my client is, for example, someone who must sprinkle salt. This person would have a nice GIS that can show where each asphalt is located and determine how much salt and where to spread it. But we’ve made many choices and tweaked the legacy systems to make it work. Someone else might have made a different choice’.
On the other hand, digital innovation managers who had an IT background and were involved in the test viewed the result as a success. According to them, the AM Platform worked technically, but the boundary conditions to make use of it were not yet in place. One of these digital innovation managers expressed this clearly: ‘The concept of this test is well known in the IT world. It is normal to do multiple quick tests throughout the development. It’s meant to check if the various systems can be technically combined.… That’s why we didn’t involve a [construction project] contractor in the test, testing usability [by the contractor] is a different test’. Throughout the process, several sessions were organized to clarify the objectives. However, at the start of each week, a long discussion would commence about a sentence or a term that had been put down on paper the previous week. Moreover, the digital innovation managers all had equal authority: no one had the power to make certain choices or say which route the test should go. Decisions were taken based on consensus. However, despite almost half a year of near-weekly discussions, consensus was never reached on whether the result of the test was a success or not. Since no consensus was reached, no further actions to combine the outputs of the legacy systems were defined, further impeding interoperability.
The continuing disagreement among the digital innovation managers indicated the presence of a deeper organizational tension between organizing and performing embedded in the DIP’s strategic approaches. Digital innovation managers with an asset management background sought to involve users in adjusting the legacy systems in order to gain their commitment, whereas digital innovation managers with an IT background sought to demonstrate the technical feasibility of the AM Platform and quickly deliver results. During the testing, this organizing and performing tension surfaced as equivocality in the scope of their tasks: was developing a technically feasible product enough, or should they also ensure that it could be implemented in practice?
A second pilot project (Pilot B) was then started to develop an AM Platform without combining the outputs of the districts’ legacy systems. The project team working on this pilot agreed that such a capability was unnecessary because they had already gathered asset information on their own having been aware that the districts’ legacy systems had incomplete and outdated asset information. Hence, the project team did not express any need for this capability. Moreover, the project team wanted to ensure that the AM Platform would be finished on time and thus sought to avoid problems that might arise from the legacy systems. As Pilot B’s technical manager emphasized during a project tender preparation workshop: ‘What does being a pilot project mean? We’re not trying out anything in our project, it is complex enough as it is’. However, asset managers expressed the need for a tool that could combine the outputs from the project and the districts’ legacy systems and thereby streamline the flow of asset information from the project to the district. As one of the asset managers involved in Pilot B remarked during the same workshop: ‘What is the added value [of this AM Platform] for us when we currently still have to fill in our own systems? And what capacity is needed from the regional district? We currently don’t have the capacity for additional tasks. I hoped that the main goal [of the pilot] would be: how to structure asset information in the project so that we can receive it properly, and not the other way around’. The demands of the project team thus competed with those of the asset managers.
This performing tension of competing demands surfaced as equivocality in users’ needs. The DIU found it difficult to make sense of users’ needs because diverse user groups were pursuing divergent organizational goals. This was evident from the many meetings that took place over almost a year trying to clarify the goals of Pilot B and determine which IT capabilities should be built in the AM Platform. Without the users generating a consistent representation of their expectations, it was difficult for the DIU to meet expectations. During the process, a split arose among the digital innovation managers. Some explored what projects needed, while others explored what asset managers needed. However, the digital innovation managers were not explicitly aware that this split had arisen. It thus became increasingly equivocal as to which needs should be addressed by the AM Platform. Ultimately, development of the AM Platform was suspended until the DIU could more clearly define its objectives.
Project teams and asset managers also, respectively, represented short-term and long-term organizational goals. Project teams had clear short-term deadlines, dictated by the renovation and replacement needs of infrastructure assets, and clear interests in making project tasks more efficient. Meanwhile, asset managers were preoccupied with managing maintenance tasks targeted at extending the lifespan of infrastructure assets that could extend over many decades. This performing and learning tension – digital innovation managers aiming to ensure successful projects in the present and, at the same time, build capabilities for the future – surfaced as equivocality in priorities. The emergent strategy adopted by the DIU left ample room for the multiplicity of views among the digital innovation managers concerning the priorities of their tasks. Some digital innovation managers prioritized serving the needs of projects and aimed to develop digital innovations that could be quickly implemented to improve current working processes in projects. Others took an asset management perspective, aiming to develop digital innovations that would strengthen the organization’s resilience to future challenges, such as the growing congestion on the national roads and waterways, and climate change. Significant changes, both internal and external to AMOrg, would be needed to realize such digital innovations. By aiming to increase interoperability among the districts’ legacy systems, digital innovation managers steered towards uniformity and the standardization of asset management processes in the districts. The AM Platform would only be useful to project teams once the asset information in existing legacy systems were harmonized and updated. Achieving this could take a long time.
Overall, we observed three equivocalities (Table 5) that hindered the development of the AM Platform and thus challenged successful interoperability at the IT level: equivocality in the scope of digital innovation managers’ tasks, equivocality in users’ needs, and equivocality in the priorities of the DIP. Underlying these equivocalities were three interrelated tensions that made it difficult for digital innovation managers to make sense of the situation and define collective goals and priorities: digital innovation process versus digital innovation outcome, project versus asset, and present versus future.
Discussion
Organizational challenges in the three approaches to interoperability
In this paper, we have sought to better understand the organizational challenges associated with various approaches to interoperability and the reasons behind these challenges using the combined analytical concepts of equivocality and organizational tensions. Our study of a public agency that aimed to develop its own standards and platform revealed equivocalities in scope, needs, and priorities that persistently challenged the successful development of the standards and platform. Underlying these equivocalities were coexistent tensions that were both inherent in the organization and emergent through the interactions between actors and the lack of resources at the regional districts (Figure 4). Below, we discuss the relationship among the challenges in each of the three approaches to interoperability and their outcomes. Relating approaches to interoperability, categories of equivocality, and typologies of tensions.
As one of the largest civil infrastructure clients in the country, the public agency has the potential to drive market adoption of standards independently. The idea behind developing the OTL – which aimed to increase interoperability at the data level – was to mandate specific modelling rules to contractors, thereby achieving interoperability among various infrastructure construction projects and the organization’s legacy systems. However, the development of the OTL was not successful. Equivocalities on the scope of the modelling rules and the priorities in establishing the standard disrupted the development of the standard. Despite the likelihood that these challenges may be considered unremarkable, it is important to note that previous studies on standard development in vertically organized ecosystems have primarily concentrated on design, acceptance, and enforcement issues (Lyytinen and King, 2006). The uniqueness of our contribution, however, lies in its exploration of these challenges in terms of equivocality and its underlying tensions.
The development of the AIN Repository was aimed towards increasing interoperability among legacy systems at the software level by linking the systems’ entry fields. The way legacy systems ask users for input is through entry fields, which therefore represent the information needs of operational tasks supported by the legacy systems and embedded in the organizational routines for asset management. However, linking entry fields of various systems with different underlying technologies proved to be challenging. The challenges posed by equivocality in user’s needs reflect similar challenges in consensus-building that have been discussed by previous studies (Farrell and Simcoe, 2012).
The public agency appeared to have struggled the most with developing a new platform that can combine outputs from multiple legacy systems. Disrupted by all three categories of equivocality (scope, needs, and priorities), digital innovation managers had to deal with a constellation of critical problems that were difficult to identify, understand, or address. Due to the complex relationship among the tensions underlying these problems, this approach to interoperability would require systemic solutions at the organizational level (Addo, 2022). This complexity is reflected on the growing amount of literature on platforms in organizational and business studies (Hodapp and Hanelt, 2022).
Theoretical contributions
The findings of our study add to the existing knowledge on interoperability in organizations in several ways. First, while our findings confirm the significance of tensions in digital innovations (Ajer et al., 2021; Gregory et al., 2015; Tamm et al., 2022; Wimelius et al., 2021; Yeow et al., 2018), we also found equivocalities present in particular approaches to interoperability that impeded actors from taking further action: (i) scope equivocality, (ii) needs equivocality, and (iii) priorities equivocality. The first equivocality – in scope – implies that boundaries of digital innovation projects can be blurred and debated. The second equivocality – in users’ needs – involves users who are diverse and find it difficult to articulate and agree on their needs. This echoes the challenges involved in interoperability approaches at the semantic level, as attempts to define uniform semantics for objects in the built environment are hindered by the different interpretations of actors on how buildings are defined and decomposed (Marche, 1991). This equivocality also reflects the less predefined and more distributed agency in digital innovation projects (Bogers and West, 2012; Lusch and Nambisan, 2015), a situation which is likely to produce long-term indecision as multiple actors with shared power and diverse goals are required to collaborate to reach decisions (Denis et al., 2010).
The absence of formal roles, in this case for taxonomy management, also exacerbated the distribution of agency and the need for leadership roles to take decisions and resolve some of the equivocality. Along with establishing formal roles, improving understanding on this equivocality can improve existing methods in requirements elicitation by enriching our understanding of reasons underlying conflicts in user requirements. This can aid digital innovation managers in facilitating a ‘constructive interaction between all stakeholders during the requirements gathering process, and also between all stakeholders and the system to avoid conflicts and problems of communication arising from different points of view’ (Pacheco and Garcia, 2012: 2178).
The final equivocality – in priorities – indicates that digital innovation projects can be highly interdependent, making it difficult to make sense of their relationships and determine priorities. The prioritization of activities in digital innovation projects will influence the resulting outcomes of each project. Such complex and dynamic dependencies between processes and outcomes are typical in digital innovations (Boland et al., 2007; Nambisan et al., 2017). As digital innovations play a significant part in many approaches to interoperability, these three categories offer valuable insights into the persistent challenges organizations face in increasing interoperability at the data, software, or IT levels. Furthermore, these empirical accounts of equivocality emphasize that while strategic equivocality can serve as a resource for facilitating collective organizational action (Jarzabkowski et al., 2010), when equivocality transcends the rhetorical stage and becomes entrenched, collective actions become fleeting as challenges persist. The persistence of equivocality can thus reveal the presence of deeper underlying organizational tensions. Our findings affirm the conclusions reported by Abdallah and Langley (2014) and Denis et al. (2010), while also offering additional evidence of the mediating role of equivocality in the necessary organizational change to attain interoperability.
Second, we found that these equivocalities are interwoven (as illustrated in Figure 4). We expand the categorization proposed by Sandberg and Tsoukas (2015) and argue that equivocalities are neither individual nor independent of each other. Our analysis shows that equivocalities are linked: the clarification of one requires some clarification of another. For example, during the development of the AM Platform, we found that needs equivocality was interwoven with priorities equivocality. Digital innovation managers that pursued the needs of project teams prioritized developing digital innovations that could be quickly implemented to improve current working processes in projects. Meanwhile, digital innovation managers that acted on the needs of asset managers prioritized building capabilities for the future and steered towards uniformity and standardization of asset management processes across the districts. Both equivocalities were linked with scope equivocality, where digital innovation managers disagreed about developing digital tools that worked technically as against gaining commitment to make the tools work in practice. These empirical findings describing the interwovenness of equivocalities emphasize the persistence of equivocalities regardless of the amount of information or of the communication channels among organizational sub-units (Ravishankar, 2013).
Last, this study offers a perspective from which one can study the interrelatedness of underlying tensions in approaches to interoperability. Using the concept of equivocality uncovered the connections among the underlying organizational tensions, as shown by how some equivocalities have a single underlying tension, whereas others have multiple underlying tensions. By studying equivocality, we were able to unravel this ‘system of entangled tensions’ (Smith and Lewis, 2011: 389) and capture the intricacies between tensions and equivocalities. Few studies have depicted such complex interdependencies, which is highly relevant as managing tensions individually is complex (Jay, 2013; Smith and Beretta, 2021). We encourage further research to investigate whether similar relationships between equivocality categories and types of tensions can be identified in different contexts. Additionally, it would be valuable to explore instances where such connections between these elements, which are absent in our data, are observed in other studies.
In summary, our contributions highlight the complexity of organizational challenges associated with various approaches to increasing interoperability. Our study aimed to uncover the ‘obscure landscape of antecedents’ that result to low interoperability (Hodapp and Hanelt, 2022: 415) and increase understanding of the ‘dynamic and fluid constellation of critical problems’ underlying the challenges to achieving interoperability (Baghizadeh et al., 2020: 132). By relating underlying tensions to categories of equivocality for three different approaches to interoperability, we show that achieving interoperability would require not only developing new standards but also promoting organizational sensemaking (Weick et al., 2005) and navigating tensions (Farid and Waldorff, 2022).
Practical implications
Our study also provides three practical insights. First, we found that it is vital to increase understanding of equivocality. Organizations would benefit from distinguishing situations that require clarity on values from those that require more information. This sensitivity towards equivocality could help organizations provide more appropriate responses to challenges rooted in confusion and conflict. Moreover, a sensitivity to equivocality can help organizations identify context-specific, intra-organizational challenges. Such insights complement earlier identified barriers to interoperability at the European, national, and inter-organizational level presented in existing models, such as the European Interoperability Framework of the European Union (2017) and the World Bank (2022) report on Interoperability: Towards a Data-Driven Public Sector.
Second, we would encourage top management to develop a roadmap to direct the development of interdependent digital innovations. This roadmap should communicate (possibly using visual representations) to all those involved which specific (intermediate) goals must be achieved and when, connect short-term and long-term perspectives (Siebelink et al., 2021), and explain how the individual digital technology developments relate to each other. At AMOrg, such a roadmap was lacking, permitting a plurality of views among digital innovation managers on the scope and priorities of the digital innovation program. This plurality contributed to tensions in both organizing and performing, which surfaced as equivocalities in scope and priorities.
Third, we also suggest that digital innovation managers map users’ journeys by compiling multiple user stories from various groups of users. User journeys visualize how users interact with a digital tool. The process of mapping user journeys can clarify to digital innovation managers which IT capabilities serve which user’s needs. As visual artefacts, user journeys can also assist users in reframing their needs from an old system to a new one (Comi and Whyte, 2018) and thus contribute to reducing needs equivocality.
Conclusions and suggestions for future research
This study set out to deepen insights into why organizations struggle to achieve interoperability from an organizational perspective, while still accounting for differences in approaches to interoperability at the data, software, and IT levels. Utilizing the combined concepts of equivocality and organizational tensions, we conducted an in-depth analysis of three major equivocality categories – scope, needs, and priorities – within our 3-year longitudinal study of an organization’s various attempts at achieving interoperability among its asset management systems. These cases of equivocality persistently hindered the organization’s efforts to enhance interoperability. We also discovered that these equivocalities are interwoven: clarifying one requires some clarification of another. Behind these equivocalities lay coexistent tensions that occur on three levels: individual/team, organization, and project. The relationship between these tensions and equivocalities explains why achieving interoperability remains very challenging for an organization. It would be interesting to examine in future research if these categories of equivocality with their underlying tensions also emerge in approaches to interoperability at other institutional levels, for example, across multiple governmental bodies and across member states of the European Union.
The most important limitation of this study is that its scope was limited to the challenges that emerge in various approaches to interoperability. Further research could take the next step and study how organizations can deal with the identified tensions and equivocalities to achieve interoperability. A possible avenue is through the Paradox System (Lewis and Smith, 2022), which proposes a set of tools for navigating persistent tensions. We therefore call on future research that explore how tools based on assumptions, boundaries, comfort, and dynamics (Lewis and Smith, 2022) help actors navigate persistent tensions in approaches to interoperability. Finally, considering the notably fragmented and standards-deficient nature of the construction industry that served as the backdrop for this study, we strongly encourage further empirical research into equivocality in organizations’ journey to interoperability in other contexts as well. While our study offers some insights into this, more research is needed to clarify its precise role in this process.
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
