5 questions

Institutional Perspectives on the Process of Enterprise

Architecture Adoption

Duong Dang1

& Samuli Pekkola2

# The Author(s) 2019

Abstract

Organizations often adopt enterprise architecture (EA) when planning how best to develop their information technology (IT) or

businesses, for strategic management, or generally for managing change initiatives. This variety of different uses affects many

stakeholders within and between organizations. Because stakeholders have dissimilar backgrounds, positions, assumptions, and

activities, they respond differently to changes and the potential problems that emerge from those changes. This situation creates

contradictions and conflicts between stakeholders that may further influence project activities and ultimately determine how EA

is adopted. In this paper, we examine how institutional pressures influence EA adoption. Based on a qualitative case study of two

cases, we show how regulative, normative, and cognitive pressures influence stakeholders’ activities and behaviors during the

process of EA adoption. Our contribution thus lies in identifying roles of institutional pressures in different phases during the

process of EA adoption and how it changes overtime. The results provide insights into EA adoption and the process of

institutionalization, which help to explain emergent challenges in EA adoption.

Keywords Enterprise architecture . EA adoption . Institutional theory . Institutionalization process

1 Introduction

Enterprise architecture (EA) attempts to improve alignment

between business and information technology (IT) manage-

ment and support IT planning and decision-making

(Magoulas et al. 2012; Ross 2009; Simon et al. 2014;). EA

is of interest to both private- and public-sector organizations.

For example, the United States and Finland, where a large

number of such projects have been implemented, have

enacted laws that oblige state agencies to use EA, such as

the Clinger-Cohen Act 1996 and the E-Government Act

2002. Because multiple actors participate in or are affected

by such projects (Jonkers et al. 2006; Shah and Kourdi

* Duong Dang

[email protected]

Samuli Pekkola

[email protected]

1 School of Technology and Innovations, University of Vaasa,

Vaasa, Finland

2 Faculty of Management and Business, Tampere University,

Tampere, Finland

2007), understanding all stakeholders’ perspectives is crucial

for successful adoption (Dang and Pekkola 2016).

EA adoption refers to how organizations actually use EA,

or how EA works there (Dang and Pekkola, 2017). EA is

adopted through EA projects or EA programs consisting of

several projects. EA adoption process is a process where EA

becomes a mundane practice of an organization (Iyamu 2009;

Weiss et al. 2013). Although the process includes many

phases, there are different views (c.f., Armour and Kaisler

2001; Armour et al. 1999; Banaeianjahromi and Smolander

2017). For example, Banaeianjahromi and Smolander (2017)

identified three phases: pre-development, development, and

post-development, while Armour and colleagues (Armour

and Kaisler 2001; Armour et al. 1999) divided it in five

phases: initiating the process, characterizing the baseline ar-

chitecture, developing the target architecture, planning the ar-

chitecture transition, and planning the architecture implemen-

tation. We view EA adoption including two main phases: EA

initiation, where EA functionalities are created, and EA im-

plementation, where those functionalities are deployed. EA

functionality refers to the architectural descriptions of the or-

ganization’s current and future state, general principles for

their architecture, and a roadmap to the future state (Niemi

and Pekkola 2017).

EA adoption studies have often ignored the challenges of

institutionalizing EA (Dang and Pekkola 2016; Hylving and

Bygstad 2019). Instead, they have studied on frameworks

(c.f., Simon et al. 2013; Dang and Pekkola 2017), the benefits

and success factors of EA adoption (c.f., Schmidt and

Buxman 2011; Lange et al. 2015), agile EA adoption (c.f.,

Bondar et al. 2017; Alzoubi et al. 2018), and problems with

EA (c.f., Kappelman and Zachman 2013; Ajer and Olsen

2018). However, they provide little or no insight into institu-

tional and stakeholder factors in EA adoption from the view-

points of senior managers and chief information officers

[CIOs], project managers and enterprise architects, and IT

specialists and non-IT civil servants, for instance.

While literature has indicated the importance of cognitive,

normative, and regulative pressure on adoption intention

(Khalifa and Davison 2006; Krell et al. 2009; Liang et al.

2007; Teo and Pian 2003; Yoon and George 2013; Zheng

et al. 2013), little is known about how these pressures affect

the adoption process. EA literature on the institutional view is

especially scarce; the few examples focusing on the institu-

tionalization barriers within EA management (Dang 2017;

Iyamu 2009), which factors influence architectural coordina-

tion (Weiss et al. 2013), interoperability challenges (Hjort-

Madsen and Gøtze 2004), government pressures (Hjort-

Madsen 2007), potential solutions for EA adoption (Dang

and Pekkola 2016; Dang et al. 2019), and the stakeholders

logics in EA adoption (Dang 2019). The ways in which insti-

tutional factors influence different phases of EA adoption re-

main unknown, as are stakeholders’ responses to challenges

that emerge within EA adoption process. We argue that ana-

lyzing these issues will provide an in-depth understanding of

the values, norms, and rules found in different phases of EA

adoption and will further explain the challenges in EA

initiatives.

Our research question is as follows: How do institutional

pressures influence different phases of EA adoption? Based on

a qualitative case study of two organizations and their key EA

stakeholders, our findings contribute to literature by identify-

ing roles of institutional pressures in different phases during

the process of EA adoption and how they change overtime.

The findings show that cognitive pressures dominate the early

stage of EA adoption, while regulative pressures become more

important later. We also show how values, norms, and rules

appear in different EA-adoption phases. These factors have

several practical implications, as highlighting institutional fac-

tors will enable practitioners to design strategies and respond

to the challenges of EA adoption.

The remainder of this paper is structured as follows.

The next section introduces the background to the study

before moving on to describe the research methods and

context. After summarizing and discussing the study’s

findings, the paper ends with conclusions, implications,

and limitations.

Inf Syst Front

2 Background

2.1 Enterprise Architecture

EA has no universally accepted definition with a wide ranges

of scopes, covering from organizational business to technolo-

gy (Dang and Pekkola 2017). In this paper, we view EA as“an

approach for managing the complexity of an organization’s

structures, business environments, and different information

systems, and for facilitating the integration of strategy, person-

nel, business, data, and IT” (Dang and Pekkola 2017, p.131).

Enterprise architecture management (EAM) to mean“the

management activities conducted in an organization to install,

maintain and purposefully develop an organization’s EA”

(Lange et al. 2015, p. 1). In that sense, EA project and its

activities can be understood to be a part of EAM. EA products

are outputs of an EA project, such as strategic plans, stan-

dards, and frameworks (Dang 2019). EA approach is under-

stood as methodologies to establish an EA. For example, or-

ganizations can use the Open Group Architecture Framework

(TOGAF) as an approach to establish their EA from initiation

to use (Hylving and Bygstad 2019).

2.2 The Institutional View within EA Research

Information systems (IS) researchers use institutional theory

as a lens to study how institutions, organizations, and organi-

zational entities influence one another (Jepperson 1991;

Mignerat and Rivard 2009) and how different institutional

stages emerge (Mignerat and Rivard 2009). Most studies have

focused on organization-level issues, while the few that have

considered individuals and groups (Mignerat and Rivard

2009; Weiss et al. 2013).

The use of institutional theory as an analytical lens appears

to be rare in EA research (Dang and Pekkola 2016). Those

include, for example, Iyamu (2009) identified the internal bar-

riers to the process of EA adoption as being organizational

structures, administrative processes, organizational politics,

and technical capabilities. Dang and Pekkola (2016) looked

at institutionalization in different phases of EA projects, while

Hjort-Madsen and Gøtze (2004) studied interoperability chal-

