Enterprise architecture operationalization and institutional pluralism: The case of the Norwegian Hospital sector

Enterprise architecture (EA) is a systematic way of designing, planning, and implementing process and technology changes to address the complexity of information system (IS) landscapes. EA is operationalized when architecture visions move towards realization through concrete projects. We report a case study on the dynamics of operationalizing EA in the Norwegian hospital sector by exploring different EA project trajectories. Our empirical context is an institutionally pluralistic setting where multiple logics coexist. We show that the distinct logic of EA is added to the institutional context and we find that tensions among existing medical, technical, and managerial logics and EA principles and assumptions emerge. We contribute to the under‐researched topic of EA operationalization by suggesting a model that demonstrates how the meeting of multiple institutional logics can lead to varying degrees of differentiation or even disassociation from EA visions during decision‐taking in projects. Furthermore, we advance extant research on IS projects' implementation in institutionally pluralistic settings by providing an empirical account of actors' interactions and project leadership arrangements that contribute to the persistence of coexisting logics in a dynamic equilibrium.

visions move towards realization through concrete projects.
We report a case study on the dynamics of operationalizing EA in the Norwegian hospital sector by exploring different EA project trajectories. Our empirical context is an institutionally pluralistic setting where multiple logics coexist. We show that the distinct logic of EA is added to the institutional context and we find that tensions among existing medical, technical, and managerial logics and EA principles and assumptions emerge. We contribute to the underresearched topic of EA operationalization by suggesting a model that demonstrates how the meeting of multiple institutional logics can lead to varying degrees of differentiation or even disassociation from EA visions during decision-taking in projects. Furthermore, we advance extant research on IS projects' implementation in institutionally pluralistic settings by providing an empirical account of actors' interactions and project leadership arrangements that contribute to the persistence of coexisting logics in a dynamic equilibrium. particularly challenging (Gandhi & Ramaswamy, 2016;Grisot & Vassilakopoulou, 2015;Romanow, Cho, & Straub, 2012). Norwegian hospitals initiated the use of EA for designing and governing technology and processes more than a decade ago. However, despite the potential benefits and the governmental mandate on EA introduction, delays and implementation challenges have been experienced.
Specifically, we investigate the activities of the actors participating in different project teams involved in a variety of EA-driven initiatives. Through interviews and secondary data (strategy documents, healthcare management reports and guidelines), we gain insight into the dynamics of EA operationalization. Analyzing our empirical material, we show that the distinct logic of EA is added to the institutional context and we demonstrate how its interplay with coexisting logics shape EA outcomes. In the complex setting studied, phenomena of institutional pluralism emerge as actors relate to multiple logics to achieve different goals.
Our study contributes to EA implementation research showing that EA can itself be invoked as a distinct logic along other coexisting logics. Tensions emerge among the different established logics and the EA logic when concrete projects aim to take EA from the strategic level towards operationalization. Building on these insights, we suggest a model that shows how coexisting logics stand in tension maintaining their distinct character while allowing local resolutions that shape EA operationalization. Furthermore, we advance extant research on IS project implementation in institutionally pluralistic settings by showing how actors grapple with emerging tensions during project deliberations about possible courses of action. Through deliberations actors reach local resolutions. These allow projects to advance and coexisting logics to persist in a dynamic equilibrium. Our study provides a rich empirical account of actors' interactions and justifications responding to calls for research on the practical interplay among distinct logics in a field with a wide range of logics (Hansen & Baroody, 2020) and especially on the impact of different logics on the development of concrete system functionalities (Berente, Lyytinen, Yoo, & Maurer, 2019).
The rest of this paper is structured as follows. After this introduction, we present the theoretical foundation of our research. Then, we describe the empirical setting and explain the research method. We continue with the presentation of our findings: we present the rationale for introducing EA, the deliberations entailed in project decisions and the assumptions, principles, and sources of legitimacy for the EA logic. Then, following the sequence of the research questions, we identify specific types of tensions responding to the first question and we continue by showing how the operationalization of EA is shaped by the ongoing management of these tensions responding to the second research question. We then discuss the findings, propose a model that captures the dynamics of EA operationalization and point to theoretical and practical implications. Finally, we point to future research directions and conclude the paper.

| Working with multiple perspectives and enterprise architecture
Over the last decades, the IT landscape has vastly changed. The IS portfolios in organizations are more complex and heterogeneous than ever and the interdependencies between systems and organizational processes are becoming tighter (Hustad & Staverløkk, 2013). To navigate this complexity, practitioners and researchers have advocated EA as a systematic way of designing, planning, and implementing process and technology changes (Bradley et al., 2012;Venkatesh et al., 2007). EA is an organizational-technical approach that seeks to coordinate, integrate, and align the multiplicity of business and IT initiatives in organizations. EA describes the processes, their supporting data, and applications, as well as all related information and communication technology (ICT) arrangements (Bernard, 2012).
Using EA, organizations can map their current state, define a desirable future for their processes and systems (target architecture), plot the path to achieving the target, and implement concrete projects towards the target (Tamm, Seddon, Shanks, & Reynolds, 2011). Overall, EA is a holistic, long-term, and top-down approach (Bernard, 2012;Jonkers et al., 2006;Ross et al., 2006). Extant literature highlights the potential benefits of EA, but only limited empirical research has assessed EA benefit realization (eg, Kappelman, McGinnis, Pettite, & Sidorova, 2008;Schmidt & Buxmann, 2011), and it is not easy to find a successfully developed EA in an organization (Banaeianjahromi & Smolander, 2019). Overall, the perceptions about EA benefits vary significantly between executive-and operational actors (Lange, Mendling, & Recker, 2016). Tamm et al. (2011) distinguish between benefits that can directly flow from EA and benefits that can be obtained from the implementation of the EA plans. For instance, benefits gained from standardization can only be reaped after projects are implemented. However, EA can have direct communicational value by facilitating communication between business and IT (Armour, Kaisler, & Liu, 1999;Gong & Janssen, 2019;Valorinta, 2011). Benefits can directly flow from EA before the completion of projects if used to encourage cooperation (Pereira & Sousa, 2004;Richardson, Jackson, & Dickson, 1990). EA can bring together business and technology viewpoints and concerns, making boundaries between different communities within organizations permeable, enabling knowledge sharing and comprehensive negotiations (Dale & Scheepers, 2019). EA in itself does not provide value, but is an instrument enabling the creation of value (Gong & Janssen, 2019). It is the interplay between EA methodologies, organizational, and social factors that produce particular outcomes. EA implementation is influenced by tensions and interactions among actors in its institutional context (Ajer & Olsen, 2018;Hjort-Madsen & Pries-Heje, 2009;Janssen, 2012). Investigating the direct role of EA within pluralistic organizations entails studying concrete action-taking during EA operationalization. Only few research studies have investigated the operationalization stage in which organizations start the projects that are needed to reach the target situation (Banaeianjahromi & Smolander, 2019). This is probably related to the scarcity of projects that operationalize EA. When starting EA initiatives, most organizations already have multiple IT systems in place, and important architectural decisions for these systems have typically been made in the past (Hylving & Bygstad, 2019); thus, developing detailed EA blueprints can be a tedious and lengthy process. Research has shown that a significant proportion of EA initiatives document only the current state of operations (Winter, Buckl, Matthes, & Schweda, 2010) and that many organizations fail to progress beyond documentation, which often leads to EA initiatives dying out (Lange et al., 2016). Furthermore, the few researchers who have studied EA operationalization in projects tend to focus on the technical conditions associated with EA success or failure and, to a lesser extent, on the interpersonal interactions and dynamics during action-taking (Dale & Scheepers, 2019;Smolander & Rossi, 2008). EA prescriptions often prove to be inherently abstract, which is a consequence of their strategic nature and of aiming at a partly unknown future (Foorthuis et al., 2012). This renders EA prescriptions open to interpretation during the EA operationalization process. Foorthuis and colleagues studied organizations that aim to ensure that new projects comply with EA principles and found that these organizations take measures including carrying out project compliance assessments and providing project assistance through expert advice and EA templates (Foorthuis, Van Steenbergen, Brinkkemper, & Bruls, 2016).

