The benefitsofenterprisearchitecture.2020

RESEARCH PAPER
The Benefits of Enterprise Architecture in Organizational
Transformation
Eetu Niemi • Samuli Pekkola
Received: 31 July 2018 / Accepted: 3 May 2019 / Published online: 19 June 2019
The Author(s) 2019
Abstract Today, as organizations constantly adjust their
activities to meet ever-changing circumstances, continuous
business transformation is taking place. However, planning
and steering this transformation can be a daunting task as
complexity has been built into the organization over the
years. Enterprise Architecture (EA) has been widely
adapted as a planning and governance approach to manage
the complexity and constant change, and to align the
organization toward a common goal. This article studies
the EA benefit-realization process by clarifying how EA
benefits are realized. Specifically, the focus is on the
strategies, resources, and practices which the EA benefits
stem from. The findings, derived from an in-depth case
study, show that the EA benefit-realization process con-
stitutes a long, intertwined chain of activities. Organiza-
tions benefit from EA through various means: from the
initiation, when comprehensive understanding starts to
form, until years later, when measurable outcomes such as
cost savings materialize. Suggestions on what to incorpo-
rate into EA programs are presented.
Keywords Enterprise architecture Organizational
transformation Benefit-realization process Value Case
study
1 The Need for Enterprise Architecture
In today’s volatile business environment, organizations
constantly adjust their activities to the changing circum-
stances—business transformation1
is continuously taking
place. However, with the long legacy of organizational
activities, processes, and IT development, planning and
steering the transformation can be a daunting task as com-
plexity has been built into the organization over the years.
The organizations often lack a clear overall view of their
business functions, processes, information systems (IS), and
individual technical platforms, such as servers and data-
bases, and of their mutual dependencies. This makes it dif-
ficult to execute the transformation initiatives in the most
beneficial way. As a result, business and IT improvement
often takes place in silos, without comprehensively consid-
ering the organizational viewpoint and transformation as a
whole. Transformation projects overrunning their budgets
and schedules, unable to reach the overall goals, are all too
familiar examples of this challenge (Bloch et al. 2012).
Traditional transformation approaches such as strategic
planning, process improvement, IT governance, and pro-
gram management are, on their own, unable to change this
course, as they lack the holistic picture and the ‘‘glue’’ that
holds the transformation together.
Accepted after one revision by Jelena Zdravkovic.
Electronic supplementary material The online version of this
article (https://doi.org/10.1007/s12599-019-00605-3) contains sup-
plementary material, which is available to authorized users.
E. Niemi ()
Coala Ltd, Helsinki, Finland
e-mail: einiemi@gmail.com
S. Pekkola
Faculty of Management and Business, Tampere University,
Tampere, Finland
e-mail: samuli.pekkola@tuni.fi
1
Transformation, in the context of organizations, is a fundamental
change that significantly alters an organization’s relationship with one
or more of its key constituencies, such as customers, employees,
suppliers and investors (Proper et al. 2017).
123
Bus Inf Syst Eng 62(6):585–597 (2020)
https://doi.org/10.1007/s12599-019-00605-3

The Enterprise Architecture (EA) approach has been
widely adapted as a planning and governance approach to
manage the complexity and constant change, and to align
organizational resources toward a common goal (Tamm
et al. 2011). EA encompasses an organization’s business
capabilities, business processes, information, IS, and
technical infrastructure, and facilitates the integration of
strategy, personnel, business, and IT (Kaisler et al. 2005).
Despite obviously beneficial EA, EA implementation
endeavors are often questioned and challenged as their
benefits are difficult to dissect (Potts 2010; Rodrigues and
Amaral 2010). In the literature, there is still no common
understanding of EA, or how it should be developed,
managed, and used to reap the most benefits from the
approach (Dang and Pekkola 2017; Sidorova and Kappel-
man 2011). Particularly concrete benefits resulting from
EA have turned out to be challenging to demonstrate, not to
mention the process of benefit realization itself: Where do
the benefits actually stem from?
There are a few empirical studies linking EA activities
to actual benefits (Foorthuis et al. 2010; Hazen et al. 2017;
Kurek et al. 2017; Lange et al. 2012; Schmidt and Bux-
mann 2011). Additionally, the benefit-realization process
itself has been addressed (e.g., Alaeddini et al. 2017;
Foorthuis et al. 2015; Lange et al. 2016; Shanks et al.
2018). Despite these studies, it is unclear how EA benefits
are realized and where the EA benefits actually stem from,
as the studies are often abstract or contradictory. As a
consequence, the challenges in planning and implementing
EA practices and comprehending EA benefit realization are
evident. EA implementation projects and their business
cases remain difficult to discuss.
In this article, we dive into the EA benefit-realization
process by clarifying how EA benefits are realized. Particu-
larly, we focus on the strategies, resources, and practices,
which the EA benefits stem from. First, we take a brief look at
the current research on EA and EA benefit realization. Then
we report findings from an in-depth case study and show how
the benefits constitute from a long, intertwined chain of
activities. We argue that organizations benefit from EA
through various means: from the first day, when compre-
hensive understanding starts to form, until years later, when a
measurable outcome—cost savings—materializes.
2 Current Research on Enterprise Architecture Benefit
Realization
2.1 Enterprise Architecture and Its Use
EA is ‘‘the definition and representation of a high-level
view of an enterprise‘s business processes and IT systems,
their interrelationships, and the extent to which these
processes and systems are shared by different parts of the
enterprise’’ (Tamm et al. 2011). This emphasizes EA being
both a process and its product.
EA management operations, i.e. EA processes, provide
direction and support in the design and management of the
EA to support the organizational transformation (van der
Raadt and van Vliet 2008). Often EA management (EAM)
encompasses the management activities conducted in an
organization to install, maintain, and purposefully develop
an organization’s EA (Lange et al. 2016). EAM and EA
processes include activities such as EA planning, which
deals with decisions about the EA target state, documented
in new and existing EA documents (Nikpay et al. 2017;
Nowakowski et al. 2017). EA governance, on the other
hand, seeks to ensure that the documents are used in and
for guiding individual development activities in the orga-
nization’s transformation journey, facilitating the compli-
ance of solutions toward the EA (Shanks et al. 2018).
EA products are the outputs of EA processes, such as
documentation and services. Documentation includes
architectural models, standards, principles, and other
knowledge items describing the organization’s business,
information, IS, and technology, on different levels of
abstraction for varying needs (Aier 2014; Boh and Yellin
2007; Tamm et al. 2011). In addition to describing the
current state of the organization, they describe the target
state and a plan of how to reach it (Hjort-Madsen and Pries-
Heje 2009; Kaisler et al. 2005; Nikpay et al. 2017; Tamm
et al. 2011). EA services, on the other hand, are commu-
nication and collaboration interfaces of the EA processes
toward EA stakeholders (Lange et al. 2016; Shanks et al.
2018). They include EA implementation support services,
facilitating and enforcing the conformity of development
initiatives with the EA, and EA planning support services,
supporting management decision-making on the EA target
state (Lange et al. 2016; Shanks et al. 2018; van der Raadt
and van Vliet 2008).
EA products are primarily used for guiding the EA’s
realization in individual development initiatives (Kaisler
et al. 2005; Tamm et al. 2011). EA plans are thus realized
when systems and processes are implemented. In addition,
EA products support decision-making and communication,
strategic management, transformation governance, and IT
and business planning activities (Aier et al. 2011; Boyd and
Geiger 2010; Harmsen et al. 2009; Simon et al. 2013;
Winter et al. 2007).
Information systems are one type of element described
in the EA products. Information systems can be defined as
an organized collection of IT, data, information, processes,
and people (Hirschheim et al. 1995). Therefore, informa-
tion systems consist of similar elements that are described
in EA products. EA can also be considered as a second
order IS, supporting the change processes of an
123
586 E. Niemi, S. Pekkola: The Benefits of Enterprise Architecture in Organizational Transformation, Bus Inf Syst Eng 62(6):585–597 (2020)

organization, instead of supporting its business processes
as traditional IS (Proper 2014). These commonalities
between the definitions of EA and IS have led some
researchers to use models from the IS domain to under-
stand EA (e.g., Lange et al. 2016; Niemi and Pekkola
2009).
2.2 Realizing Benefits from Enterprise Architecture
A multitude of EA benefits have been identified in the
literature. Our review of the literature on EA benefits lists
250 different benefits. The review was based on four aca-
demic meta-reviews on EA benefits (Boucharas et al. 2010;
Foorthuis et al. 2015; Niemi 2006; Tamm et al. 2011).
They were selected because they present comprehensive
literature reviews on EA benefits. For example, Tamm
et al. (2011) present a meta-review of 50 studies on EA
benefits. As we grouped similar benefits together, we
arrived at a list of 40 individual benefits, illustrated in
Table 1.
The benefits range from very abstract ones such as
business–IT alignment and improved decision-making, to
concrete, measurable benefits such as reduced costs. This
variety, and the fact that very few studies actually define
the benefits explicitly, make it difficult to comprehend
where they stem from, or what their mutual interrelation-
ships are.
EA benefit realization research also lacks empirical
evidence. Of a review of 50 studies, only six provided any
empirical data (Tamm et al. 2011). Many studies have
focused on hypothetical or potential benefits of EA, not on
concretized benefits. Studies addressing actual benefits
have appeared, even though they do not always clarify the
benefit realization mechanisms (e.g., Aier et al. 2011;
Kurek et al. 2017; Lagerström et al. 2011). While benefits
can be realized from EA in some circumstances, the benefit
realization mechanisms need further clarification. To
investigate how EA benefits are realized, we conducted a
literature review to identify relevant studies. Although our
main focus was on IS journals (including, but not limited to
BISE, MISQ, JAIS, ISR, EJIS, JIT, JSIS, JMIS and ISJ),
we expanded the sample by including also a search on
Google Scholar. The following search terms were used:
‘Enterprise Architecture’, ‘Architecture’ and ‘Architect’
with terms ‘Benefit’ and ‘Value’. This resulted in 132
relevant articles. From these, 55 articles were about EA
benefit realization. They were then analyzed to see whether
they explicitly describe the benefit-realization process, and
not just list some success or failure factors. Final 18 arti-
cles, listed in Table 2, were included for analysis.
The studies from the literature review show that EA
benefit realization resembles a process,2
i.e. a series of
actions or steps that have to be carried out to realize the
benefits from EA. Consequently, in this article the term
‘‘EA benefit-realization process’’ refers to the chain of
constructs and their interrelationships leading to the
Table 1 Enterprise architecture
benefits synthesized from the
literature
Document knowledge on the enterprise Improve resource quality
Identify resource dependencies Improve return on investments
Identify resource synergies Improve situational awareness
Identify suboptimal resource use Improve solution development
Improve alignment with partners Improve stability
Improve change management Increase agility
Improve compliance Increase economies of scale
Improve customer satisfaction Increase efficiency
Improve decision-making Increase growth
Improve employee satisfaction Increase innovation
Improve enterprise-wide goal attainment Increase market share
Improve information quality Increase resource flexibility
Improve investment management Increase resource reuse
Improve measurement Increase resource standardization
Improve organizational alignment Increase revenue
Improve organizational collaboration Provide a high-level overview
Improve organizational communication Provide directions for improvement
Improve resource alignment Provide standards
Improve resource consolidation Reduce costs
Improve resource integration Reduce complexity
2
The Oxford English Dictionary defines process as ‘‘a series of
actions or steps taken in order to achieve a particular end’’.
123
E. Niemi, S. Pekkola: The Benefits of Enterprise Architecture in Organizational Transformation, Bus Inf Syst Eng 62(6):585–597 (2020) 587

Table 2 Results of the literature review
Article Number of
constructs
Number of
interrelationships
Included constructs (or categories for the
constructs)
Constructs leading to benefits
Aier (2014) 6 5 Group culture, EAP management, EAP
application, EAP guidance, EA consistency,
EA utility
EA consistency
Alaeddini
et al. (2017)
12 16 Communications, competency/value
measurements, governance, partnership, scope
and architecture, skills, EA framework,
organization size, organization type, country,
EA, business-IT alignment
Communications, competency/value
measurements, governance, partnership,
scope and architecture, skills
Bischoff et al.
(2014)
2 1 Use intensity of artifact, realization of benefit Use intensity of artifact
Boh and
Yellin (2007)
13 11 Governance mechanisms for EA standards
management, use and conformance to EA
standards, outcomes (main categories)
Use and conformance to EA standards
Boucharas
et al. (2010)
4 3 Contexts, intervention, mechanisms,
organizational outcomes
Mechanisms
Foorthuis
et al. (2015)
6 10 EA approach, project compliance with EA,
architectural insight, EA-induced capabilities,
organizational performance, project
performance
Architectural insight, EA-induced capabilities
Lagerström
et al. (2011)
2 1 EAM maturity, successful execution of IT EAM maturity
Lange (2012) 6 6 EAM product quality, EAM infrastructure
quality, EAM service delivery quality, EAM
use, EAM cultural aspects, EAM benefits
EAM product quality, EAM use
Lange et al.
(2016)
6 6 EAM product quality, EAM infrastructure
quality, EAM service delivery quality, EAM
organizational anchoring, intention to use
EAM, EAM organisational and project
benefits
EAM product quality, organizational
anchoring, intention to use EAM
Lux et al.
(2010)
9 7 EAM-related human IT resources, EAM-
related intangibles, EAM-related
technological IT resources, other IS resources,
EAM capability, other IS capabilities, (IT
resource exploitation in) business processes,
business process performance, organizational
performance
EAM capability, other IS capabilities, (IT
resource exploitation in) business processes
Schmidt and
Buxmann
(2011)
17 17 IT compatibility, IT connectivity, EA
communication and support, firm
decentralization, documentation, duration of
EAM implementation, EAM approach, IT
efficiency, IT flexibility, EA governance, EA
implementation, mergers and acquisitions, IT
modularity, stakeholder participation, EA
planning, EA programming, firm size
EAM approach
Shanks et al.
(2018)
6 7 EA service capability, EA governance, use of
EA services in IT-driven change, use of EA
services in business-driven change, project
benefits, organizational benefits
Use of EA services in IT-driven change, use
of EA services in business-driven change
Tamm et al.
(2011)
6 8 Enterprise architecture quality, organizational
alignment, information availability, resource
portfolio optimization, resource
complementarity, organizational benefits
Organizational alignment, information
availability, resource portfolio optimization,
resource complementarity
van
Steenbergen
and
Brinkkemper
(2008)
Numerous
constructs
Numerous
interrelationships
Enterprise architecture practice, architectural
results, organizational performance, business
goals, ultimate business goals (main
categories)
Architectural results, organizational
performance
123

realization of benefits from EA. In the literature, EA benefit
realization is often seen as a simple process with only two
steps: specific constructs are interrelated with specific
benefits (e.g., Alaeddini et al. 2017; Bischoff et al. 2014;
Lagerström et al. 2011; Schmidt and Buxmann 2011; van
Steenbergen et al. 2011). Yet the benefits may also be
realized indirectly through one or more intermediary con-
structs (e.g., Foorthuis et al. 2015; Lange et al. 2016;
Shanks et al. 2018; Tamm et al. 2011; Weiss et al. 2013).
This suggests that EA benefits are realized through an
impact chain of more than three constructs, making the EA
benefit realization a complex, multi-phased process. This
resembles the benefit realization in the IS discipline
(DeLone and McLean 2003).
There are different views on how EA benefits emerge.
Some consider EA benefits to realize directly from high-
quality EA products (Lange et al. 2016; Lange 2012;
Schmidt and Buxmann 2011), EA processes (Schmidt and
Buxmann 2011; Tamm et al. 2011) or EA services (Foor-
thuis et al. 2015; Shanks et al. 2018). A few add more
indirect sources such as EA use or implementation (Aier
2014; Lange et al. 2016; van Steenbergen and Brinkkemper
2008). Some also consider the effects of EA implementa-
tion: an improved IT operating platform and the resulting
business process performance improvements produce
benefits (Lux et al. 2010; Tamm et al. 2011). Even though a
multitude of sources for benefits have been suggested, all,
or even most of the sources are very seldom included in the
EA benefit-realization process descriptions.
Social, cultural, and organizational issues, such as the
organizational culture and the organization’s understanding
of EA and its foundations, have also been suggested to
have impacts on the EA process (Aier 2014; Lange 2012).
Utilizing EA is evidently not only a technical issue, but
also a social and political one (Weiss et al. 2013). For
example, top-management commitment to EA, and stake-
holder awareness and understanding of EA are crucial for
bridging EA use and the quality of EA processes, products,
and services (Lange et al. 2016). Acceptance of EA in the
organization has also been considered critical (Lange et al.
2016; Weiss et al. 2013). This indicates that the EA’s
conceptualization and grounding in the organization sup-
ports EA use. Contextual factors, for example, organiza-
tional size and complexity, operating platform quality,
operating model, and the rate of organizational change,
legislation and regulations, demographic factors, and
organization type also impact benefit realization (Lux et al.
2010; Schmidt and Buxmann 2011; Tamm et al. 2011).
3 The Case Study
Our primary data source for this study is a single qualita-
tive case study (Stake 2000; Walsham 1995) of a large
Finnish public-sector organization, described in Table 3. It
has undertaken EA work for over 8 years. The first author
observed the situation for 2 years before the study took
place. It was therefore estimated that the maturity of the
organization’s EA capability was appropriate to provide
adequate research data for the EA benefit-realization
process.
The data was collected through 14 semi-structured
themed interviews. Initially, a set of five interviewees were
handpicked from the organization: the centralized EA
team, all the main business units, and major ongoing pro-
jects. Then snowball sampling was used to identify the rest
of the respondents. In addition, documentation on the EA
and its framework and methodology were studied. Data
Table 2 continued
Article Number of
constructs
Number of
interrelationships
Included constructs (or categories for the
constructs)
Constructs leading to benefits
van der Raadt
et al. (2010)
26 32 Attributes, consequences, values (main
categories)
Consequences
van der Raadt
et al. (2007)
10 23 Governance, processes, communication,
support, scope, resources, architecture
awareness, architecture maturity, Architecture
alignment, architecture effectiveness
Architecture awareness, architecture
maturity, architecture alignment
van
Steenbergen
et al. (2011)
5 5 Project conformance to EA, choices in EA
explicitly linked to business goals, organized
knowledge exchange between architects, EA
in general a good instrument, economic sector
Project conformance to EA, choices in EA
explicitly linked to business goals, organized
knowledge exchange between architects,
economic sector
Weiss et al.
(2013)
10 9 Social legitimacy, efficiency, organizational
grounding, trust, governance, goal alignment,
enforcement, response, EA consistency,
benefits
Enforcement, response, EA consistency
123

collection continued until theoretical saturation was
reached. Table 4 presents the interviewees and their
characteristics.
The interviews were conducted by using examples,
‘‘stories,’’ to derive the arguments for each theme. The
themes (see the Appendix; available online via http://link.
springer.com) followed the application of the DeLone and
McLean IS success model to the EA context (Niemi and
Pekkola 2009). They included the quality, use, user
satisfaction, and benefits of EA products and EA services.
For each theme, first an example was requested, and then
clarifying ‘‘why and how’’ questions were asked. We want
to emphasize that the IS success model was used only to
include and illustrate different themes. This made it pos-
sible for informants to tell their stories, from their own
viewpoints, without influencing them unnecessarily (Wal-
sham 2006).
The audio-recorded and transcribed interviews that las-
ted approximately 57 min were conducted between Octo-
ber 2011 and January 2012. Detailed notes were also taken
to facilitate data analysis, and to identify relevant issues for
subsequent interviews. All the interviews, except one, were
conducted by phone.
An interpretative research approach was used in the data
analysis (Klein and Myers 1999; Walsham 1995). Figure 1
illustrates the analysis process by providing examples of
the coding categories that emerged in each step. The
interview themes were first searched as initial coding cat-
egories. Then, the data and these categories were iteratively
reanalyzed so that all attributes and interrelationships
relating to EA benefit realization were identified. Similar
attributes were then grouped as constructs. Subsequently,
the interrelationships were mapped to attribute pairs and
then generalized as interrelationships between the related
constructs. This analysis resulted in a set of interrelated
constructs describing the EA benefit-realization process.
4 Findings from the Study
The analysis resulted in eight factors and 695 interrela-
tionships having an impact on the EA benefit realization.
Moreover, 51 descriptive attributes related to the constructs
were identified. Table 5 presents the constructs, their
Table 3 Case organization summary
The organization is governed by a centralized group administration and has several fairly independent lines of business (LoBs). A multitude
of development initiatives are constantly underway. In addition to EA, these are governed by typical governance processes such as portfolio
management, project management, procurement, and IT governance. The organization utilizes EA to concretize strategic plans, set
architectural guidelines for development initiatives, and to guide individual projects in conforming to EA
The EA work is carried out by a semi-centralized EA team on several architectural levels: EA, reference architecture, LoB architecture,
project architecture, and implementation architecture. The central EA team is responsible for EA, reference architecture, and LoB
architecture, which are mainly used to set the direction for development at a high level. Project architecture and implementation architecture
are defined in individual projects, and constitute a detailed view of the particular project and its dependencies to the overall EA. The
organization uses an established EA framework and methodology. EA modeling is carried out with a proprietary EA modeling tool. EA
models are extracted from the tool into documents for communication outside the architect community
The organization had defined the EA framework, methodology, roles, and objectives seven years earlier. Architects and owners had been, for
the most part, named for the EA viewpoints. While the architects in the central team were full time, most architects were actually not. As a
consequence, the EA methodology and the role descriptions did not fully realize in practice. Even though the lack of resources was often
highlighted as a major problem, the EA organization structure and methodology were also regarded as overly heavy. There were plans for
streamlining and rationalizing the EA organization and methodology. EA was also considered somewhat separate from the other planning and
governance methods. Especially on the project level, governance methods partly overlapped, as similar information was required from the
projects in different formats, causing an extra burden
Table 4 Interviewees and their characteristics
Interviewee Work role Level EA team
Architect A Technical-functional
architect
LoB Central
Architect B Domain architect EA Central
Specialist C EA framework specialist LoB Central
Specialist D Lifecycle management
specialist
LoB Decentralized
Project manager
E
Project manager Project N.A.
Line manager F Line manager, specialist
in projects
Project Decentralized
CIO G Head of information
systems
LoB Decentralized
Project manager
H
Development
manager I
Development manager EA Central
Architect J Technical architect LoB Central
Program
manager K
Program manager Project N.A.
Project manager
L
Architect M Functional architect LoB Central
Architect N Architect LoB Central
123

definitions, and attributes. The resulting EA benefit-real-
ization process is depicted in Fig. 2.
EA benefit realization is a multi-phased process where
eight constructs are interconnected in a complex manner.
EA benefit realization begins with the EA Process Quality
construct, referring to the day-to-day operations of the EA
function. Its attributes relating to EA methodologies,
frameworks, tools, organization, and stakeholder partici-
pation have an extensive impact on the process. Obviously,
it has a direct impact on the quality of the results of the EA
processes—represented by the EA Product and Service
Quality constructs. It also directly impacts the realization
of several benefits. This signifies the role of having a solid
basis for EA work in the benefit realization, as the pro-
cesses of EA planning, documentation, and governance can
immediately contribute to improved understanding of the
organization and its components.
Additionally, EA Results Use results in a multitude of
EA Benefits. Utilizing EA products and services in use
situations by EA stakeholders, such as architects, projects,
and management, is another way (in addition to EA pro-
cesses) in which EA benefits are realized. The use situa-
tions include, for example, project and solutions planning,
IT and business decision-making, training, and further EA
planning. Most of the attributes of use, including its
motives, involved stakeholders, EA results, and timing of
use have an effect on benefit realization.
EA Results Use is impacted by EA Process and EA
Results Quality. This means that having an appropriate
basis for EA work and high-quality EA products facilitates
their use. EA Process and EA Results Quality are also
mutually intertwined. While high-quality EA products are
required to deliver high-quality service, appropriate EA
services also improve the quality of EA products.
In addition, organizational factors, external to EA
(conceptualized as the EA Social Environment construct),
have a significant mutual relationship with most other
constructs, as those influence and are influenced by EA
Social Environment. This means that high-quality EA
processes, services, and successful EA use further build up
an environment that is favorable for the utilization of the
EA approach. There is also a counter-impact from EA
Benefits to EA Social Environment, as gaining concrete
benefits from EA promotes it further.
The benefits resulting from the EA processes are
numerous. While most benefits result from EA activities,
there are also some benefits that are impacted by others,
forming chains of benefits, where a benefit may trigger
other benefits to be realized. The benefits range from
immediate benefits to EA users or the EA stakeholders
participating in EA planning (e.g., identify dependencies or
provide overview), to indirect benefits, such as improved
understanding (e.g., improve decision-making) that are a
result of the immediate benefits. There are also benefits that
Identify attributes and
interrelationships
Identify initial and additional
coding categories
Identify constructs
Map interrelationships
Examples of Codes
Analysis Step
EA product quality, EA service use,
EA product user satisfaction and benefits, EA
process, EA tools, Organization
Cohesion and uniformity, Activeness, EA
results used, Provide example, Increase
standardization in solutions portfolio, Resource
availability
EA Process Quality, EA Product Quality, EA
Results Use, First-level Benefits
EA Process Quality (EA framework quality)
EA Product Quality (Cohesion)
EA Product Quality (Granularity)
EA Results Use (Motives of use, EA results used)
EA Results Use (Motives of use, EA results used)
First-level Benefits (Provide guiding framework)
Fig. 1 Data analysis process
123

can only be realized over time. For example, an improved
IT platform is implemented in compliance with EA (e.g.,
increase interoperability between solutions). Most of the
benefits are on an individual or project level, while some
are more at the organization level in nature. Finally, while
there are concrete, measurable benefits such as cost sav-
ings, most of the benefits are somewhat abstract and are not
easily measurable. Examples of benefit-realization chains
from the data are included in Table 6.
5 Discussion: Reflection to Literature
Our findings suggest that EA benefits are realized either
directly from certain EA activities, or indirectly, through a
chain of several interconnected constructs and attributes.
This is supported by several studies (Aier 2014; Foorthuis
et al. 2015; Lange 2012; Schmidt and Buxmann 2011).
This means that the processes of EA planning, docu-
mentation, and governance can immediately contribute to
the improved understanding of the organization and its
components, thus providing a basis for more informed
decision-making and development. A prerequisite for this
seems to be a solid basis for EA work, with appropriate EA
tools and frameworks, adequate resourcing, and stake-
holder participation. Although the role of rigid EA pro-
cesses has been identified earlier (Foorthuis et al. 2015;
Schmidt and Buxmann 2011; Tamm et al. 2011), they are
not often seen as a precursor for benefits. Process factors
have also been emphasized elsewhere (Banaeianjahromi
and Smolander 2017; Kotusev 2018; van der Raadt et al.
Table 5 Constructs and their attributes in the enterprise architecture
benefit-realization process
Construct Definition Attributes
EA Process
Quality
Measures of EA
processes,
methodologies,
tools, and
organization
Clear EA scope and purpose
Cohesion with other
governance
EA framework quality
EA modeling conventions
EA modeling tool quality
EA process task timing
Non-architecture source
material quality
Resource availability
Stakeholder participation
Support documentation quality
EA Product
Quality
Measures of EA
products
Availability
Clarity
Cohesion and uniformity
Correctness
Granularity
Usefulness
EA Service
Quality
Measures of EA
services
Activeness
Availability
Competence
Usefulness
EA Results
Use
Consumption of
the output of EA
processes (i.e.,
EA results) by
EA stakeholders
Amount of use
EA results used
Motives of use
Stakeholders
Timing of use
User satisfaction
First-level
Benefits
Effects of EA
that arise directly
from the EA
processes
Allow project to proceed
Identify dependencies
Improve alignment
Improve implemented
solutions
Improve project governance
Improve project management
Improve service management
Increase understanding/new
insight
Provide answers quickly
Provide common vocabulary
Provide example
Provide guiding framework
Provide overview
Provide standards
Reduce duplication
Reduce workload in EA work
Second-level
Benefits
Effects of EA
that arise
(depending on
Improve decision-making
Increase interoperability
between solutions
Table 5 continued
Construct Definition Attributes
the situation)
either directly
from the EA
processes or as a
result of the
First-level
Benefits
Increase standardization in
solution portfolio
Identify requirements and
restrictions
Speed up project initialization
Third-level
Benefits
Effects of EA
that arise as a
result of the
second-level
benefits
Decrease IT costs
EA Social
Environment
Organizational
factors external
to the EA
undertaking that
have an effect on
the EA benefit-
realization
process
Common approval and
understanding of EA
Top-management commitment
Understanding of EA work in
other organizations
123

2007, 2010). Some studies (Foorthuis et al. 2015; Schmidt
and Buxmann 2011; Tamm et al. 2011) share our view that
benefits can arise directly from EA processes.
Most EA benefits seem to be realized from the appro-
priate use of EA products and services. The view that EA
use contributes to benefit realization directly or indirectly is
shared by several authors (Aier 2014; Boh and Yellin 2007;
Foorthuis et al. 2015; Lange et al. 2016; Lange 2012; Lux
et al. 2010; Schmidt and Buxmann 2011; Shanks et al.
2018; Tamm et al. 2011; van Steenbergen and
EA Benefits
EA Product
Quality
EA Service
Quality
EA Process
Quality
EA Social
Environment
First-level
Benefits
Second-level
Benefits
Third-level
Benefits
EA Results Use
Fig. 2 Constructs and interrelationships in the enterprise architecture benefit-realization process
Table 6 Examples of benefit-realization chains
Codes Quotes from the interviews
EA Process Quality (stakeholder participation) ? Second-level
Benefits (Identify requirements and restrictions)
Second-level Benefits (Identify requirements and
restrictions) ? Third-level Benefits (decrease IT costs)
‘‘…there was a large group of people doing the requirements analysis,
we had even the architect at the time taking part and bringing issues he
thought relevant for the program, there were a lot of requirements
related to information security, for example … it is critical that the
planning team is large enough … if [EA] has not been able to influence
a project in the requirements analysis … there the larger problems arise
… it is more expensive, if not impossible, to make changes later.’’
[Architect J]
EA Process Quality (Support documentation quality) ? EA Product
Quality (Availability, Cohesion)
EA Process Quality (Support documentation quality) ? First-level
Benefits (Provide guiding framework)
‘‘Yes, [the guidelines] are for suppliers, they present the architecture
and tell us what the views are that they need to produce … in an ideal
situation, we get the [architectural] descriptions directly from the
supplier and only need to copy them to the [EA modeling tool] … when
we send out a request for a proposal, we add these guidelines as an
attachment to specify what descriptions we require.’’ [Architect N]
EA Product Quality (Granularity) ? EA Results Use (EA results used,
Motives of use, Stakeholders)
EA Results Use (EA results used, Motives of use,
Stakeholders) ? First-level Benefits (Identify dependencies, Provide
guiding framework), Second-level Benefits (Identify requirements
and restrictions)
‘‘[The program architecture description] did not bring a lot more than
restrictions and a number of interfaces, and as a matter of fact, maybe
some taxonomy things as well came from there. But because it was on a
slightly different level than we really went in this program … that is
why it merely gave a kind of framework for our work.’’ [Program
Manager K]
EA Results Use (EA results used) ? First-level Benefits (Provide
common vocabulary)
First-level Benefits (Provide common vocabulary) ? Second-level
Benefits (Increase interoperability between solutions)
‘‘I think it could be a vehicle for coherent and congruent
communication, at its best. And through that, a tool for making sure
that the interface that has been procured [between particular systems]
fits there and works, in the end.’’ [Project Manager E]
123

Brinkkemper 2008). The significance of the use perspective
has also been emphasized by Bischoff (2017). Similarly to
EA processes, EA use can immediately result in improved
understanding, as the information gathered from EA
products facilitates a comprehensive view of the organi-
zation and its components. An obvious benefit is getting a
clear overall view of a specific subject area, its compo-
nents, and interrelationships. For example, during a project,
some selected EA products can be used to improve
understanding of the project’s interrelationships to pro-
cesses, solutions, and to other projects. In our case, for
example, project architects used the EA documentation
from simultaneous neighboring projects and existing sys-
tems as a basis for deciding which interfaces were required
and defining high-level requirements for them. EA use thus
facilitates project and program management, speeds up
project initialization, and may lead to better decisions.
EA results use also has more indirect implications. As
EA is used to guide development activities, it may, over
time, improve the organizational IT platform (Tamm et al.
2011). This leads to further benefits such as increased
interoperability between solutions, reduced redundancy,
and increased standardization in the solution portfolio. In
turn, this can lead to measurable cost savings. Although our
data referred specifically to these IT benefits, we can safely
speculate that similar benefits can be realized regarding
improved business processes and business–IT alignment.
Indirect benefits probably take many years to appear, as
large improvement programs take several years, where the
role of EA, as a form of guidance, can be somewhat limited
at first. The realized benefits can also be different in dif-
ferent organizations and contexts (Aier et al. 2008). Our
results, indicating that achieving certain benefits can in turn
lead to other benefits, is in line with literature (Foorthuis
et al. 2015; Lux et al. 2010; Shanks et al. 2018; van
Steenbergen and Brinkkemper 2008).
Our results highlight the extensive impact of EA social
environment in the benefit-realization process, as it has an
influence on the entire process. The role of cultural issues
and EA’s organizational grounding have also been high-
lighted earlier (Aier 2014; Lange 2012), Other literature
also underlines the significance of EA’s acceptance in the
organization (Kotusev 2017; Weiss 2017).
Similar kind of comprehensive view on the EA benefit-
realization process is not provided elsewhere. For example,
the use of EA results and high-quality EA processes have
not been empirically demonstrated to have a direct influ-
ence on benefits, although both have individually been
implied to have such effect. Also, our case did not show
that EA product or service quality directly leads to benefits,
as in some of the earlier studies (Boh and Yellin 2007;
Foorthuis et al. 2015; Lange 2012; Schmidt and Buxmann
2011). Instead, we argue that it has a more indirect role in
the benefit-realization process. High-quality EA products,
supported by useful EA services, contribute to EA use
which in turn leads to benefit realization.
Other studies have also presented less complex benefit-
realization processes, in terms of constructs and interrela-
tionships. For example, they do not refer to the ‘‘feedback
loop’’, in which successful EA use and realization of
benefits lead to grounding of EA in the organization,
although this effect has been hinted to in some studies
(Kotusev 2017; Schmidt and Buxmann 2011; van der Raadt
et al. 2010).
6 Implications
Based on our findings, EA benefit realization constitutes a
long, intertwined chain of activities. Consequently, there
are various ways in which the organization can benefit
from EA at various points in time. This has impacts for
how the EA practice should be organized and for how the
objectives of EA initiatives should be set. In the following,
we will discuss the implications of our findings.
6.1 Implications for Enterprise Architecture
Management
The findings highlight the importance of EA processes. Not
only can benefits be directly realized from EA operations,
but they also impact all the other parts of the EA benefit-
realization process. Therefore, there should be a solid basis
for EA work with appropriate resources, organization,
tools, methods, and frameworks. Concrete endorsement for
EA work from the top management is also crucial. To
avoid the ‘‘ivory tower syndrome’’ in EA planning, EA
activities should be integrated with the strategic, business,
and IT planning processes of the organization. EA stake-
holders should also be involved in EA creation (Nakakawa
et al. 2010). How this should be done depends on the
organization. There is not a single right way of carrying out
EA work but different approaches should be applied in
different organizational contexts (Aier et al. 2008). It is
also significant to note that EA does not replace existing
methodologies but provides a tool for more informed
planning and decision-making. In any case, communication
and collaboration are crucial for the success of EA
(Banaeianjahromi and Smolander 2017), as with any
enterprise endeavor.
The use of EA products is another key activity in the
benefit-realization process. This is logical, as the guiding
effect of EA on development is established through its
usage. Even though the quality of EA products has been
emphasized before, the products are useless from the
benefits point of view if they are not properly used (Lange
123

et al. 2016). EA use cannot exist in a vacuum, so EA
managers should establish a clearly communicated and
instructed set of EA use situations in co-operation with the
existing development governance methodologies (such as
project management, program steering, and IT investment
management). EA use situations should be planned and
managed comprehensively, including their objectives, key
stakeholders, the EA results used, and the timing of use.
Especially in development initiatives, the timing of when
the EA results are used is critical. The initiative should be
captured within EA support already in its initiation phase.
EA services’ role in benefit realization is often under-
stated or omitted. In our case, the services mainly support
deriving useful information from the EA products. This is
emphasized for those EA users who are not familiar with
architectural thinking, such as business decision-makers.
These stakeholders need support when interpreting and
selecting EA products in particular situations, and what
issues to consider in terms of the EA products. There are
also EA services to guide development initiatives, such as
project architecture reviews. At the same time, these EA
services improve the quality of the EA products as they
guide stakeholders to create architecture that is consistent
with the standards. However, it should be noted that EA
services should not be overly laborious for the stakehold-
ers. Similar documentation should not be required in dif-
ferent formats for the needs of each governance
methodology. EA is there to serve the stakeholders, not the
other way around (see also Kotusev 2017).
6.2 Implications for Measuring Enterprise Architecture
Traditionally, investments have been assessed by their
measurable impacts. According to our findings, this is a
rather short-sighted approach with regard to EA as an
investment. We argue that measurable cost savings can be
expected years from the initiation of EA work, at best.
Thus, investing in EA requires confidence and faith that the
benefits will eventually come; the traditional year-long
budgeting cycle is evidently too short to observe any
measurable benefits from EA. It should also be remem-
bered that most of the EA benefits are at the individual
level and are not easily measurable. Still, over time, they
will build up an environment that facilitates EA activities
and the realization of organization-level benefits.
However, there are some measures that can be used to
track the EA initiative to ensure that it is heading in the
right direction. Process and product quality measures can
be used to ensure that the EA processes result in high-
quality EA products and services (Tamm et al. 2011; Timm
et al. 2017). User satisfaction measures may give an idea as
to whether the EA results are useful to the EA stakeholders.
The IT portfolio can be reviewed, and the complexity
measures, such as the number of interfaces and technolo-
gies, can be tracked. The EA itself can provide tools for
evaluating IT and the business in the form of useful system
and process blueprints. These indirect measures can pro-
vide the necessary success stories at the beginning of and
throughout the EA journey.
7 Limitations
The main limitation of the study arises from its nature. As
the study was carried out as a single case study in a public-
sector organization, the generalizability of its results is
limited. It cannot be claimed that the identified constructs
and interrelationships are similar in other settings. Actu-
ally, some studies even suggest that the way of doing EA
should be different in different kinds of organizational
contexts (Aier et al. 2008). Therefore, also benefit-real-
ization process could be different.
There is also a limitation related to the qualitative
empirical data collected as ‘‘stories’’. Even though the
stories describe what was important for our informants,
important details might still be missing. Therefore, our
model of constructs and interrelationships in the EA ben-
efit-realization process is by no means a complete or per-
fect description of EA benefit realization everywhere. It is
a model that resembles the case. As it is aligned with the
literature, we believe the model can be applied elsewhere,
perhaps appended and amended.
8 Conclusion
In this article, we have studied how EA benefits are real-
ized through an in-depth case study. We have focused on
the strategies, resources, and practices which the EA ben-
efits stem from, and have clarified the nature of the EA
benefit-realization process. The process turned out to be
more complex and extensive than assumed and previously
described. It constitutes a long, intertwined chain of
activities. Our results indicate that EA benefits stem from
solid EA processes, as well as from the appropriate use of
EA products and services. Social and cultural factors also
play an important role in the process. The results also shed
light to the time dimension of EA benefit realization.
Organizations can benefit from EA from day one, when
comprehensive understanding starts to form, until the later
years, when measurable outcomes—cost savings and so
on—materialize. This is similar to the IS domain, where a
large number of constructs, including system quality,
information quality, service quality, IS use, and user sat-
isfaction, have been observed to influence benefits—also in
the long run (Petter et al. 2008).
123

Our findings help researchers and practitioners to
understand how EA benefits are realized. This insight can
be used to improve organizational EA practices and pro-
cedures, and to study them. The results can be used as a
basis for developing both EA products and their use, and
also for improving EA governance structures, methods, and
practices. While it is important to invest in the quality of
EA processes, appropriate use of EA results is perhaps
even more important. The comprehensive use of EA results
by the EA stakeholders, such as projects, management, and
architects, is emphasized. The usage also requires some
support services to be provided for the stakeholders. This is
the only means to ensure that the main function of EA as a
guide for organizational development is realized.
Although there does not appear to be a simple way to
build up a cultural grounding favorable for EA utilization,
the findings suggest that high-quality EA processes and
results directly contribute to this (Lange et al. 2016). Yet,
this is a chicken and egg problem: to gain high-quality EA
processes and results, a favorable culture is needed. Yet an
EA-favorable culture necessitates high-quality processes
and results. This issue is emphasized with novel, organi-
zationally unknown concepts, such as EA.
Finally, even though we have focused on EA as an
organizational function, it should not be forgotten that EA
is not a separate island in the organization. EA is deeply
intertwined with other planning, management, and gover-
nance approaches and practices. Therefore, it is not suffi-
cient to merely improve aspects of EA such as its quality or
even its utilization. Dialogue between EA and the organi-
zation at large should be initiated to integrate EA in par-
allel with other planning and management approaches,
minimizing the overlap and extra effort required. Seamless
integration and alignment are required to maximize the
benefits from EA.
Open Access This article is distributed under the terms of the
Creative Commons Attribution 4.0 International License (http://crea
tivecommons.org/licenses/by/4.0/), which permits unrestricted use,
distribution, and reproduction in any medium, provided you give
appropriate credit to the original author(s) and the source, provide a
link to the Creative Commons license, and indicate if changes were
made.
References
Aier S (2014) The role of organizational culture for grounding,
management, guidance and effectiveness of enterprise architec-
ture principles. Inf Syst E-Bus Manag 12(1):43–70
Aier S, Riege C, Winter R (2008) Classification of enterprise
architecture scenarios—an exploratory analysis. Enterp Model
Inf Syst Arch 3(1):14–23
Aier S, Gleichauf B, Winter R (2011) Understanding enterprise
architecture management design—an empirical analysis. In:
Bernstein A, Schwabe G (eds) Proceedings of the 10th interna-
tional conference on Wirtschaftsinformatik. Lulu, Raleigh,
pp 645–654
Alaeddini M, Asgari H, Gharibi A, Rad MR (2017) Leveraging
business-IT alignment through enterprise architecture—an
empirical study to estimate the extents. Inf Technol Manag
18(1):55–82
Banaeianjahromi N, Smolander K (2017) Lack of communication and
collaboration in enterprise architecture development. Inf Syst
Front 1:1–32. https://doi.org/10.1007/s10796-017-9779-6
Bischoff S (2017) Chapter 9 The need for a use perspective on
architectural coordination. In: Proper HA et al (eds) Architec-
tural coordination of enterprise transformation. Springer, Cham,
pp 87–98
Bischoff S, Aier S, Winter R (2014) Use IT or lose IT? The role of
pressure for use and utility of enterprise architecture artifacts. In:
Aveiro D et al. (eds) Proceedings of the 16th IEEE conference on
business informatics. IEEE Computer Society, Los Alamitos,
pp 133–140
Bloch M, Blumberg S, Laartz J (2012) Delivering large-scale IT
projects on time, on budget, and on value. http://www.mckinsey.
com/business-functions/business-technology/our-insights/deliver
ing-large-scale-it-projects-on-time-on-budget-and-on-value.
Accessed 17 Feb 2018
Boh WF, Yellin D (2007) Using enterprise architecture standards in
managing information technology. J Manag Inf Syst
23(3):163–207
Boucharas V, Steenbergen M, Jansen S, Brinkkemper S (2010) The
contribution of enterprise architecture to the achievement of
organizational goals: a review of the evidence. In: Proper E et al.
(eds) Proceedings of the 5th international workshop on trends in
enterprise architecture research. Springer, Heidelberg, pp 1–15
Boyd R, Geiger S (2010) Enterprise architecture and information
technology acquisition management. J Enterp Arch 6(4):43–47
Dang DD, Pekkola S (2017) Systematic literature review on
enterprise architecture in the public sector. Electron J E-Gov
15(2):132–154
DeLone W, McLean E (2003) The DeLone and McLean model of
information systems success: a ten-year update. J Manag Inf Syst
19(4):9–30
Foorthuis R, van Steenbergen M, Mushkudiani N, Bruls W,
Brinkkemper S, Bos R (2010) On course, but not there yet:
enterprise architecture conformance and benefits in systems
development. In: Sabherwal R, Sumner M (eds) Proceedings of
the 2010 international conference on information systems. AIS,
Atlanta
Foorthuis R, van Steenbergen M, Brinkkemper S, Bruls W (2015) A
theory building study of enterprise architecture practices and
benefits. Inf Syst Front 18(3):541–564
Harmsen F, Proper HAE, Kok N (2009) Informed governance of
enterprise transformations. In: Proper E et al. (eds) Advances in
enterprise engineering II. PRET 2009. Lecture Notes in business
information processing, vol 28. Springer, Heidelberg,
pp 155–180
Hazen BT, Bradley RV, Bell JE, In J, Byrd TA (2017) Enterprise
architecture: a competence-based approach to achieving agility
and firm performance. Int J Prod Econ 193:566–577
Hirschheim R, Klein HK, Lyytinen K (1995) Information systems
development and data modeling: conceptual and philosophical
foundations. Cambridge University Press, Cambridge
Hjort-Madsen K, Pries-Heje J (2009) Enterprise architecture in
government: fad or future? In: Sprague RH (ed) Proceedings of
the 42nd Hawaii international conference on system sciences.
IEEE Computer Society, Los Alamitos
Kaisler SH, Armour F, Valivullah M (2005) Enterprise architecting:
critical problems. In: Sprague RH (ed) Proceedings of the 38th
123

Hawaii international conference on system sciences. IEEE
Computer Society, Los Alamitos
Klein HK, Myers MD (1999) A set of principles for conducting and
evaluating interpretive field studies in information systems. MIS
Q 23(1):67–93
Kotusev S (2017) Conceptual model of enterprise architecture
management. Int J Coop Inf Syst 26(3):1–36. https://doi.org/
10.1142/S0218843017300017
Kotusev S (2018) TOGAF-based enterprise architecture practice: an
exploratory case study. Commun Assoc Inf Syst 43(1):321–359
Kurek E, Johnson J, Mulder H (2017) Measuring the value of
enterprise architecture on IT projects with CHAOS research.
Syst Cybern Inform 15(7):13–18
Lagerström R, Sommestad T, Buschle M, Ekstedt M (2011)
Enterprise architecture management’s impact on information
technology success. In: Sprague RH Jr (ed) Proceedings of the
44th Hawaii international conference on system sciences. IEEE
Computer Society, Los Alamitos
Lange M (2012) Evaluating the realization of benefits from enterprise
architecture management: construction and validation of a
theoretical model. Doctoral dissertation, Humboldt-Universität
zu Berlin, Berlin. ISBN: 978-3-8439-0558-9
Lange M, Mendling J, Recker J (2012) Realizing benefits from
enterprise architecture: a measurement model. In: Pries-Heje J,
et al. (eds) Proceedings of the 20th European conference on
information systems. Association for Information Systems,
Atlanta
Lange M, Mendling J, Recker J (2016) An empirical analysis of the
factors and measures of enterprise architecture management
success. Eur J Inf Syst 25(5):411–431
Lux J, Riempp G, Urbach N (2010) Understanding the performance
impact of enterprise architecture management. In: Santana M,
et al (eds) Proceedings of the 16th Americas conference on
information systems. Association for Information Systems,
Atlanta
Nakakawa A, van Bommel P, Proper HA (2010) Challenges of
involving stakeholders when creating enterprise architecture. In:
van Dongen B, Reijers H (eds) Proceedings of the 5th SIKS/
BENAIS conference on enterprise information systems 2010.
Eindhoven University of Technology, Eindhoven, pp 43–55
Niemi E (2006) Enterprise architecture benefits: perceptions from
literature and practice. In: Soliman KS (ed) Proceedings of the
7th international business information management association
(IBIMA) conference on internet and information systems in the
digital age. IBIMA Publishing, Norristown
Niemi E, Pekkola S (2009) Adapting the DeLone and McLean model
for the enterprise architecture benefit realization process. In:
Sprague RH Jr (ed) Proceedings of the 42nd Hawaii international
conference on system sciences. IEEE Computer Society, Los
Alamitos
Nikpay F, Ahmad RB, Rouhani BD, Mahrin MN, Shamshirband S
(2017) An effective enterprise architecture implementation
methodology. Inf Syst E-Bus Manag 15(4):927–962
Nowakowski E, Farwick M, Trojer T, Häusler M, Kessler J, Breu R
(2017) Enterprise architecture planning: analyses of require-
ments from practice and research. In: Sprague RH Jr (ed)
Proceedings of the 50th Hawaii international conference on
system sciences. IEEE Computer Society, Los Alamitos,
pp 4847–4856
Petter S, DeLone W, McLean E (2008) Measuring information
systems success: models, dimensions, measures, and interrela-
tionships. Eur J Inf Syst 17(3):236–263
Potts C (2010) Using structural performance ratios to guide invest-
ments in enterprise architecture. J Enterp Archit 6(4):14–18
Proper HA (2014) Enterprise architecture: informed steering of
enterprises in motion. In: Hammoudi S, et al. (eds) Enterprise
information systems. Lecture Notes in business information
processing, vol 190. Springer, Cham, pp 16–34
Proper HA, Winter R, Aier S, de Kinderen S (2017) Architectural
coordination of enterprise transformation. Springer, Cham
Rodrigues L, Amaral L (2010) Issues in enterprise architecture value.
J Enterp Arch 6(4):27–32
Schmidt C, Buxmann P (2011) Outcomes and success factors of
enterprise IT architecture management: empirical insight from
the international financial services industry. Eur J Inf Syst
20(2):168–185
Shanks G, Gloet M, Someh IA, Frampton K, Tamm T (2018)
Achieving benefits with enterprise architecture. J Strateg Inf Syst
27(2):139–156
Sidorova A, Kappelman L (2011) Better business-IT alignment
through enterprise architecture: an actor-network theory per-
spective. J Enterp Arch 7(1):39–47
Simon D, Fischbach K, Schoder D (2013) Enterprise architecture
management and its role in corporate strategic management. Inf
Syst E-Bus Manag 12(1):5–42
StakeRE(2000)Casestudies.In:DenzinNK,LincolnYS(eds)Handbook
of qualitative research. Sage, Thousand Oaks, pp 435–454
Tamm T, Seddon PB, Shanks G, Reynolds P (2011) How does
enterprise architecture add value to organisations? Commun
Assoc Inf Syst 28(1):141–168
Timm F, Hacks S, Thiede F, Hintzpeter D (2017) Towards a quality
framework for enterprise architecture models. In: Lichter H, et al
(eds) Proceedings of the 5th international workshop on quanti-
tative approaches to software quality. CEUR-WS.org, Aachen,
pp 14–21
van der Raadt B, van Vliet H (2008) Designing the enterprise
architecture function. In: Becker S, et al. (eds) Proceedings of the
4th international conference on quality of software architectures.
Springer, Heidelberg, pp 103–118
van der Raadt B, Slot R, van Vliet H (2007) Experience report: assessing
a global financial services company on its enterprise architecture
effectiveness using NAOMI. In: Sprague RH Jr (ed) Proceedings of
the 40th Hawaii international conference on system sciences. IEEE
Computer Society, Los Alamitos, pp 218–227
van der Raadt B, Bonnet M, Schouten S, van Vliet H (2010) The
relation between EA effectiveness and stakeholder satisfaction.
J Syst Softw 83(10):1954–1969
van Steenbergen M, Brinkkemper S (2008) Modeling the contribution
of enterprise architecture practice to the achievement of business
goals. In: Papadopoulos GA, et al (eds) Proceedings of the 17th
international conference on information systems development.
Springer, New York, pp 609–618
van Steenbergen M, Foorthuis R, Mushkudiani N, Bruls W,
Brinkkemper S, Bos R (2011) Achieving enterprise architecture
benefits: what makes the difference? In: O’Conner L (ed)
Proceedings of the 15th IEEE international enterprise distributed
object computing conference workshops. IEEE Computer Soci-
ety, Los Alamitos, pp 350–359
Walsham G (1995) Interpretive case studies in IS research: nature and
method. Eur J Inf Syst 4(2):74–81
Walsham G (2006) Doing interpretive research. Eur J Inf Syst
15(3):320–330
Weiss S (2017) Chapter 12 institutionalization of ACET: needs and
foundations. In: Proper HA et al (eds) Architectural coordination
of enterprise transformation. Springer, Cham, pp 87–98
Weiss S, Aier S, Winter R (2013) Institutionalization and the
effectiveness of enterprise architecture management. In: Pro-
ceedings of the international conference on information systems.
Association for Information Systems, Atlanta, pp 1–19
Winter R, Bucher T, Fischer R, Kurpjuweit S (2007) Analysis and
application scenarios for enterprise architecture: an exploratory
study. J Enterp Arch 3(3):33–43
123

The benefitsofenterprisearchitecture.2020

More Related Content

What's hot (20)

Similar to The benefitsofenterprisearchitecture.2020 (20)

Recently uploaded (20)

The benefitsofenterprisearchitecture.2020