lenges at different levels of government. Magnusson and

Nilsson (2006) argue that institutional theory can be used to

introduce legitimacy and a historical perspective to architec-

tural frameworks. Hjort-Madsen (2007) discussed govern-

ment pressures for consolidation and value preservation and

the political motives that drive EAM development. Dang

(2019) studied institutional logics influencing EA adoption,

and Hjort-Madsen et al. (2007) investigated the influence of

EAM adoption in government organizations. These studies

have not considered how institutional pressures change over

time, nor how individuals or groups are influenced by

Inf Syst Front

institutional pressures during the process of EA adoption. We

try to fill this gap.

Because each stakeholder group exhibits distinct behaviors

and activities, they will respond differently to a given action.

For that reason, we focus on different stakeholders, including

the management team (e.g., senior managers), the project team

(e.g., project managers (PMs)), and users. Within this view,

organizations, groups, and individuals constitute an internal

group, while society and central governments are externals.

We argue that both groups are equally important in shaping

the stakeholders’ activities and behaviors and lead to different

responses to new issues. Analyzing the institutional factors

can thus help in understanding the roles of values, norms,

and rules in the EA-adoption process, from establishing the

technology or practice (i.e., EA) to its institutionalization.

2.3 Theoretical Lens

We adopt Mahalingam and Levitt’s formulation of an institu-

tion for our study:“(neo) institutions are a set of rules, norms,

and values operating in a given environment that help generate

a regularity of behavior among actors affected by that envi-

ronment” (2007, p. 523). This formulation acknowledges that

organizations may initiate EA with certain expectations but

may leave others to do the interpreting and applying. Rules,

norms, and values may drive (and therefore explain) the ac-

tivities and behaviors of stakeholders during the institutional-

ization of EA (Mahalingam and Levitt 2007).

As institutional theory examines“the processes and mech-

anisms by which structures, schemas, rules, and routines be-

come established as authoritative guidelines for social behav-

ior.” (Scott 2005, p. 408) The theory is often used to study

social perspectives in organizations that implement IS projects

(Mignerat and Rivard 2009; Orlikowski and Barley 2001).

Institutional theory thus offers a lens for analyzing the rules,

norms, and values that underlie and legitimize the behaviors

and activities of groups and individuals (Berente and Yoo

2012). The majority of studies that have used institutional

theory as a lens have focused on the macro level, where the

organization is considered to be the smallest type of actor

(Berente and Yoo 2012; DiMaggio and Powell 1983).

Others, however, have argued that the micro levels of various

phenomena (e.g., groups or individuals) are rooted at higher

levels (Berente and Yoo 2012; DiMaggio and Powell 1983;

Powell and DiMaggio 1991). This notion allows us to focus

on individuals and groups and governmental policies.

Three main pressures influence organizational and individ-

ual behavior: cognitive (values), normative (norms), and regu-

lative (rules) pressures (Scott 2005). Cognitive pressures relate

to institutional culture, such as beliefs or organizational values

(DiMaggio and Powell 1983). Normative pressures refer to

how an organization’s approach to professionalization—for

example, work norms or mimetic behaviors—informs its

members’ activities (DiMaggio and Powell 1983). Regulative

pressures, both formal and informal, include policies and ele-

ments in the legal environment that explain how institutions

constrain and regulate stakeholder activities and behavior

(Mignerat and Rivard 2009), as in the case of local govern-

ments ruled by a central government.

When pressures arise, organizations and stakeholders tend

to conform in order to achieve legitimacy and to secure re-

sources that are important for their survival (Ribeiro and

Scapens 2006; Scott 2005). Yet their responses vary (Oliver

1991) due to different backgrounds, cultures, beliefs, socie-

ties, and political environments. Responses are applied differ-

ently in EA project activities (for example, in terms of scope,

approach, and outcomes), which then steers the projects in

different directions. For instance, top managers, project mem-

bers, and users may initiate different actions by their varying

views on a given problem, which creates contradictions and

conflicts among stakeholders. Institutional theory thus entails

both the assumptions that are taken for granted and the actions

that influence and guide decision-makers.

We adopt this perspective as a means of understanding

stakeholders’ behaviors and activities (Cloutier and Langley

2013; Scott 2005; Oliver 1991; Friedland and Alford 1991)

during the adoption process. The use of the institutional view

helps in understanding how institutional pressures change

over time and how individuals or groups are influenced by

institutional pressures during the adoption process.

3 Research Methods and Context

3.1 Research Methods

Our empirical research was conducted from 2015 to 2016. We

used an interpretive case study as a research approach (Myers

1997; Walsham 1995). As Myers (1997) and Walsham (1995)

have instructed, we first conducted a literature review

(Webster and Watson 2002) in order to form the theoretical

foundations for the study. The theories were used loosely so

that they would not influence the data collection and analysis.

The lenses of the theoretical foundations of institutional theo-

ry and EA were adopted later and used in the data analysis.

The use of interpretive case studies helps to understand

various phenomena within a case’s context (Benbasat,

Goldstein, and Mead 1987). As Orlikowski and Baroudi

(1991, p. 13) note, this approach allows researchers to“under-

stand how members of a social group, through their participa-

tion in social processes, enact their particular realities and

endow them with meaning, and to show how these meanings,

beliefs and intentions of the members help to constitute their

social action.”

We chose two Vietnamese provinces for our multiple-case

study (Stake 2005). They were chosen for two key reasons.

Inf Syst Front

First, multiple cases may be “…similar or dissimilar, redun-

dancy and variety each important. They are chosen because it

is believed that understanding them will lead to better under-

standing, perhaps better theorizing, about a still larger collec-

tion of cases” (Stake 2005, p. 446). Second, the cases were

different in terms of capabilities, complexity, and experiences

with e-government initiatives. For example, the“Omega” case

(a pseudonym) used its own resources and procedures, while

the“Eta” case was the first province to adopt EA, so it relied

on a sponsor, local authorities, and external resources and

procedures. In these respects, we considered Omega to be a

purpose sample and Eta to be an opportunistic and reputation-

al sample (Miles and Huberman 1994).

3.2 The Cases and their Contexts

Our study focuses on two Vietnamese provinces adopting EA

through EA projects. Vietnam has 63 provinces and equiva-

lent municipalities (thereafter provinces). Each province has

several departments (e.g., Department of Justice, Department

of Information and Communications—DIC) and districts.

Each department or district has several divisions (e.g.,

Division of Information Technology and Division of

Planning and Finance of DIC) (Fig. 1).

Vietnam has shown a strong political commitment to pro-

moting electronic government. For instance, during the period

2011–2015, the Vietnamese government’s master plan en-

couraged state agencies to“use ICT for their administrative

reform and business services to improve the effectiveness and

efficiency of the public administration system” (Decision

No.1605/QD-TTg by the Primier Minister 2010, p. 1). In

our cases, EA was thought of as a means of achieving these

aims. At the time of this study, however, there were no oblig-

atory laws or policies that the provinces could follow, which

resulted in public organizations adopting EA according to

their own perceptions. This approach caused variances be-

tween the cases.

EA projects in both cases were considered as mega pro-

jects. The projects bridged three levels of administrative

Eta/Omega

Administration

…

Province n

Administration

Department or

District 1

Department or

District 2

…

Department or

District n

Division 2.1 Division 2.2 Division 2.m

…

Fig. 1 Organizational structure of the cases

structure (Fig. 1). This means that each EA functionality

may influence several agencies in all organizational levels.

EA projects were established on the administration level.

DICs’ were in charge of the project management.

Stakeholders participating the projects were collected from