| Healthcare as a site of institutional pluralism
An institution can be defined as "shared rules and typifications that identify categories of social actors and their appropriate activities or relationships" (Barley & Tolbert, 1997, p. 96). Social actors can be individuals, groups, organizations, or even larger assemblages. Institutional theory "highlights cultural influences on decision making and formal structures. It holds that organizations, and the individuals who populate them, are suspended in a web of values, norms, rules, beliefs, and taken-for-granted assumptions, that are at least partially of their own making" (Barley & Tolbert, 1997, p. 93). The institutional logics' perspective represents a stream within institutional research that emphasizes social actors and their belief systems in maintaining and changing organizations and institutions (Scott, 2014;Thornton & Ocasio, 2008). For our study, we adopt Thornton and Ocasio's (1999, p. 804) definition of institutional logics as "the socially constructed, historical patterns of material practices, assumptions, values, beliefs, and rules by which individuals produce and reproduce their material subsistence, organize time and space, and provide meaning to their social reality." Prior research has recognized the increasing prevalence of multiple logics within organizations (Besharov & Smith, 2014;Smets, Jarzabkowski, Burke, & Spee, 2015). This phenomenon is called institutional pluralism (Kraatz & Block, 2008); it occurs when organizations are sites where multiple logics are active and no single belief system can perpetuate its dominance. For instance, in universities, the logics of teaching and research are simultaneously active, and although the two can be mutually facilitative, tensions abide (Kraatz & Block, 2008). Multiple and sometimes conflicting logics also exist in healthcare, where tensions typically emerge between medical professionalism and managerialism (Reay & Hinings, 2009;Scott, 2000). In hospitals, medical professionalism is oriented towards the quality of care, while managerialism is mainly occupied with efficiency.
The landscape of IS in healthcare has been shaped by the institutional pluralism of the domain. The institutional complexity poses challenges for healthcare IS adoption and use, and prior research has shown how system adaptations and workarounds can be traced back to the multiplicity of logics at play (Jensen et al., 2009;Plumb et al., 2017). Hansen and Baroody (2020) studied the adoption and use of electronic health record systems in hospitals and identified four prominent logics: medical professionalism, private sector managerialism, technical design, and regulatory oversight. Bernardi and Exworthy (2019) studied IT innovation in healthcare and found that different types of innovation have different effects on the relationship between the institutional logics of managerialism, medical professionalism, and patient-centred care. Currie and Guah (2007) found that medical professionalism and managerial and market logics shaped the implementation of the IT programme for the national healthcare system in the United Kingdom. Heeks (2006) identified technical, managerial, and medical types as the three rationalities that shape health IS. Extending Heeks' work, Boonstra et al. (2018) elaborated on the IT professionals' logic, which expresses technical rationality specifically related to IT in hospital contexts. Table 1 provides an overview of key healthcare institutional logics identified in prior research. The logics are described along three different dimensions (assumptions, principles, and sources of legitimacy) that are adapted from the works of Hansen and Baroody (2020) and Berente et al. (2019). Assumptions are established beliefs about the nature of reality and means-ends relationships. Principles are the foundations for action-taking related to goals and values. Sources of legitimacy are bases on which actions are deemed desirable and appropriate.

Assumptions
The best decisions are made closest to the point of care (Hansen & Baroody, 2020).
Health information systems improve efficiency and reduce costs (Hansen & Baroody, 2020).
Prior IS research generally associates specific logics with specific types of actors (eg, Berente & Yoo, 2012;Boonstra et al., 2018). Actors with different functions and professional backgrounds are assumed to invoke different logics due to the differences in their work, education, and overall socialization patterns (Boonstra et al., 2018). Nevertheless, nascent IS research has shown that multiple institutional logics can influence the behaviour of actors that have complex roles as in the case of clinical managers that deploy multiple identities and their social position to facilitate IT innovation at the crossroad of multiple institutional logics (Bernardi & Exworthy, 2019). Empirical institutional research has shown that in everyday practices, actors do not always adhere to the logics of their professional groups but may invoke a mix of logics (Martin, Currie, Weaver, Finn, & McDonald, 2017;McPherson & Sauder, 2013;Waldorff, Reay, & Goodrick, 2013). Actors exercise discretion in their everyday use of the logics available in a domain, deciding which logics to adopt and for what purposes. In institutionally complex settings, actors may appear to relate to multiple logics simultaneously. Consequently, available logics are like tools that can be creatively employed by actors to achieve individual and organizational goals (McPherson & Sauder, 2013). For instance, management research in healthcare has shown how managers, project leaders, and nurses invoke both care and business-like logics when discussing healthcare practice innovation (van den Broek et al., 2014). These findings echo the conceptualization of institutional logics laid out by Thornton, Ocasio, and Lounsbury (2012), who posit that individuals learn multiple institutional logics that may be activated, depending on their applicability in specific situations.
The ability to accept the coexistence of multiple logics and work through them can be a source of creative energy in organizations; it can drive the questioning of assumptions, enable people to look beyond the obvious, support learning and resilience (Smith & Lewis, 2011).

| Study context
This study was conducted in the Norwegian hospital sector (Figure 1). In Norway, most hospitals are public and organized in hospital trusts. One trust can include several local hospitals. The trusts are allocated to four independent regional health authorities (RHAs) under the jurisdiction of the Ministry of Health and Care Services. The four RHAs collectively own a specialized organization for the strategic coordination, prioritization, and consolidation of hospital The Norwegian hospital sector (units covered by interviews noted in bold text) ICT across all regions. This organization is called the National ICT (NICT). Among the four RHAs, the South Eastern Region (SERHA) is the largest one. SERHA manages 9 hospital trusts that include 30 hospitals with 78 000 employees and an annual turnover of 82 billion NOK (ie, approximately 9 billion USD). SERHA is supported by its wholly-owned ICT service provider (the HospitalPartner). The Norwegian government promotes the use of technology for effective and efficient services, quality improvement and patient security. Two of the most important government directives that guide the development of digital health services are "The healthcare coordination reform" "establish EA as a strategic tool for hospital services" (NICT, 2012, p. 6). The rationale for establishing EA is explained in NICT's special report entitled "Practice of Enterprise Architecture in National ICT, Initiative 42.2" where it is stated that "the Enterprise Architecture's contribution is to ensure that the healthcare and healthcare sector's strategies, tools and change processes are viewed in conjunction to achieve desired results" (NICT, 2014, p. 5). Furthermore, the report defines The Open Group Architecture Framework (TOGAF) Architecture Development Method as the preferred method and clarifies that "the methodological descriptions shall be required for the National ICT's architecture function and projects and guide the regional architecture function and projects" (NICT, 2014, p. 41).
In 2013, SERHA started a large-scale portfolio of initiatives aiming to develop shared regional solutions for clinical and administrative hospital services (the Digital Renewal portfolio). The budget allocation for this is 6585 MNOK over 7 years (ie, approximately 725 million USD). The portfolio includes three programmes. One of them is the Regional Clinical Solution (RCS) programme for which an EA approach was decided in 2015. Nevertheless, it was not always easy to ensure that the different ongoing projects are making use of or are aligned to EA. In 2017, SERHA decided to adjust its project management method toolkit to specify how projects under the RCS programme should work with EA. The new toolkit introduced the requirement to prepare an architecture description in the concept phase of each project and to continue updating the description as the project evolves (Appendix A including Figure A1 provide additional information about EA in the RCS programme). RCS includes several large projects consolidating electronic patient record systems and implementing regional solutions for laboratory and radiology support. It is governed by a board that is responsible for organizing and staffing the various RCS projects aiming to ensure broad involvement of subject matter experts from the health trusts. Enterprise architects participate in all projects. The RCS board acknowledges the multifaceted character of the projects and is promoting a three-party project management structure covering clinical, managerial, and technical aspects ( Figure 2). Specifically, the typical project management team includes a project manager with a clinical background (coming from one of the hospital trusts), an assistant project manager specializing in management (coming from the HospitalPartner), and an assistant project manager specializing in IT (coming from a vendor).