Cases’ administration (e.g., senior managers, CIOs),

Department or District (CIOs, PMs, IT specialists), and

Division (e.g., IT specialists, civil servants). Each stakeholder

may represent more than one agency or group. Project activ-

ities was thus influenced by internal factors (e.g., individual

and agencies within the organizations) and external factors

(e.g., sponsor and government policies). We investigate how

those factors influence to the adoption process.

3.2.1 Omega EA Project

Omega is a province with little experience on e-government.

The EA project was established in 2012, with the main objec-

tive of reforming and connecting distinct public services and

increasing interoperability between and within organizations.

The scope of the EA project covered three levels of the ad-

ministrative hierarchy (see Fig. 1). Three groups of stake-

holders were involved with or influenced by the project activ-

ities: senior management, the project team, and users. The EA

products included a strategic plan to digitalize services in the

Omega agencies and a new model for centralized public ser-

vices as a single point of delivery for citizens and enterprises

and organization employees. Table 1 shows the main activities

and timeline for the Omega EA project.

3.2.2 Eta EA Project

Eta is a local e-government leader in Vietnam. Supported by a

sponsor’s loan, Eta had embarked on an EA project to reform

administrative procedures and public services, reduce the

number of information systems, and improve interoperability

within and between organizations. Commencing in January

2010, the EA project affected all organizational levels (Fig.

1). The EA products included standards and frameworks for

use in various organizations’ IT application strategies. In the

absence of explicit guidance for using those frameworks, it

became apparent that the program’s outcomes were somewhat

limited—for instance, the use of EA products was not report-

ed. Table 2 shows the Eta project’s main activities and

timeline.

3.3 Data Collection and Analysis

To gain an in-depth understanding of the topic, we used a

qualitative research approach (Myers 1997; Walsham 1995).

We conducted face-to-face semi-structured interviews with

individuals who worked directly on the EA projects. We re-

cruited new interviewees until we were no longer gaining new

Inf Syst Front

Table 1 Timeline: Omega EA

project Timeline Phase Main activities

Sept. 2012 to

June 2013

Initiation A proposal to establish EA functionalities, including a master plan for

digitalized services and a new model for public services (e.g.,

architectures and standardized services and administrative procedures)

June 2013 to

Oct. 2015

Implementation Implement EA functionalities in the organization’s agencies (e.g., central

administrations, departments, districts, and divisions)

insights or information. To enhance our contextual knowledge

and understanding of the interviewees’ statements, we supple-

mented the interviews with a range of project documents,

reports, news, and presentations.

Our data collection followed a semi-structured interview

approach. Interview questions aimed at understanding EA

adoption. They were organized into four themes. The explor-

atory theme aimed to understand the interviewees’ back-

grounds and roles, how they comprehended EA, and who

had prompted the use of EA. The practice theme aimed to

understand EA-adoption processes such as the projects’ activ-

ities, events, methods, features, resources, usage, and evalua-

tion. The problems theme aimed to understand the challenges

that arise during EA adoption and how they were managed.

The final theme aimed to elaborate on emerging issues.

A total of 16 interviews were conducted in 2015 from June

to August and four more in 2016 from July to August (inter-

viewees of each case are equal). During both rounds of inter-

views, the interviewees worked at various levels and positions

in the EA projects as senior managers, CIOs, project man-

agers, enterprise architects, IT specialists, and civil servants.

In short, we interviewed the stakeholders involved in the

adoption process. We assumed that these informants could

provide reliable input for the research. We began by

interviewing the CIOs to identify key stakeholders, the main

project activities, and any relevant secondary sources, which

enabled us to draw a project timeline and to specify stake-

holders and their roles. The interviews also helped us to divide

the project lifecycle into two main phases: initiation and im-

plementation. We then interviewed the other stakeholders.

Four additional interviews that were held in 2016 focused on

previous findings; they were organized with CIOs and project

managers to ensure that our interpretations were correct. All

interviews were conducted in Vietnamese, recorded and tran-

scribed; they lasted between 45 and 60 min.

The transcripts were imported to ATLAS.ti for detailed

analysis. Our coding unit was the text segment (no larger than

a paragraph and no smaller than a sentence); single text seg-

ments could be assigned multiple codes. Relationships, cate-

gories, and subcategories were grouped and coded using axial

coding (Strauss and Corbin 1998). Throughout the analysis,

open and axial coding and interview transcripts were constant-

ly compared. Following the axial coding, we interpreted the

data in terms of institutional pressures, with particular regard

to stakeholders’ behaviors and activities. During the coding

process, we used a triangulation technique by cross-checking

between data sources (Stake 2005).

We then extracted and analyzed the data through the theo-

retical lens to understand (for example) the activities and

behaviors related to regulative pressures, although further

identification and coding allowed us to classify and refine

these codes. The analysis was conducted on the Vietnamese

transcripts; only relevant selections were translated into

English for illustrative purposes. Table 3 shows an example

of the coding. We finished the data analysis with the guidance

of Eisenhardt (1989) and compared our findings with those

from the literature.

4 Findings

During EA adoption, institutional pressures shape the institu-

tionalization process. The pressures influence the stake-

holders’ activities and behaviors. Although the stakeholder

responses may seem to be similar, the reactions differ among

specific pressures and issues because the stakeholders tend to

have dissimilar backgrounds, cultures, and perceptions toward

the phenomena. In this context, the use of institutional pres-

sures as a lens helps to understand EA adoption through the

stakeholders’ activities and behaviors.

Table 2 Timeline: Eta EA project

Timeline Phase Main activities

Jan. 2010 to

June 2013

Initiation Proposal to establish EA functionalities, including common IT architectures,

standards, frameworks, and master plans for all organizational levels

June 2013 to

Dec. 2013

Implementation Implement EA functionalities in all agencies, including central

administration, departments, districts, and divisions

Inf Syst Front

Table 3 Examples of coding: values, norms, and rules

Institutional

pressure

Concept Selected quotation Phase

Cognitive

pressure

Belief or values in an

institutional environment

“Some leaders are afraid that when EA is deployed, our roles and benefits will be reduced.

That’s why, in some cases, we needed a year or longer to persuade the leader and staff to

change their attitudes.” (Enterprise architect, Omega)

“The management team perceived EA similarly to other IT projects. The EA project was

managed by the ICT department, and those in charge had a strong technical

background, which seemed to affect [the project’s] direction.” (CIO, Eta)

Implementation

Normative

pressure

Professionalization, work

norms, or habits

“They [consultants] brought EA approaches with them from a developed country to us for

implementation.” (Senior manager, Eta)

“We deployed EA as a means for administrative reform with the help of [the CIO]

committee, and [EA] replaced IT application planning in the state agencies.” (CIO,

Omega)

Implementation

Regulative

pressure

Formal and informal

policies or work rules

“At that time, the definitions, scope, scale, level of detail, method, and output of an EA

project [from the authorities] were vague. In our EA plan, we weren’t able to focus

appropriately on cooperation between the agencies.” (Enterprise architect, Eta)

“EA was initiated by the decision of the [management] board, so others had to deploy it

within their organizations.” (PM, Omega)

Initiation

4.1 Cognitive Pressures on EA Adoption

While the central government had a master plan and decree for

IT applications for state agencies, no regulations or laws were

in place to force provinces to adopt EA. EA was generally

considered to be a new approach for strategies, business-IT

alignment, and planning in organizations. In addition, because

agreements on EA products related to standards, frameworks,

and products were lacking, the cases adopted EA purely on the

basis of their own premises, initial perceptions, and expecta-

tions about how EA could help to reform administrative pro-

cedures, align business and IT applications, and increase IS

interoperability. This indicates the absence of external pres-

sures (i.e., rules), professional practices (i.e., norms) and ex-

ternal institutions in the EA adoption or decision-making. In

contrast, cognitive-cultural factors from internal institutions

(i.e., values) were significant in both cases. This is because

in the initiation phase, the EA adoption is dependent on the

stakeholders’ backgrounds, skills, and capabilities. For exam-

ple, when the stakeholders undertook EA projects, they had

difficulties in understanding why EA had been chosen in the

first place, instead of other governance models or approaches.

Cognitive-cultural factors emerged in the initiation phase,

and influenced the EA adoption. For example, EA was not the

Eta IT department’s first choice but had been picked by Eta’s

senior managers on the basis of its potential financial support

from a sponsor and for helping them to reform business ser-

vices and models. Eta’s senior managers perceived EA to be

similar to a“city plan” that would help management to mini-

mize costs and save time. The senior managers appeared to

have no idea about the organizational capabilities and re-

sources required for EA adoption. Further, other stakeholders

involved in the EA-adoption process lacked the requisite skills

to identify successful and appropriate EA examples elsewhere,

or which model, direction, or method they should use. Some

even lacked knowledge about EA. As one enterprise architect

stated,

“At that time, we [EA project team] lacked all kinds of

clarity [related to EA] about the definition, scope, scale,

level of detail, method, and output of an EA project.”

This indicates that cognitive-cultural factors were important

in the early stages of EA adoption. To overcome the cognitive-

cultural related challenges, the organizations used different ap-

proaches to improve or train their stakeholders to be able to

adapt better to the situation. For instance, Eta used consultants

to assist with the EA proposal; it also sent its employees to

courses to gain knowledge about EA, although the

challenges—related to dissimilar views, general EA aware-

ness, and expected benefits—appeared to remain. These chal-

lenges made it difficult to agree on even the simplest details,

which led to severe delays. Omega did not use consultants but

used its own IT staff. Because the staff had experience with IT

projects but not EA, they focused on IT issues and not on

business perspectives. According to a senior manager,

“When we specified the EA requirements [EA function-

alities]… no one in our team had EA experience…. We

didn’t understand what EA was—whether it was a

human-resource or a financial issue, what the policies

were, and so on. We spent a lot of time discussing the

topic but found it difficult to reach an agreement.”

This situation had several consequences. For example, it

later became clear that the proposed schedules and objectives

Inf Syst Front

were unrealistic and infeasible when the responsibility for

proposing EA functionalities fell to the IT department or other

agencies without appropriate credibility, as was the case in

Eta. In contrast, EA initiation was more feasible and effective

when the organization had a multidisciplinary team from dif-

ferent departments, led by a senior manager, as was the case in

Omega. It thus seems that in order to improve the efficiency

and quality of EA adoption, the adoption should be specified

early by senior managers or agencies with strong credibility in

terms of budgets, business services, and policies that support

cooperation among all affected agencies. As one CIO said,

“One of the main problems [with the EA project] in our

organization is the IT department. They’re responsible

for [proposing EA functionalities], but they focus too

much on IT issues rather than business aspects. This

leads to infeasibility in the next phase in terms of such

issues as relevance to inter- or intra-agency cooperation,

business-services reform, and budget.”

Cognitive-cultural factors also appeared in other forms in

the initiation phase of EA adoption; for example, collabora-

tion difficulties were evident both within and between the

agencies. In particular, the leaders in the agencies were often

unwilling to participate in joint EA projects; instead they pre-

ferred to secure their own businesses, services, and resources.

They also seemed to fear losing the“lucrative benefits” asso-

ciated with their positions in the organization or in society.

This outlook threatened to confine the scope of the EA project

to single agencies, with minimum intervention from others.

Alternatively, the organizations might focus solely on IT per-

spectives during their adoption of EA, as one PM noted:

“We don’t have a law or policy on EA in the state

agencies; it’s just one option among many. That

means we have problems when working with other

agencies, so we just focus on IT rather than on busi-

ness perspectives.”

The variance in stakeholders’ backgrounds, skills, and ca-

pabilities influenced EA adoption during the early stage, and

this variance caused difficulties in promoting EA during the

initiation phase, since collaboration practices and the scope,

scale, and level of detail of EA functionalities first had to be

negotiated and defined. As an IT specialist from Omega said,

“Our agencies… conduct [EA] planning with… differ-

ent understandings of the benefits, and they [stake-

holders] come from different backgrounds. This makes

it difficult to create [common] plans, as we must con-

stantly negotiate with others.”

4.2 Normative Pressures on EA Adoption

Normative pressures are usually influenced by other institu-

tions. This situation became apparent when an organization’s

EA approaches were unclear. Our findings suggest that nor-

mative factors were not a significant factor during the initia-

tion phase. As a PM from Eta articulated,

“Certain approaches were used in the early stage of EA

adoption in different organizations. For example, some

used [international] consultants to establish their re-

quirements [for EA functionalities], and some used their

own IT department. However, the results were different,

even though they used a similar approach. This is be-

cause EA can be understood as everything from strategy

to planning, depending on the adopters …”

The norms varied between different organizations. For ex-

ample, some organizations used EA as an independent com-

ponent for certain dedicated agencies only, and not for the

whole organization. In contrast, sometimes EA was seen to

supplement IT programs within organizations. In both situa-

tions, the norms did not influence these approaches.

Although organizations can place normative pressures on

one another, our findings indicate that such an influence is

unclear. This situation can be explained by the fact that EA

approaches vary because of a lack of general definitions,

agreements, frameworks, and standards. This variance caused

the organizations to copy each other when choosing the EA or

its approaches. Such mimicking is not adequate, however,

because of the complexity of EA. As Omega’s CIO stated,

“We were proposing EA independently from other EA

projects [from China, Singapore, and a local organiza-

tion], because we recognized that there’s no single ap-

proach that fits with every organization adopting EA.”

It was also evident that the organizations treated EA as a

normal IT project, with a focus on purchasing software and

hardware. The organizations neglected the business perspec-

tives of their EA projects. The EA projects also appeared to

last longer than the manager’s single term, which put EA

project activities at risk, as the new manager may not have

cared about the old manager’s projects, including EA. This

scenario resulted in organizations dividing their EA projects

into several subprojects. As an IT specialist from Omega

stated,

“Our EA project is divided into several subprojects,

managed by different agencies within the organization.

At the same time, they [the leaders in the agencies] were

responsible for a number of other [non-EA] projects,

with similar sets of objectives…. This breaks down the

unity of EA project.”

4.3 Regulative Pressures on EA Adoption

While regulative pressures were less dominant in the initiation

phase of EA adoption, the case organizations had to conform

to policies and protocols governing their projects once the

adoption process moved on to the implementation phase.

For example, implementation activities had to follow project

management policies and protocols, and interoperability is-

sues needed agreements from involved agencies. In addition,

politicians, sponsors, and other powers put pressure on stake-

holders, which led to conflicts between the stakeholders, who

consequently reacted differently to the EA project activities.

For example, in Eta some of the services connecting the agen-

cies and their IS were not implemented because the stake-

holders had followed organizational policies on intra-

organizational services.

The organizations usually either followed their own ap-

proaches to implementing EA or were heavily influenced by

their sponsor; for example, Eta adopted the FEA framework at

its sponsors’ suggestion. This points out the main differences

between the cases: regulative factors appeared Eta clearer than

those that in Omega, while cognitive-cultural factors in Eta

seemed more complex than those in Omega. In the words of