| Research approach, data collection, and analysis
Our research is designed as an interpretive case study (Klein & Myers, 1999;Walsham, 1995) on the introduction of EA in the Norwegian hospital sector. In our study, we investigated the views, tactics, and approaches of different actors engaged in concrete EA-driven initiatives in Norwegian hospitals. The focus of our study is EA operationalization, in other words, the move from abstract principles and architectural schemas for processes and IT, to concrete system designs and procedure specifications. By conducting an interpretive case study, we sought to gain an in-depth understanding of EA operationalization in a real-life setting (Walsham, 1993). The seven principles for interpretive field research by Klein and Myers (1999) were followed as practical guidance. Appendix D, Table D1 provides an overview of how we followed the principles.
The context of our study was chosen for its institutional complexity. Healthcare is a multifaceted organizational field where multiple competing institutional logics coexist (Currie & Guah, 2007;Reay & Hinings, 2009;van den Broek et al., 2014). We were interested in exploring the tensions that emerge when the holistic EA approach is introduced in institutionally complex settings and to identify how these tensions shape the operationalization of EA. We performed four initial exploratory interviews with three enterprise architects (at the national, regional, and local trust level) and one senior manager from a hospital trust. This helped us gain an initial understanding of EA use and the EA approach in the research setting. After this, we proceeded with interviews about experiences with EA, projects and portfolio management, and the challenges of the holistic EA approach. As the research advanced, we narrowed down the study to the projects within the RCS programme. This focus allowed us to gather empirical data on on-going projects for which an EA approach was decided. The data were collected from November 2016 to the end of January 2019. The empirical data were collected via unstructured and semi-structured interviews. In addition, over 300 documents were collected and reviewed (these are presented later in this section and outlined in Appendix C; Tables C1   and C2).
In total, 30 in-depth interviews with 29 interviewees were conducted ( Table 2). Three of the participants were interviewed twice, and on two occasions, two persons participated in each interview. The interviews were conducted in Norwegian and recorded and transcribed verbatim. The quotes included in this paper are translated into English from the Norwegian transcripts. We applied the snowballing technique by asking the initial interviewees to help us identify other participants who could provide rich information regarding the operationalization of EA and the ongoing projects (Coleman, 1958;Heckathorn, 1997). In addition, we identified relevant participants in SERHA's websites.
We started the data collection by interviewing mostly enterprise architects and senior managers and expanded to the project management teams, including the clinical specialists with managerial roles and the participants with a more technical orientation. Table 2 shows that many of the interviewees combine IT, management, and/or clinical backgrounds. Nearly half of the participants have mixed backgrounds, indicating that the domain's complexity was accounted for in project staffing decisions. The deployment of EA initiatives in organizations is typically based on a top-down strategy (Hylving & Bygstad, 2019). Therefore, we decided to collect data across levels. Interviews were F I G U R E 2 Three-party project leadership within the regional clinical solution (RCS) projects conducted in the national coordinating body (NICT), the South Eastern Region (SERHA and HospitalPartner), and three hospital trusts.
During the interviews, we avoided leading questions or questions that might yield stylized answers, and when possible open-ended "how" and "why" items were applied (see further details in the interview guide, Appendix B). This way, the interview transcripts became rich with lengthy statements, amenable to the analysis of the interviewees' perspectives. The interviews were mainly dialogue-based (Myers & Newman, 2007), and a narrative approach was adopted in several of them to explore specific stories from projects experienced by the interviewees. The narrative approach encourages participants to share what they think is important (Cassell & Symon, 2011). These stories were documented as project vignettes. The interviews included topics on EA operationalization including EA perceptions, practices and management, the role of enterprise architects, and issues about national coordination and collaboration in hospital IS. Furthermore, the interviews covered project-specific topics about the development, use, and value of EA artefacts; the involvement of different actors; and the progress of actual project work.
Over 300 documents related to the projects, the introduction of EA in the hospital sector, and the overall strategy and policies for hospital IS in Norway were reviewed. Out of those, 179 were issued by SERHA. The documents were used to gain an overall contextual understanding and to obtain detailed information about specific aspects of the projects. Additionally, the documents contributed to the preparation of the interviews as they provided background information about project participants, project methods, and applied frameworks. The significant volume of the documents indicates the heavily regulated hospital IS, the well-documented projects, and at the political level, the strong interest in modernizing healthcare information infrastructures over the last decade. The reviewed documents include policy papers and reports issued by the parliament, the Ministry of Health and Care Services, the directorates, NICT, and SERHA (see further details in Appendix C; Tables C1 and C2).
The flexibility of the interpretive approach allowed us to gradually obtain a sophisticated picture of the EA operationalization efforts. The interview transcripts were read and re-read several times by the authors. A synopsis with crucial findings, preliminary graphics, and sample quotes was developed. We approached the data by first identifying key tensions reported by the interviewees or documented in the analyzed documents. We followed a "pattern-inducing" approach (Reay & Jones, 2016), which involved an interpretive analysis of the beliefs expressed in verbal or written discourse and the norms observed in behaviours and activities. The approach was inductive, and text segments from the interview data and documents were categorized to reveal patterns. The analysis comprised a bottom-up process to identify the patterns of the logics invoked by different interviewees during conversations and explanations. These were compared and contrasted with the key aspects of logics (medical, managerial, and IT professionalism) documented in the extant literature. Principles and assumptions related to EA were also coded and consolidated to outline the EA logic which was identified as a separate pattern.
In interpretive research, the researcher is part of the context, aiming to understand phenomena through the meanings that people assign to them (Orlikowski & Baroudi, 1991). Understanding is participative, conversational, and produced in a dialogue, not something reproduced by an interpreter through an analysis that seeks to "make sense" of a social action (Bernstein, 1986;Gadamer, 2000). As the data were analyzed to a large extent during the same period as the data collection, we had a lot of opportunities to discuss and develop the emergent understanding, together with the interviewees. Appropriate involvement of participants in the research process can enrich the interpretive process and increase the relevance of the findings (Bygstad & Munkvold, 2011;Klein & Myers, 1999). For instance, we shared manuscript drafts with the interviewees asking for their feedback.
The coding of our empirical material followed the principles of first-and second-cycle coding (Miles, Huberman, & Saldaña, 2014). By utilizing the software NVivo, the outcomes of the first cycle were further analyzed, grouped, and transferred into Excel forms. In the second cycle, the data from Nvivo and the synopsis were discussed, organized, and compared iteratively to identify emerging patterns. The empirical material was further systematized, with the data visualized and reduced (Miles & Huberman, 1994). Selected long statements were condensed to shorter sentences to grasp the essence of the texts and to generate themes by taking into account the overall sequences in the texts (Kvale & Brinkmann, 2009). A graphic overview of the data analysis process is provided in Appendix E, Figure E1. Overall, we followed a hermeneutical process of data collection, literature studies, and iterative analysis. In this process of sense-making, the concept of institutional logics was used as an analytical lens, and the principle of dialogical reasoning (Klein & Myers, 1999) supported the development of theoretical insights. The insights relate to the multiple logics at play and the EA operationalization dynamics.