an Eta enterprise architect,

“We had advice and pressure to follow a certain ap-

proach [suggested by the sponsor] in a very different

environment [in comparison to Eta’s environment in

terms of political climate, organizational structures, ca-

pabilities, and skills]. This created a very complex situ-

ation for deploying EA [into Eta].”

Many agencies were involved in the EA implementation.

Each agency had its own objectives and powers, so severe

difficulties in implementing EA emerged, for example in

terms of sharing information with other agencies or having

conflicting interests and information asymmetries among the

parties. This situation caused the EA adoption to fall behind

schedule, hindering cooperation between the parties and re-

ducing the use of EA in practice. In the words of an enterprise

architect from Omega,

“Some leaders [at Omega’s agencies] were afraid that

once EAwas implemented into their agencies, their roles

and other advantages would be reduced…. This concern

was solved when senior managers became involved in

Inf Syst Front

implementation. Then the leaders had to obey [the se-

nior managers’] orders.”

Regulative pressures were also enforced by stakeholders

from external institutions, who were typically thought of as

experts in EA adoption. However, their involvement did not

always have a positive impact on EA adoption. For example,

due to a sponsor’s request, experts from developed countries

were imported to participate in EA implementation in Eta. The

experts used their earlier experiences and approaches to

implementing EA within Eta. These outside ideas and prac-

tices were ineffective since Eta’s socio-technical and socio-

political environments were not considered. Ultimately, EA

project in Eta turned out to be not particularly successful. In

the words of Eta’s PM,

“We received funding for our EA project [from the

sponsor]. We had to deploy EA and establish several

groups to comply with their funding policies. If we

didn’t follow them, we might have lost their support….

However, most of the ideas and proposals from them

[the experts] were simply inapplicable to Eta, as they

required business-process reforms and changes to all

levels of the administrative hierarchy. This was

impossible.”

Regulative pressures dominated the implementation phase.

However, some events indicate that norms and rules also ap-

peared. For example, due to inefficient tools and methods the

quality control of EA products was poor. Consequently EA

project teams applied the techniques they were familiar with,

and that had been approved and used by their organization.

Yet those methods were inappropriate for EA. This made it

impossible to estimate EA project activities and their perfor-

mance and risks.

4.4 Institutional Pressures Roles in each Phase of EA

Adoption

The absence of appropriate EA policies and successful EA

precedents was evident. EA-adoption activities were thus

depended on individual people and their characteristics, i.e.

their cognitive-cultural factors. In particular, the characteris-

tics of senior managers and project team members played

important roles in the initiation phase in terms of steering the

adoption process, defining EA products, and increasing the

stakeholders’ awareness. Cognitive-cultural factors thus influ-

ence the implementation phase, and further the whole project.

Normative factors emerged when other institutions tried to

influence stakeholders in their selection of EA functionalities.

For example, Eta was influenced by the sponsor through con-

sultants. As a result, Eta mimicked the EA approaches used in

Inf Syst Front

the developed countries while Omega utilized its own ap-

proaches. Professional groups influenced the technological

choices in Omega.

In relation to regulative pressures, the cases were not sub-

ject to any formal rules for EA projects. For that reason, senior

managers tailored policies and formalized rules for establish-

ing EA. This resulted in organizational members to consider

the rules to be less important during the initiation phase. They

however became crucial during the implementation phase

when the projects were split into explicit tasks and activities.

For example, legal rules for governing public IT investments

strongly influenced the implementation phase. Table 4 sum-

marizes institutional factors influencing EA adoption.

5 Discussion

5.1 Cognitive Pressures Determine Project Direction

in the Initiation Phase

Our case organizations adopted EA on their own premises and

according to their perceptions and expectations about how EA

could help them reform administrative procedures, align busi-

ness and IT applications, and increase IS interoperability. The

cases shared a number of features when they chose EA. The

EA projects, architectures, approaches, tasks, and products

were initiated and influenced by senior managers, and two

main groups participated in the very early stage: the manage-

ment team and the project team. We argue that cognitive fac-

tors are more emergent and important than normative and

regulative pressures in the early stage of adoption.

Particularly important are cognitive-cultural issues related to

the managers’ understanding and perception of the role of EA

in organizations (as in Omega) and the stakeholders’ knowl-

edge of EA functionalities (as in Eta).

Table 4 Cognitive, normative,

and regulative factors in EA

adoption

Regulatory factors, such as legal frameworks and gover-

nance practices, can be thought of as a prerequisite for EA

projects (Saha 2008). But these items are more prevalent in

developed countries with stable governance, sufficient re-

sources, and high levels of IT awareness (Dang 2017;

Janssen and Hjort-Madsen 2007). In our cases, frequent

changes occurred in governmental structures and governance

practices; in addition, legal frameworks were unstable, and

necessary resources were lacking. Under the circumstances,

senior managers and others in charge of EA adoption steered

the EA implementations. For example, while Omega pro-

duced both physical and document-based strategic-planning

products, Eta’s product was solely document based.

Both organizations had little knowledge of the benefits of

EA before their decision to adopt EA. They only expected EA

to help in reforming administrative procedures and services, to

reduce the number of information systems in use, and to im-

prove interoperability. This finding parallels the literature on

unclear and intangible EA benefits (Lange et al. 2015; Niemi

and Pekkola 2016; Shanks et al. 2018) and emphasizes the

importance of cognitive factors in the early stage of EA

adoption.

Furthermore, although formal policies had little impact dur-

ing the initiation phase, informal regulative factors within pow-

erful agencies affected EA projects. For example, financial

departments or agencies led by senior managers seemed to be

more successful in taking responsibility for EA projects than

less powerful agencies. In Eta’s situation, the agencies in which

EA projects had been assigned to IT departments suffered from

a lack of credibility. In the case of Omega, it became clear that

the higher the agency’s status in the organizational pecking

order, the more successful its EA project would likely be.

This situation parallels the assignment of responsibility for

EA projects to the US Office of Management and Budget

(Bellman and Rausch 2004) and to the committee under the

president of South Korea (Lee and Kwon 2013). The finding is

Initiation phase Implementation phase

Values– Values related to the adoption context (e.g.,

technology, strategy, planning) and readiness

and awareness of stakeholders

– Values related to the perception of EA products,

and how to assess them

– Values related to the change behavior (e.g.,

users’ responses to EA project activities and

products)

– Values related to the implementation of the EA

approach (e.g., how stakeholders switch from

traditional approaches to new ones)

Norms– Norms related to how the organizations should

Norms related to work practices (e.g., project

approach and establish EA projects

management practices)

– Norms related to approaches used in other

organizations

Rules– Rules when deciding to adopt EA initiatives– Rules on project protocols (e.g., procedures,

reporting, management)

– Rules in agencies that are assigned

– Rules on how EA projects are organized and

responsibilities for project activities

approved

– Rules on inter- and intra-agency cooperation

Inf Syst Front

also aligned with Löhe and Legner’s (2014) work on the im-

portance of having explicit goals for EA initiatives. No re-

searchers to date have mentioned when such roles, responsi-

bilities, and goals should be determined. This study thus sup-

plements the literature by indicating the roles of both the stake-

holders’ backgrounds and informal EA policies during the ear-

ly stage of adoption.

5.2 Regulative Pressures Dominate EA

Implementation

Regulative pressures were found to have emerged during

the implementation phase. Similarly to any project within

an organization, EA projects also had to follow procedural

and financial policies. In both cases, these external pres-

sures affected the entire process of implementation. For

example, in addition to governmental policies, Eta was

required to follow its sponsor’s protocols and instructions

in all activities related to EA implementation. Regulative

factors thus played an important role for EA adoption in

the implementation phase. Although earlier studies have

identified the importance of regulative factors (Chatterjee

et al. 2002; Liang et al. 2007; Teo and Pian 2003), we have

explicitly shown the phase of the adoption process in

which regulative factors are influential.

Regulative pressures created several conflicts between ex-

ternal and internal institutions within the two cases—for in-

stance among project members and senior managers. Because

the collaborations that were formed within EA projects varied,

these conflicts escalated to other institutions (i.e., to other

agencies within the organizations). These conflicts extended

the schedules in Eta, while in Omega, the conflicts confined

the project scope exclusively to IT perspectives. This situation

highlights the role of internal formal and informal policies and

of the senior managers who handle the conflicts. In Omega,

the top managers led the EA projects, which made it easier to

resolve inter- and intra-agency issues. In contrast, Eta projects

that were led by less important departments (such as the IT

department) faced risks in cooperating with other agencies.

This scenario arose because different stakeholders had differ-

ent viewpoints (Isomäki and Liimatainen 2008; Janssen and

Hjort-Madsen 2007). We argue that EA should be planned in a

way that acknowledges existing organizational structures and

policies.

The impact of norms and values was less visible during the

implementation phase. This is understandable, as EA imple-

mentation is a matter of following administrative acts and

orders, technical-compliance guidelines, and different poli-

cies, all of which regulate the activities. The situation differs

significantly from the initiation phase, where the stakeholders

struggled with different views of EA usage and appropriate-

ness as well as lacking instructions and policies.

5.3 How Institutional Pressures Roles Change

Although the literature has pointed out the role of institutional

pressures (Bharati et al. 2014; Khalifa and Davison 2006; Krell

et al. 2009; Liang et al. 2007; Teo and Pian 2003; Yoon and

George 2013; Zheng et al. 2013), the ways in which they

influence different phases during the adoption process remain

unclear (Mignerat and Rivard 2009; Weiss et al. 2013; Dang

2017). This section illustrates how the institutional factors steer

the adoption process and ultimately shape the adoption.

Cognitive factors relate to one’s own values and volition.

They seem to play significant roles in the initiation phase of

EA adoption. This means that the stakeholders’ backgrounds

and experiences influenced activities towards EA adoption,

such as adoption direction, frameworks, and products.

Improving these issues requires a willingness to change behav-

iors and to reconsider personal values, neither of which are

easy to do (DiMaggio and Powell 1983; Suchman 1995). In

contrast, regulative factors are typically imposed by govern-

ments or organizations. They seems to be very important in the

implementation phase of EA adoption. Two kinds of regulative

factor, related to formal and informal rules, emerged. Formal

rules refer to regulatory behaviors within a given society, while

informal rules originate from senior managers and power insti-

tutions. The informal rules can be replaced by new ones from

other settings (Scott 2005). In our cases, all agencies imple-

mented EA according to their own informal rules, including

rules for governing project responsibility, cooperation, and

project organizations. This indicates the importance of effects

of local rules and practices—that is, the organizational culture

in a broader sense (Niemi and Pekkola 2016). Relying solely

on formal rules is inadequate for EA implementation. This

shows that the relative importance of values, norms, and rules

changes when the adoption process evolves within different

institutions. When the institutions are more involved in the

EA implementation, regulative factors become more dominant

and cognitive-cultural factors become more complex.

Normative factors, which are typically influenced and

enforced by peer groups, were less evident in both initiation

and implementation phases. Normative factors are usually poor-

ly articulated and therefore difficult to identify (Hu and Huang

2006; Chandwani and De 2016). Figure 2 illustrates the relative

importance of cognitive, normative, and regulative factors in the

process of EA adoption. Values are central at the early stage,

while rules become dominant during the implementation phase

when the stakeholders must follow organizational rules.

6 Conclusions, Implications, and Limitations

In this paper, we have explored how institutional factors in-

fluence the process of EA adoption in different phases and

how those factors change over time. We have discussed these

Inf Syst Front

Fig. 2 The relative importance of

institutional factors in EA

adoption

Importance

Values

Rules

Rules and

norms

Values and

norms

Phase

Initiation Implementation

findings earlier; next we will present the contributions, impli-

cations, and limitations of our study.

First, the literature has indicated the role of cognitive, nor-

mative, and regulative pressures when new information sys-

tems are adopted (Bharati et al. 2014; Khalifa and Davison

2006; Krell et al. 2009; Liang et al. 2007; Teo and Pian 2003;

Yoon and George 2013; Zheng et al. 2013). But the ways in

which these pressures influence the adoption process in its

different phases remain unknown, from establishing the tech-

nology or practice (i.e., EA in this case) to EA institutionali-

zation. Cognitive pressures appear to dominate during the

early phases, while regulative pressures seem to become im-

portant during the implementation phase of EA adoption.

Second, although institutional theory is used in the EA liter-

ature, the theory is used to study on the barriers of institution-

alization (Iyamu 2009), interoperability challenges (Hjort-

Madsen and Gøtze 2004), governmental pressures (Hjort-

Madsen, 2007), or institutional logics within EA adoption

(Dang 2019). These studies have not revealed how

individuals and groups are involved in or are influenced by

the pressure. From this perspective, our study offers a rare

analysis of individuals and groups in institutions, as suggested

by Mignerat and Rivard (2009) and Weiss et al. (2013). Our

findings indicate how values, norms, and rules appear and

changes in different phases in the process of EA adoption, all

of which advances institutionalization in the EA context.

Third, EA studies are primarily focusing on the developed

countries contexts (Dang and Pekkola 2017; Simon,

Fischbach, and Schoder 2013). Recently, however, EA has

become of increasing interest around the world (Dang and

Pekkola 2017; Shanks et al. 2018), especially in the develop-

ing world (Dang and Pekkola 2017). Because only a few EA

studies have focused on developing countries (Dang and

Pekkola 2017), we thus contributes to this front. We argue that

our findings can be generalized to similar contexts in terms of

stakeholders and their values or organizational cultures, ad-

ministrative hierarchies, income, human capacity, ICT infra-

structure, and resources, such as another provinces, ministries,

and line of businesses no matter whether developed or devel-

oping country.

The paper also has practical implications. Our highlighting of

institutional factors at different phases enables practitioners to

design strategies to respond to different adoption challenges.

Table 4 may be thought of as a starting point for designing such

strategies. Managers should consider how to harmonize and bal-

ance their organizational values, norms, and rules between old

and new environments, which would benefit practitioners in

solving problems that emerge during the adoption process. In

contrast, if these issues are not taken into account, then a number

of challenges are likely to arise, often leading to the failure of EA

adoption. Having a better understanding of EA project activities

and institutional pressures will clarify the shaping of activities

and behaviors at both the organizational and the individual level,

which will help managers to better prepare for EA adoption.

One limitation of this study is that we have addressed only

two cases within a single country. Although this is indeed a

limitation, understanding the context is also an important consid-

eration (Davison and Martinsons 2016). Consequently, even

though we have illuminated stakeholders’ behavior and activities

in this study, more research is still needed to illustrate the nuances

of these phenomena; for example, the relative importance of rules

and values may vary between organizations. While our focus on

EA adoption also suggests that the results are bound to the EA

context, we contend that the institutionalization of EA resembles

any socio-technical assemblage. Overall, then, our cases provide

a foundation for understanding the adoption of organization-

wide practices or technologies. In the future, we hope to combine

institutional perspectives with a cross-nation analysis to under-

stand problems in their wider context and to facilitate theoretical