| FINDINGS
In this section, we present the findings of our case study. First, we show that although there was a consensus about the general aims of EA (Section 4.1: Rationale about EA adoption), controversies emerged when EA visions moved towards realization through concrete projects (Section 4.2: Deliberations and decisions during EA projects). Drawing from these empirical findings, we then show that the distinct logic of EA is added to the institutional context bringing specific assumptions, principles, and sources of legitimacy (Section 4.3: The EA logic). Consolidating the empirical analysis, we respond to the two research questions outlined in the introduction. First, we identify three broad categories of tensions in the relationship between the logic of EA and established logics (Section 4.4: Analysis of tensions between the logic of EA and established logics) and then we show how the operationalization of EA was shaped by these tensions (Section 4.5: Tensions shaping the operationalization of EA). Overall, EA operationalization is continuously deliberated in the projects and shaped through case-by-case tension settlements.

| Rationale for introducing EA
While interviewing the participants, we discussed the reasons for introducing EA. The different interviewees provided similar reasons for using an EA approach for hospital IT and processes. EA was expected to facilitate fundamentals, such as interoperability, standardization, coordination, process support, and data management. The interviewees expressed similar views, irrespective of their backgrounds and roles. Table 3 summarizes these findings under seven categories. The standardization, data management, and interoperability and integration categories are system related. The process support category, along with coordination and collaboration, can be linked to healthcare delivery-related aims. Additionally, the participants also pointed to the potential of EA to facilitate managerial planning by mapping as-is and to-be states and looking beyond local needs. Interestingly, every participant, irrespectively of background and role, referred to a mix of system, healthcare and managerial planning aims. This reasoning echoes the argumentation found in official documents for the introduction of EA in the hospitals.
Although we found that the interviewees shared similar views on high-level EA aims, controversies were revealed when discussing how EA moved from the strategic level towards operationalization. The empirical data showed that the high-level objectives were not always followed in concrete project decisions and that tensions emerged.
One of the enterprise architects explained that it was not easy to make the practical decisions needed: "I felt that the management only pointed to ICT strategy for consolidation and standardization without going into nuances and what to actually standardize, while the clinicians fought against [standardization]." The section that follows presents three project vignettes that illustrate project-level deliberations and decisions.
These emerge when EA is moving from the strategic level towards operationalization. In this transition, abstract EA principles and schemas move to concrete system designs and procedure specifications.

T A B L E 3 Rationale for introducing EA, expressed in interviews Category
Standardization: to follow technical guidelines, best practices, and architectural principles.
Data management: to control data handling and flow, especially the master data.
Interoperability and integration: to facilitate exchange and reuse of data.
Process support: to ensure that information systems support the work processes (eg, for patient safety).
Coordination and collaboration. Coordination denotes assessing and adapting several relationships in relation to the whole. Collaboration is about actors working together towards a common aim.
Future (to-be) and Current State (as-is) mapping: to support the organization's strategy, suggest solutions and plan, while having an overview of the existing systems, the integrations in place, the interfaces, and dependencies.
Looking beyond: to understand that other units and actors are influenced by locally used systems.

| Deliberations and decisions during EA projects
Experiences from EA operationalization are presented in three project vignettes. Each of them focuses on a specific project within the RCS programme and illustrates the project deliberations that bring to the surface different logics.
4.2.1 | Vignette 1: Deliberations and decisions for the regional ambulance record project address, type of incident, name, and other details collected over the phone is automatically sent to the A-EHR in the ambulance. Then the record will be pre-filled, and time will be saved.
[…] Before, you had to write with a pen, sometimes when the car was in motion, name, address, where you picked up and where you delivered, when you arrived and when you delivered.
[…] You will now avoid duplication, and as names have slight differences in this country, it will be easier to get things correctly." The RCS programme board asked the project team to investigate the possibility of integrating the A-EHR with the hospitals' EHRs. This integration would allow the digital flow of information between the ambulance and the hospital systems eliminating the need for new data entry in the hospitals when the patient is delivered. Nevertheless, after some deliberations, the project team concluded that the output for the hospitals will simply be a PDF file. The project team suggested not to include integrations in the A-EHR scope to avoid the complexity, risks, and lengthy processes of interfacing the new system with different existing hospital EHRs and rather consider the integrations for further development at a later stage. The project team suggestions were approved by the management at SERHA.
The ambulance personnel involved in the project wanted to focus the effort on capturing information correctly ensuring that the information would follow the patient in an efficient and reliable way. This resonates with medical professionalism principles related to patient focus and healthcare quality. A member of the project management team explained: "The ambulance staff is concerned about efficient and smooth information registration in the ambulance, capturing what you see and experience there, and ensuring that the information is sent to the hospital and remains with the patient in the future." The regional ambulance record project prioritized simple functionality that can be swiftly deployed and relegated to the future complex integrations. In the A-EHR project, we observe the tension between the overarching EA aim for "One Citizen-One Record" (Norwegian Ministry of Health and Care Services, 2012) and the desire for immediate clinical utility and service quality improvement. A manager explained: "If you are to satisfy that everything can be transmitted digitally and seamlessly to different types of recipients, then it is a completely different project […] we shall be able to just transmit a record note as a pdf file to the hospitals' emergency rooms […] the hospitals' emergency units will get [the ambulance record] as a pdf […]this is much better than the handwritten paper with a ballpoint pen in an ambulance that is moving, a quality improvement." The members of the managerial team were involved in deliberations invoking the managerial logic that values efficiency, the IT logic that values secure and automated data flows, and the medical professionalism logic that values clinical utility. The deliberations led to suppressing the overall EA vision for "One Citizen-One Record" postponing system integrations for a later stage.

| Vignette 2: Deliberations and decisions for the pharmaceutical management project
A special project for uniform pharmaceutical management is included in the RCS programme. The aim of the project is to coordinate drug information across three applications within hospitals (the hospital EHR, the Critical Care system, and the Cancer Medication system) harmonizing the work nationally within the pharmaceutical area (South-Eastern-RHA, 2018b). Today, the information is scattered across systems, and clinicians lack an overview of each patient's drug use. Work processes across disciplines are fragmented, and the lack of information sharing requires manual duplication of drug information. SERHA started work on this project in late 2017, but the official start was in March 2018. The project is particularly challenging due to the fragmentation of the systems and the processes that it aims to address. One of the interviewees referred to the disputes that occurred when EA was discussed across projects: "Each of the applications wants control, e.g., the Critical Care system asks for full control, and they do not like to allow drugs to be managed by other systems. it is hard to get a common architecture because one is constrained by different vendor solutions." Although standardization and uniform medication handling across the different solutions are the aims of the project, these are far from straightforward, not only because of technical issues, but also because of singularities in clinical practices. For instance, the system used in maternity clinics allows midwives to manage medications, but this is not allowed in the Critical Care system. Furthermore, the Cancer Medication system covers not only drugs but also different types of support treatments (eg, non-pharmaceutical support for nausea).
From a medical professionalism perspective, the singularities of clinical practices need to be preserved. From an IT perspective, these singularities impede standardization and complicate coordination with the different vendors.
Furthermore, local tailoring of systems and procedures complicates managerial control across clinics and throughout hospitals. The project was put on hold as the actors engaged did not manage to reach a joint decision over a course of action.