and practical development.

Acknowledgments This study was partly funded by the Academy of

Finland, grant # [306000]. We would like to thank the editors and two

anonymous reviewers for their invaluable comments, which greatly

helped us improve the paper.

A previous version of this paper was presented at the 24th European

Conference on Information Systems (ECIS 2016), Istanbul, Turkey,

Inf Syst Front

research paper: 139, entitled“Institutionalising Enterprise Architecture in

the Public Sector in Vietnam”

, http://aisel.aisnet.org/ecis2016_rp/139.

Funding Information Open access funding provided by University of

Vaasa (UVA).

Open Access This article is distributed under the terms of the Creative

C o m m o n s A t t r i b u t i o n 4 . 0 I n t e r n a t i o n a l L i c e n s e ( h t t p : / /

creativecommons.org/licenses/by/4.0/), which permits unrestricted use,

distribution, and reproduction in any medium, provided you give appro-

priate credit to the original author(s) and the source, provide a link to the

Creative Commons license, and indicate if changes were made.

References

Ajer, A. K., and Olsen, D. H. (2018). Enterprise Architecture Challenges:

A Case Study of Three Norwegian Public Sectors, in: European

Conference on Information Systems. Portsmouth, UK.

Alzoubi, Y. I., Gill, A. Q., & Moulton, B. (2018). A measurement model to

analyze the effect of agile Enterprise architecture on geographically dis-

tributed agile development. Journal of Software Engineering Research

and Development. https://doi.org/10.1186/s40411-018-0048-2.

Armour, F. J., & Kaisler, S. H. (2001). Enterprise architecture: Agile

transition and implementation. IT Professional, 3(6), 30–37.

Armour, F. J., Kaisler, S. H., & Liu, S. Y. (1999). Building an Enterprise

architecture step by step. IT Professional, 1(4), 31–39.

Banaeianjahromi, N., & Smolander, K. (2017). Lack of communication and

collaboration in Enterprise architecture development. Information

Systems Frontiers. https://doi.org/10.1007/s10796-017-9779-6.

Bellman, B., & Rausch, F. (2004). Enterprise architecture for e-govern-

ment. In R. Traunmüller (Ed.), Electronic government: Proceedings

of the 3rd [IFIP WG 8.5] international conference, EGOV 2004 (pp.

48–56). Spain: Zaragoza.

Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The case research strategy

in studies of information systems. MIS Quarterly, 11(3), 369–386.

Berente, N., & Yoo, Y. (2012). Institutional contradictions and loose

coupling: Postimplementation of NASA’s Enterprise information

system. Information Systems Research, 23(2), 376–396.

Bharati, P., Zhang, C., & Chaudhury, A. (2014). Social media assimilation

in firms: Investigating the roles of absorptive capacity and institution-

al pressures. Information Systems Frontiers, 16(2), 257–272.

Bondar, S., Hsu, J. C., Pfoug, A., & Stjepandić, J. (2017). Agile digital

transformation of system-of-systems architecture models using

Zachman framework. Journal of Industrial Information

Integration, 7(September), 33–43.

Chandwani, R., & De, R. (2016). Doctor-patient interaction in telemedi-

cine: Logic of choice and logic of care perspectives. Information

Systems Frontiers, 19(4), 955–968.

Chatterjee, D., Grewal, R., & Sambamurthy, V. (2002). Shaping up for E-

commerce: Institutional enablers of the organizational assimilation

of web technologies. MIS Quarterly, 26(2), 65–89.

Cloutier, C., & Langley, A. (2013). The logic of institutional logics:

Insights from French pragmatist sociology. Journal of

Management Inquiry, 22(4), 360–380.

Dang, D. (2017). Enterprise architecture institutionalization: A tale of two

cases, in Proceedings of the 25th European Conference on

Information Systems (ECIS). Guimarães, Portugal.

Dang, D. (2019). Institutional logics and their influence on enterprise

architecture adoption. Journal of Computer Information Systems,

1–11. https://doi.org/10.1080/08874417.2018.1564632.

Dang, D. D., & Pekkola, S. (2016). Institutionalising enterprise architec-

ture in the public sector in Vietnam, In Proceedings of the 24th

European Conference on Information Systems (ECIS). İstanbul,

Turkey.

Dang, D. D., & Pekkola, S. (2017). Systematic literature review on en-

terprise architecture in the public sector. Electronic Journal of e-

Government, 15(2), 130–154.

Dang, D., Vartiainen, T., and Pekkola, S. (2019). Patterns of Enterprise

Architecture Adoption in the Public Sector: A Resource-Based

Perspective, in: 27th European Conference on Information

Systems. Stockholm and Uppsala, Swenden.

Davison, R. M., & Martinsons, M. G. (2016). Context is king!

Considering particularism in research design and reporting.

Journal of Information Technology, 31(3), 241–249.

DiMaggio, P. J., & Powell, W. W. (1983). The iron cage revisited:

Institutional isomorphism and collective rationality in organizational

fields. American Sociological Review, 48(2), 147–160.

Eisenhardt, K. M. (1989). Building theories from case study research.

Academy of Management Review, 14(4), 532–550.

Friedland, R., & Alford, R. R. (1991). Bringing society back in: Symbols,

practices, and institutional contradictions. In W. W. Powell & P. J.

DiMaggio (Eds.), The new institutionalism in organizational

analysis (pp. 232–263). Chicago: University of Chicago Press.

Hjort-Madsen, K. (2007). Institutional patterns of enterprise architecture

adoption in government. Transforming Government: People,

Process and Policy, 1(4), 333–349.

Hjort-Madsen, K., & Gøtze, J. (2004). Enterprise architecture in government -

Towards a multi-level framework for managing IT in government. Paper

presented at the Proceedings of ECEG04, Dublin, Ireland.

Hu, Q., & Huang, C. D. (2006). The rise and fall of the competitive local

exchange carriers in the U.S.: An institutional perspective.

Information Systems Frontiers, 8(3), 225–239.

Hylving, L., & Bygstad, B. (2019). Nuanced responses to Enterprise

architecture management: Loyalty, voice, and exit. Journal of

Management Information Systems, 36(1), 14–36.

Isomäki, H., & Liimatainen, K. (2008). Challenges of government enter-

prise architecture work– Stakeholders’ views. In M. A. Wimmer, H.

J. Scholl, & E. Ferro (Eds.), Electronic government: Proceedings of

the 7th [IFIP WG 8.5] international conference, EGOV 2008 (pp.

364–374). Italy: Turin.

Iyamu, T. (2009). The factors affecting institutionalisation of enterprise

architecture in the organisation. Paper presented at the IEEE