| Vignette 3: Deliberations and decisions for the cancer medication project
The cancer medication project is also under the RCS programme. The project aim is the delivery of "a new, forwardlooking, and uniform service for medical cancer treatment. This involves standardizing work processes and cure definitions in the region across the health trusts. The solution is intended to meet the internal needs of the health trusts as well as the region's needs across the health trusts" (South-Eastern-RHA, 2015b). The cancer medication system will support medication requisition, preparation, administration, and documentation throughout the course of cancer treatment. The project started in 2013 with an expected duration of 7 years. It introduces a digital system in an area that has only been supported by paper documentation until now. The paper-based arrangements have allowed substantial variations in the different hospitals, and the project needs to grapple with the consequences. Reaching an agreement about common processes in the region has been challenging as explained by a member of the management team of the project: "There are differences in how different health trusts work; there are manual routines and no standardized regional procedures. So, it was a bit pragmatic, […] an example of this is the possibility for the pharmacy to prepare drugs in advance; we allowed this only for the inexpensive medication." The same interviewee provided another interesting example: "[At one hospital] it was common for doctors to request a treatment regimen and set up several cycles of the same treatment. Then, nurses approved the second iteration of the treatment and continued up to six treatments […] when coming to treatment number two, if the patient was in good shape, it was sufficient that a nurse signed […] There was a slightly different legal interpretation compared to other hospitals where nurses were not allowed to be the requester of such a treatment [...] In the digital solution, allowing a nurse to approve a treatment would not be correct. So, the project required changes in practice: doctors had to order each and every treatment separately." These examples illustrate that, in this project, medical professionalism prevailed when there were minor managerial implications. For instance, for medications that are not too expensive, some hospital trusts were able to implement local variations of the processes, allowing hospital pharmacies to prepare drugs in advance. However, when variations in clinical practices entailed regulatory risks (as in the case of nurses' involvement in medication requisition) the standardization vision was realized. Specifically, it was decided to implement for all hospitals a uniform process not allowing deviations, so, the nurses were no longer given the possibility to approve treatments in the new digital solution.

| The EA logic
The three project vignettes show the difficulty of materializing EA visions in concrete project decisions. The principles of EA were frequently debated as the projects evolved. Although the EA logic became available alongside other logics when introduced at the strategy level, tensions actually emerged during concrete projects when architecture visions moved towards realization. In Table 4

| Analysis of tensions between the logic of EA and established logics
The project vignettes show how moving from abstract principles and architectural schemas to concrete design decisions may be controversial and debated. During the interviews, different participants pointed out several tensions related to EA operationalization. We classify the identified tensions into three main categories and map them to the incongruences between the EA logic and the dominant logics in healthcare (medical professionalism, managerialism, "EA will contribute to a greater degree of goal achievement through a structured approach focused on holistic thinking and change capability and will provide common guidelines for the development of architecture and ICT solutions in the hospital service" (NICT, 2014, p. 3). "EA's contribution is to ensure that healthcare and healthcare sector's strategies, tools and processes are viewed in conjunction to achieve desired results.
There is an ever-increasing need for collaboration and mutual adaptation to other players in the sector and public administration in general. This is reinforced by new demands from patients and the public, these players must be involved in a completely different degree than before" (NICT, 2014, p. 5).
"I think [the EA approach] is an improvement; you are able to visualize and concretize the processes and the effects of the measures that are implemented, and what you expect to happen. [...] You see it more concretely, which means we make sure we talk about the same thing, and you make sure you are a little more aware of the consequences of what you do, so it's an awareness" (project manager and clinician). "The more we build up documentation and processes, the better reuse it will give in the future" (senior manager -IT background).
Principles: Holistic orientation Top-down planning for standardization and integration. Long-term thinking.
"EA is about how an enterprise is organized, how work processes are put together and how IT solutions are utilized.
[…] The purpose of a well-described and unified EA is, inter alia, to realize individual solutions in a holistic context, not separately. The purpose is to ensure a good connection between work processes and IT solutions and to avoid the establishment of information systems that do not talk together, so-called silos" (Difi, 2012, p. 3). "One vision for architecture practice in the hospitals to use EA in strategic work, in organizational and process development, in portfolio management, and in programs and projects.
[…] The architecture practice provides ICT solutions that support holistic processes in hospitals and the health sector in general. The architecture practice ensures standardization and collaboration across health regions and the sector" (NICT, 2014, p. 6).
"[EA] is valuable because you get an idea of the complexity -and this is actually important because you have so many elements. In such a box, there are so many lines you should relate to.
[…] It forces me to think that you have to do this so carefully; how else should one control the information?" (project manager and clinician). "It is about seeing things in context and prioritizing.
[…] For example, in implementing new systems and in relation to standards, reference models, and application platforms, − trying to associate this with stakeholders and users, everything must be connected in a way, − interactions between meta-models, building blocks, charts and stakeholders, everything must be seen in a context. TOGAF helps us and is a possible approach to seeing these relationships in the enterprise" (enterprise architect).

Sources of legitimacy: Executive Endorsement and Best practices
"The method to be used in National ICT projects will be based on TOGAF ADM, adapted to the hospital service and the needs of each project" (NICT, 2014, p. 41). "The development of models and frameworks based on EA will be fundamental for systematically developing the region's decision basis, regional prioritization and implementation ability" (South-Eastern-RHA, 2015a, p. 33). IT professionalism in this case are provided in Appendix F, Table F1.
The first tension is related to operationalizing the holistic thinking of EA. The established approach of addressing process and technology changes in a piecemeal, fractional way contrasts with the holistic orientation of EA. Although EA initiatives have wide organizational and technical scope, they are realized through bounded projects with specific timeframes and commitments so, it is difficult to keep a holistic overview. For instance, in the regional ambulance record project (Vignette 1), the project team decided to deliver a stand-alone solution that did not fit the vision for "One Citizen-One Record". This decision was made to avoid the complexity and the uncertainty of interfacing with different existing hospital EHRs. Furthermore, working with a holistic view of the organization makes it difficult to have everything specified upfront to calculate costs and budget resources. Having everything budgeted in advance is part of the traditional managerial approach that is challenged. One of the enterprise architects explained: "It is a fundamental difference […] you have to think that not everything has to be specified upfront […] Assuming you do not know everything in advance, [it is hard to estimate] how much money this will cost." The holistic character of EA differs from the traditional technical approach of solving problems in a piecemeal manner, where a system is broken down into pieces, and the focus is on different modules. An enterprise architect explained that this difference is reflected in the tools used: "Having documented your enterprise architecture in a way that supports decision-making processes is different [from] the system architecture approach of HospitalPartner, where one must conduct modeling of different areas to produce a solution.
[…] it requires different functionality in an EA tool." Enterprise architects have a holistic view and a need to have an outline of the interdependencies across the organization. They are able to look for streamlining opportunities across the application portfolio as explained by one of them: "When we now look at the needs and functionality of the business layer, we can see that it may make sense to move some functionality from one application to another -and it becomes visible in the architecture." In contrast, IT professionals and managers pay more attention to each project at hand. Similarly, medical professionals are confined to their specializations, following clinical protocols to address specific clinical needs.
They are not used to open-ended strategic efforts. One interviewee pointed out the entrenched healthcare attitudes.

T A B L E 4 (Continued)
Representative extract from documents Interview quote "It is nationally and regionally recommended that TOGAF shall be used as an architecture methodology" (RCS Guidelines presentation, 2017).
domain properly" (senior manager -IT background). "Getting it [mandatory use of EA approach] into the project guideline is a confirmation that this is a valuable area, and this is a requirement" (project manager and clinician).
"It is part of the culture of healthcare to be ad-hoc organized to save lives. The focus is not on strategic development, neither for clinicians nor for IT people." Furthermore, one of the project managers explained that it is natural to have a perspective that is focused on the project scope and not on the wider landscape: "A project always puts itself in the center, then the picture is drawn around the center." The second tension is related to realizing the aspiration for top-down standardization through EA. The hospital sector has a long tradition of decentralized and autonomous entities, this creates a tension between the traditional bottom-up localization and the EA-driven top-down standardization. In the case of the pharmaceutical management project (Vignette 2), standardizing information management across multiple applications proved to be particularly challenging. In the case of the cancer medication project (Vignette 3), standardization is advancing, but some local variations are tolerated (eg, the advanced preparation of medications in some hospitals). The decentralized setup of the hospital sector is in contrast to the EA approach which builds on principles of centralized control in decisionmaking. One of the interviewed enterprise architects said: "At least, some [hospital trusts] will actually have their [own] local systems and avoid the hassle of regional ICT services. Because then, they will have complete control over their own ICT needs, to support the work processes they have, without interference." The findings indicate a tension between top-down standardization initiated from the region and the local work practices in each hospital. The tension is not only related to local managerial concerns, but also to the role of medical professionals. One of the enterprise architects clearly referred to this issue: "That's what it's all about, the desire to be able to keep the control. Some doctors had control over the years, and now they are increasingly losing it, and they are not completely satisfied." An enterprise architect explained that the region could have been more proactive towards developing regional-level solutions, but it is difficult because the hospital trusts prefer to maintain their autonomy: Local solutions are in some cases implemented, without taking top-down standardization into account. The enterprise architects suggested the introduction of new organizational arrangements to support standardization. Specifically, the architectural and design group and the architectural board were introduced as explained by one enterprise architect: "When the RCS program started, I raised questions about how we could handle issues that transcended the projects in the program in a better way. The top management agreed that we had to establish two architectural functions, one was the architecture and design group as an operational function in the RCS program and the architecture board as an interdisciplinary body, which could make architectural choices." The third tension pertains to the time perspective. EA essentially introduces a long-term outlook, but it is difficult to prioritize long-term activities over hospitals' urgent needs. For instance, in the regional ambulance record project (Vignette 1), the decision was to aim for immediate utility instead of the long-term vision. One of the interviewed enterprise architects described the general situation: "There are many pressing initiatives that have to be done; thus, the 'long-term' picture is a bit difficult." Another interviewee further elaborated: "It is hard to get people in a busy operating organization to use a lot of time on IT without having short-term benefits. Sometimes, the benefits come to others or are diffused to many, but it takes some time." A project manager explained that the short-term orientation has been common in hospital IS projects: "The driver is to meet a need in the short-term […] with the long-term perspective we are increasing the complexity of our portfolio." An interviewee with clinical background stated: "[The EA approach] has created an opportunity to become more long-term oriented, however the health care sector has a very short-term oriented mindset, this significantly influences the vendors, leading to a poor architecture." Furthermore, IT professionals tend to orient themselves towards solving well-known practical problems. A senior manager with an IT background explained: "We are far behind, we have a lot of technical debt, we face many challenges. And so, it is that enterprise architects and others, they think it is exciting to look ahead-so the distance between the realities and what they like to talk about and relate to, of great systems coming or whatever it is, is so huge that it is hard to see that they have a good agenda for management." To summarize, the coexistence of IT professionalism, medical professionalism, and managerialism in hospitals orients IT and process design towards fractional initiatives, localizations, and short-/medium-term outlooks. However, EA introduces a holistic, long-term, and top-down approach. Hence, tensions emerge when project decisions need to be made. Table 5 provides an overview of the identified tensions, linking them to logic incongruences. The tension categories identified consolidate the empirical findings.

| Tensions shaping the operationalization of EA
The empirical analysis provides insights about EA operationalization in practice in an institutionally complex context.
In the case studied, the EA logic is introduced in a domain where multiple logics are already active (medical professionalism, managerialism, and IT professionalism). The different logics get invoked during deliberations for project decisions. These deliberations make visible the incongruences between the principles of the newly introduced EA logic (holistic orientation, top-down planning, long-term thinking) and the established logics. Hence, tensions emerge.
Although the projects are EA-driven, the dominance of the EA logic cannot be taken for granted and the findings suggest that the resolution of tensions varies. Actors have to grapple with the co-presence of different logics seeking ways to facilitate action. During deliberations for project decisions the different possible courses of action are discussed against the different principles and assumptions underlying different logics. The EA projects studied are managed by three-party project leadership teams (clinical, managerial, and technical). This is an institutional arrangement that promotes the inclusiveness of multiple perspectives. Actors are acclimatized to the coexistence of multiple logics and seek to work with them. They do perceive their contradictory elements, but also acknowledge their importance and interdependence in the complex hospitals' setting. avoid the paralyzing effect of unsettled tensions, actors seek accommodation relaxing rules and challenging established ways of thinking. In this process, the EA principles may be suppressed (as in the case of the regional ambulance record project in Vignette 1); may be foregrounded (as in the case of abolishing the nurses' requisition rights in Vignette 3), or a blend may be agreed (as in the case of hospital pharmacies retaining the discretion to prepare medications in advance in Vignette 3). Regardless of the type of settlement, as projects evolve more tensions are bound to emerge creating the need for new settlements. Coexisting logics can continually exist in a state of dynamic tension as EA becomes operationalized through projects.

| Key findings and contributions
Our research makes a twofold contribution extending the existing EA literature and advancing research on the implementation of IS projects in complex settings where many different institutional logics coexist. It contributes to EA studies by explicitly examining EA operationalization. There is a notable paucity of studies focusing specifically on EA operationalization and the relevant theoretical development is limited (Banaeianjahromi & Smolander, 2019). This is probably related to the scarcity of projects that operationalize EA. Furthermore, the few researchers who have studied EA operationalization in projects tend to focus on the technical conditions associated with EA success or failure and, to a lesser extent, on the interpersonal interactions and dynamics during action-taking (Dale & Scheepers, 2019;Smolander & Rossi, 2008). Our study contributes to filling this gap. Combining the empirical findings and building upon literature on institutional logics (Thornton & Ocasio, 1999) and institutional pluralism (Kraatz & Block, 2008), we developed a model of EA operationalization (Figure 3). In the model, we show EA being invoked as a distinct logic along other pre-existing logics.
The interplay between the EA logic and the established logics creates tensions during project deliberations. The model is descriptive, and it depicts trajectories for tension settlement in project decisions. In these trajectories, EA is foregrounded, As presented in the model, moving from "EA at the strategy level" to "EA in project decisions" entails project deliberations that bring to the surface different logics and the tensions among them. Deliberations play a key role in EA operationalization in institutionally complex settings. During deliberations for the EA projects studied, the participants sought to move ahead with their projects through joint project decisions. The focus on action distinguishes deliberation from other forms of dialogue (Walton & Krabbe, 1995). In deliberations the discussion is directed at reaching a joint decision over a course of action as the actions under consideration need to be enacted by all involved parties. Doing nothing at all has also consequences and is therefore a form of action which in the case of project deliberations leads projects to a halt. Deliberation is a group activity in which participants engage to carry out a collective task in a specific situation. When possible courses of action are proposed, they are assessed based on different concerns. These different concerns reflect the different assumptions and principles of the institutional logics invoked by participants. EA operationalization is essentially an on-going tailoring process addressing contextual specificities as identified in prior research (Kotusev, 2018a). This process allows institutional pluralism to persist, the decisions taken are temporary stabilizations, the projects continue to evolve, and the actors involved are bound to grapple with new tensions through multiple situated actions and interactions.
By utilizing the lenses of institutional logics and institutional pluralism to study the dynamics of decision-taking for information systems, we respond to calls for IS research on the practical interplay among different institutional logics in a field with a wide range of logics (Hansen & Baroody, 2020) and especially on the impact of different logics on the development of concrete system functionalities (Berente et al., 2019). Our findings show how decisions about functionalities emerge as project teams engage in deliberations. In these deliberations, actors acknowledge the coexistence of differences and seek to "work through" allowing multiple logics to persist (Smith & Lewis, 2011). Prior IS research generally tends to associate specific logics with specific types of actors (eg, Berente & Yoo, 2012;Boonstra et al., 2018); this study contributes to developing a more nuanced understanding by acknowledging broader practice repertoires. In the case studied, the three-party project leadership structure ( Figure 2) is an institutional arrangement that promotes inclusiveness and power symmetry. By being part of such institutional arrangements, actors can perceive the contradictory elements of coexisting logics while recognizing their importance and interdependence (Hargrave & Van de Ven, 2017). Furthermore, in the case studied, many of the actors involved learned different logics by following diverse educational and professional paths (for instance, medical specialists or technical specialists becoming managers). Such diverse paths are becoming increasingly common in contemporary complex organizational settings and can contribute in reactions to the introduction of new logics that are not characterized by outright resistance, anxiety, or defensiveness, cultivating dynamic equilibria. For instance, the introduction of new integrated information systems is often associated with managerial logics that promote efficiency and tend to create tensions with pre-existing professional logics within complex organizations (Berente & Yoo, 2012;Boonstra et al., 2018;Hansen & Baroody, 2020). The ability to accept the coexistence of multiple logics can be a source of creative energy in organizations driving the questioning of assumptions and enabling actors to avoid polarization. Our findings demonstrate that institutional pluralism can be the basis for broad practice repertoires as actors relate to multiple logics.
We elaborate on these contributions and their implications for theory and practice in the following sections.

| Theoretical implications
The study has theoretical implications for EA scholarship; it conceptualizes the institutional logic of EA and provides a model that shows how the meeting of multiple institutional logics may lead to varying degrees of differentiation or F I G U R E 3 EA operationalization model even disassociation from EA visions. Furthermore, our study has theoretical implications for IS research on the interplay among different logics and their impact on information systems; it highlights the importance of considering actors' discretion in their everyday use of the logics available, suggests disentangling institutional logics from specific types of roles and shows how actors within complex institutional arrangements may engage in the on-going reproduction of tensions and temporary settlements allowing different logics to persist in a dynamic equilibrium.
First, we suggest that EA can be conceptualized as a distinct logic. As EA becomes part of the institutional context, its logic becomes part of the resources that actors can draw on in their everyday interactions. The established logics are ingrained in the customary ways of working and the established power structures, as identified in prior IS research (Boonstra et al., 2018;Boonstra, van Offenbeek, & Vos, 2017;Heeks, 2006). In the case studied, although the reasoning for the introduction of EA is clear and the high-level aims are universally accepted, differences among the EA logic and the other dominant logics surface when decisions about applications and processes need to be taken. These differences lead to tensions that have to be resolved. The tensions relate to the principles identified for the logic of EA: (a) holistic orientation, (b) top-down planning for standardization and integration, and (c) long-term thinking. Second, this study has implications for making sense and providing an explanation for the mixed outcomes and the implementation delays of EA visions. Moving from the strategic to the operational level, a state of dynamic tension between the EA logic and multiple existing institutional logics is generated. We propose a model that shows how EA gets operationalized through project deliberations that lead to different settlements.
The study by Reay and Hinings (2009) on the interaction between the logics of medical professionalism and managerialism in healthcare is often cited as an exemplary study on how multiple logics may coexist at the microlevel. Nevertheless, their seminal paper does not elaborate on actor interactions and justifications. By demonstrating such interactions, our work extends prior research on settling tensions in contexts of institutional complexity (Kraatz & Block, 2008;Pache & Santos, 2010;Reay & Hinings, 2009). Our research shows how the meeting of multiple institutional logics may lead to varying degrees of differentiation or even disassociation from EA visions.
Third, moving beyond EA scholarship to the overall IS studies on the institutional dynamics shaping information systems, we highlight the importance of considering actors' discretion in their everyday use of the institutional logics available.
Previous studies have shown that actors involved in IS projects can be influenced by multiple logics and can have shifting positions over time (Pouloudi, Currie, & Whitley, 2016). Within institutionally pluralistic organizations, decisions taken about functionalities are temporary stabilizations as actors manage tensions to guide action (Berente & Yoo, 2012). The tensions between different logics may be managed through dialectical or paradox approaches (Hargrave & Van de Ven, 2017). When tensions are managed as paradoxes, actors acknowledge the coexistence of differences and seek to "work through" them while in dialectical approaches, actors do not pursue the sustainment of different logics but instead, engage in ongoing processes of integration (synthesis) eventually converging. This study contributes to the stream of IS research that investigates paradoxical management of tensions within institutionally pluralistic settings (Gregory, Keil, Muntermann, & Mähring, 2015;Soh, Yeow, Goh, & Hansen, 2019;Wimelius, Mathiassen, Holmström, & Keil, 2021). This stream of research provides rich insights about the outcomes of paradox management but says comparatively little about the leadership arrangements and interpersonal interactions that make possible the management of tensions as paradoxes.
The findings of this study are therefore important for IS researchers with an institutional interest to understand leadership arrangements for IS project implementation in settings where different logics coexist. Furthermore, our study provides a rich empirical account of actors' interactions and justifications. Hence, this paper is relevant for researchers interested in understanding the sense-making and practices which actors individually and collectively employ to manage tensions in institutionally pluralistic settings. Previous research has shown that for instance, enterprise-wide systems may cause institutional resistance due to divergent interests among user communities (Berente et al., 2019). This can lead to workarounds and unintended outcomes that diverge from the original visions of IS projects (Boudreau & Robey, 2005). Our model on EA operationalization is therefore valuable for making sense of the dynamics of project implementation in institutionally complex settings.

| Practical implications
Our study provides practical insights for working with EA at the concrete project level. EA aims to provide support for addressing long-standing healthcare problems related to fragmented IT portfolios, immature IT infrastructures, and silo-structured organizing (Ross et al., 2006). The empirical findings from this case analysis show that prioritizing the EA logic is difficult in hospital projects despite executive-level support. These findings complement prior research that has mostly explored EA initiatives at the executive level identifying overarching challenges and enablers (for instance, Banaeianjahromi & Smolander, 2016;Dang & Pekkola, 2019;Iyamu & Mphahlele, 2014). Our study suggests that the operationalization of EA in hospital projects requires some level of adaptation of EA principles and methodological premises. For instance, the top-down orientation of EA initiatives needs to be adjusted by taking into account key aspects of the sociocultural climate including the established culture of autonomy, flexibility, and demand for locally adapted systems. Prior research has identified that actual EA practices often differ substantially from the original EA methodologies (Kotusev, 2018b), and, that real-world EA practices can work even when an organization does not adopt all the elements that are typically considered essential for EA (Kotusev, 2018a). EA prescriptions often prove to be inherently abstract (Foorthuis et al., 2012) and getting them concretized is part of the EA operationalization process. The operationalization of EA in hospitals requires tailoring to the institutionally complex setting of healthcare.
Furthermore, by foregrounding logic multiplicity our study points to the need for establishing a project environment that allows tensions to surface and get addressed. Interestingly, in the case studied a three-party project management structure covering clinical, managerial, and technical aspects was established. The diversity in project leadership allowed different perspectives to be voiced exhibiting different degrees of dominance during project deliberations. Prior research has shown the importance of a supportive social environment and an adaptive culture for EA projects (Aier, 2014;Niemi & Pekkola, 2016;Weiss et al., 2013) and of tactical EA engagement beyond strategic engagement with senior business leaders and executives (Kotusev & Kurnia, 2019). The specific case studied provides an interesting example of a project environment that can contribute to a management of tensions that is not characterized by outright resistance, anxiety, or defensiveness, cultivating dynamic equilibria. In practice, the inclusion of multiple perspectives in decision-making (such as in the SERHA three-party project leadership model) allows tensions to surface and get deliberated by engaged actors that seek to reach joint decisions over their course of action. Such organizational arrangements can set the stage for using the tension among logics as an opportunity for creativity and learning.

| LIMITATIONS AND DIRECTIONS FOR FUTURE RESEARCH
This study has limitations that provide opportunities for future research. First, although we believe that our research provides a valuable exploration of EA operationalization in hospitals, we also recognize the influence of the characteristics of the empirical context in our findings. Our study is conducted in a Scandinavian context which is wellknown for a work culture with low power distance, encouraging bottom-up approaches, and democratic processes (Gregory, 2003). Norwegian healthcare has a tradition of developing clinical systems by involving clinical personnel in the design process (Bjerknes & Bratteteig, 1985;Bjerknes & Bratteteig, 1995), and in general, participatory processes involving users are strong in Scandinavian organizations. Such settings can be conducive to tension management through paradoxical approaches that allow different logics to persist (Hargrave & Van de Ven, 2017 Second, although our empirical material provided indications that enterprise architects play a significant role in the deliberation processes that unfold during EA operationalization, the enterprise architects' role is not within the focus of this study. Prior research has shown that enterprise architects can act as change agents and communicators (Ylinen & Pekkola, 2018) and can create an inter-community structure by bridging boundaries between different professional communities (Dale & Scheepers, 2019). The role of enterprise architects during EA operationalization warrants further research, future studies may consider examining this. Finally, an interesting direction for further research is to move beyond EA operationalization to study the appropriation of EA-driven systems and processes after their deployment in actual work settings. Studying the actual use of systems and processes deployed by organizations that use EA as a systematic way of designing, planning, and implementing process and technology changes would require analyzing the perspectives and experiences of organizational members that have not been directly involved in EA projects. TOGAF describes the process of developing and managing an enterprise architecture. A key part of TOGAF is the architecture development method (ADM) which is an incremental and iterative approach for progressing from high-level architecture visions, to detailed architectural blueprints, all the way to architecture change management covering process, information, application, and technology architectures. TOGAF is used by practitioners from the EA function within organizations, nevertheless, some organizations also link TOGAF elements with Information Systems' project management processes to ensure that the projects will contribute to reaching architecture visions.

| CONCLUSIONS
The South Eastern Regional Health Authority (SERHA) in Norway uses a specific method toolkit to plan and manage Information Systems projects. This toolkit is adapted to the region's needs and is called the "South East Health Project Wizard." It covers the entire project process from concept selection to completion including the hand over to line organization. In 2017, SERHA released a revised version of the Project Wizard specifying how projects under the RCS programme should work with Enterprise Architecture. In practical terms, the wizard was adapted to include TOGAF's Architecture Definition Document (TOGAF ADD). The updated wizard sets the requirement to prepare an architecture description already in the concept phase of each project. This description needs to be continuously updated and further developed as the project evolves (see Figure 1). The introduction of TOGAF ADD in the project wizard requires close collaboration between architects and project managers in all on-going projects within SERHA. As a consequence, the projects in the RCS programme must take onboard the EA principles and tools. Based on TOGAF's ADD all RCS projects describe their future architecture and how it will be developed in the project.
The architecture documentation describes a future-planned architecture based on the current state of architecture. A gap analysis describes how the project should change from current to planned architecture. The architectural deliverables to be implemented provide a comprehensive overview of the scope of the architectural work that the project will deliver in order to achieve the desired results and gains that the business wishes to realize.

Challenges in architecture documentation
There have been (and still are) major challenges with the architecture documentation in the projects of SERHA due to lack of standardization. This has resulted in major differences when it comes to format and content. Poor overview of the present architecture and inadequate overview of ongoing architecture deliveries in other projects have caused high costs in several projects. The project wizard aims to ensure higher architecture quality, increased standardization, and specific decisions points for the project management of ICT projects in SERHA.

Background information
Can you tell me about your department, your role and responsibilities? Validation and explanation of the educational background and current position (Pre-collected notes from LinkedIn were discussed, updated, and/or confirmed).  The principle of the hermeneutic circle We iterated between specific aspects of different projects and the overall dynamics within hospitals. Relating EA operationalization with the changing hospital IT landscape, the work practices and the relations between different organizational roles. Combining data from interviews and strategic documents, healthcare management reports and guidelines. 2 The principle of contextualization Data collection was performed in the 2017-2019 period, nevertheless, to contextualize the study, information was collected to also cover activities that happened in the past including the initiation of the Digital Renewal programme back in 2013. This helped in making sense of how the current situation under investigation emerged. Furthermore, we started the data collection by interviewing mostly enterprise architects and senior managers but to better understand the setting we expanded to the project management teams, including the clinical specialists with managerial roles and the participants with a more technical orientation. 3 The principle of interaction between the researchers and the subjects The data were analyzed to a large extent during the same period as the data collection, so, we had a lot of opportunities to discuss and develop the emergent understanding, together with the interviewees. Moreover, three different researchers were involved in this work contributing and debating alternative views.

The principle of abstraction and generalization
The analysis was empirically grounded in the Norwegian hospital context, the Digital Renewals programme and the specific projects studied but, the findings were viewed through the institutional logics lens which was used as a basis for abstract theorizing.

5
The principle of dialogical reasoning Initially in the research design we assumed that the enterprise architects and the enterprise architecture artefacts were the key in developing insights about EA operationalization. But we soon saw that EA had to be viewed together with the different professional practices and roles expanding the scope of our empirical data collection.

6
The principle of multiple interpretations We observed that the views about the aimed benefits from the introduction of EA were similar among the different actors. However, when EA was operationalized in practice, tensions arose and diverse perspectives about EA were identified. We reached out to interviewees that had experienced the same events while having different roles. We asked them about the course of events and their experiences. Combining multiple accounts, we brought together different perspectives and interpretations of the same events.

7
The principle of suspicion We strived to collect empirical accounts from multiple parties. Being conscious that biases and distortions may occur, during data analysis we kept in mind the roles and organizational affiliations of interviewees.