Conference on Commerce and Enterprise Computing (CEC '09),

pp. 221–225., Vienna, Austria.

Janssen, M., & Hjort-Madsen, K. (2007). Analyzing enterprise architecture in

national governments: The cases of Denmark and the Netherlands.

Paper presented at the Proceedings of the 40th Hawaii International

Conference on System Sciences, Waikoloa, HI, USA.

Jepperson, R. L. (1991). Institutions, institutional effects, and institution-

alization. In W. W. Powell & P. J. DiMaggio (Eds.), The new insti-

tutionalism in organizational analysis (pp. 143–163). Chicago:

University of Chicago Press.

Jonkers, H., Lankhorst, M. M., Doest, H. W. L. t., Arbab, F., Bosma, H.,

& Wieringa, R. J. (2006). Enterprise architecture: Management tool

and blueprint for the organisation. Information Systems Frontiers,

8(2), 63–66.

Kappelman, L. A., & Zachman, J. A. (2013). The Enterprise and its

architecture: Ontology & Challenges. Journal of Computer

Information Systems, 53(4), 87–95.

Khalifa, M., & Davison, R. M. (2006). SME adoption of IT: The case of

electronic trading systems. IEEE Transactions on Engineering

Management, 53(2), 275–284.

Krell, K., Matook, S., & Matook, F. (2009). The effects of regulatory

pressure on information systems adoption success: An institutional

theorey pespecitve, European Conference on Information Systems

(ECIS), Verona, Italy.

Inf Syst Front

Lange, M., Mendling, J., & Recker, J. (2015). An empirical analysis of

the factors and measures of enterprise architecture management suc-

cess. European Journal of Information Systems, 25(5), 411–431.

Lee, J. D., & Kwon, Y. I. (2013). A study on strategy planning and

outcome of EA in Korea. Paper presented at the 15th International

Conference on Advanced Communication Technology (ICACT).

Liang, H., Saraf, N., Hu, Q., & Xue, Y. (2007). Assimilation of enterprise

systems: The effect of institutional pressures and the mediating role

of top management. MIS Quarterly, 31(1), 59–87.

Löhe, J., & Legner, C. (2014). Overcoming implementation challenges in

enterprise architecture management: A design theory for

architecture-driven IT management (ADRIMA). Information

Systems and e-Business Management, 12(1), 101–137.

Magnusson, J., & Nilsson, A. (2006). Infusing an architectural framework

with neo-institutional theory: reports from recent change manage-

ment initiatives within the Swedish public administration,

Proceedings of the 39th Annual Hawaii International Conference

on System Sciences. Kauai, Hawaii, USA: IEEE.

Magoulas, T., Hadzic, A., Saarikko, T., & Pessi, K. (2012). Alignment in

enterprise architecture: A comparative analysis of four architectural

approaches. Electronic Journal Information Systems Evaluation,

15(1), 88–101.

Mahalingam, A., & Levitt, R. E. (2007). Institutional theory as a frame-

work for analyzing conflicts on global projects. Journal of

Construction Engineering and Management, 133(7), 517–528.

Mignerat, M., & Rivard, S. (2009). Positioning the institutional perspec-

tive in information systems research. Journal of Information

Technology, 24(4), 369–391.

Miles, M. B., & Huberman, A. M. (1994). Qualitative data analysis.

Thousand Oaks: Sage.

Myers, M. D. (1997). Qualitative research in information systems. MIS

Quarterly, 21(2), 241–242.

Niemi, E., & Pekkola, S. (2016). Enterprise architecture benefit realiza-

tion: Review of the models and a case study of a public organization.

ACM SIGMIS Database, 47(3), 55–80.

Niemi, E., & Pekkola, S. (2017). Using enterprise architecture artefacts in

an organisation. Enterprise Information Systems, 11(3), 313–338.

Oliver, C. (1991). Strategic responses to institutional processes. Academy

of Management Review, 16(1), 145–179.

Orlikowski, W. J., & Barley, S. R. (2001). Technology and institutions:

What can research on information technology and research on orga-

nizations learn from each other? MIS Quarterly, 25(2), 145–165.

Orlikowski, W. J., & Baroudi, J. J. (1991). Studying information technol-

ogy in organizations: Research approaches and assumptions.

Information Systems Research, 2(1), 1–28.

Powell, W. W., & DiMaggio, P. J. (1991). The new institutionalism in

organizational analysis. Chicago: University of Chicago Press.

Ribeiro, J. A., & Scapens, R. W. (2006). Institutional theories in manage-

ment accounting change. Qualitative Research in Accounting &

Management, 3(2), 94–111.

Ross, J. W. (2009). Information technology strategy-creating a strategic IT

architecture competency: Learning in stages. In R. D. Galliers & D. E.

Leidner (Eds.), Strategic Information Management: Challenges and

Strategies in Managing Information Systems (pp. 584): Routledge.

Saha, P. (2008). Advances in government enterprise architecture.

Hershey, New York: Information Science Reference (IGI Global).

Schmidt, C., & Buxman, P. (2011). Outcomes and success factors of

Enterprise it architecture management: Empirical insight from the

international financial services industry. European Journal of

Information Systems, 20(2), 168–185.

Scott, W. R. (2005). Institutional theory. In Encyclopedia of Social

Theory (pp. 408–414): Thousand Oaks, CA: Sage.

Shah, H., & Kourdi, M. E. (2007). Frameworks for enterprise architec-

ture. IT Professional, 9(6), 36–41.

Shanks, G., Gloet, M., Someh, I. A., Frampton, K., & Tamm, T. (2018).

Achieving benefits with enterprise architecture. Journal of Strategic

Information Systems, 27(2), 139–156.

Simon, D., Fischbach, K., & Schoder, D. (2013). An exploration of en-

terprise architecture research. Communications of the Association

for Information Systems, 32(1), 1–72.

Simon, D., Fischbach, K., & Schoder, D. (2014). Enterprise architecture

management and its role in corporate strategic management. Inf Syst

E-Bus Manage, 12(5), 5–42.

Stake, R. E. (2005). Qualitative Case Studies. In N. K. Denzin & Y. S.

Lincoln (Eds.), The SAGE handbook of qualitative research (3rd ed.,

pp. 443–466). Thousand Oaks: Saga.

Strauss, A., & Corbin, J. (1998). Basics of qualitative research (2 ed.):

Saga, Thousand Oaks, Calif.

Suchman, M. C. (1995). Managing legitimacy: Strategic and institutional

approaches. Academy of Management Review, 20(3), 571–610.

Teo, T. S., & Pian, Y. (2003). A contingency perspective on internet

adoption and competitive advantage. European Journal of

Information Systems, 12(2), 78–92.

Walsham, G. (1995). Interpretive case studies in IS research: Nature and

method. European Journal of Information Systems, 4(2), 74–81.

Webster, J., & Watson, R. T. (2002). Analyzing the past to prepare for the

future: Writing a literature review. MIS Quarterly, 26(2), xiii–xxiii.

Weiss, S., Aier, S., & Winter, R. (2013). Institutionalization and the

effectiveness of enterprise architecture management. Paper present-

ed at the Thirty Fourth International Conference on Information

Systems, Milan, Italy.

Yoon, T. E., & George, J. F. (2013). Why aren’t organizations adopting

virtual worlds? Computers in Human Behavior, 29(3), 772–790.

Zheng, D. Q., Chen, J., Huang, L. H., & Zhang, C. (2013). E-government

adoption in public administration organizations: Integrating institu-

tional theory perspective and resource-based view. European

Journal of Information Systems, 22(2), 221–234.

Publisher’s Note Springer Nature remains neutral with regard to jurisdic-

tional claims in published maps and institutional affiliations.

Duong Dang , PhD, is Assistant professor at University of Vaasa,

Finland. His research interests include enterprise architecture, digital

transformation, IT management, IT governance, and digital strategy.

His research work has appeared in Information Systems Frontiers,

Journal of Computer Information Systems, Electronic Journal of e-

Government, International Series in Operations Research &

Management Science of Springer, and several leading IS conferences.

Samuli Pekkola , PhD, is Professor at Tampere University, Finland. His

research focuses on IS management and acquisition, and enterprise archi-

tectures and infrastructures, both in the context of public sector. His re-

search has appeared e.g. in ISJ, SJIS, BISE, EIS, EIM, DSS, CAIS, and

The DATA BASE. He serves on the editorial boards of Business

Information Systems and Engineering and Scandinavian Journal of

Information Systems. He is President of the Scandinavian Chapter of