Skip to main content


Weitere Artikel dieser Ausgabe durch Wischen aufrufen

19.06.2019 | Research Paper | Ausgabe 6/2020 Open Access

Business & Information Systems Engineering 6/2020

The Benefits of Enterprise Architecture in Organizational Transformation

Business & Information Systems Engineering > Ausgabe 6/2020
Eetu Niemi, Samuli Pekkola
Wichtige Hinweise

Electronic supplementary material

The online version of this article (https://​doi.​org/​10.​1007/​s12599-019-00605-3) contains supplementary material, which is available to authorized users.
Accepted after one revision by Jelena Zdravkovic.

1 The Need for Enterprise Architecture

In today’s volatile business environment, organizations constantly adjust their activities to the changing circumstances—business transformation 1 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 complexity 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 databases, and of their mutual dependencies. This makes it difficult to execute the transformation initiatives in the most beneficial way. As a result, business and IT improvement often takes place in silos, without comprehensively considering 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 program management are, on their own, unable to change this course, as they lack the holistic picture and the “glue” that holds the transformation together.
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 Kappelman 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 Buxmann 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. Particularly, 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 comprehensive 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 organization’s transformation journey, facilitating the compliance 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 communication 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, information 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 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 understand 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 academic 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.
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
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 interrelationships 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; Lagerströ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 articles, listed in Table  2, were included for analysis.
Table 2
Results of the literature review
Number of constructs
Number of interrelationships
Included constructs (or categories for the constructs)
Constructs leading to benefits
Aier ( 2014)
Group culture, EAP management, EAP application, EAP guidance, EA consistency, EA utility
EA consistency
Alaeddini et al. ( 2017)
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)
Use intensity of artifact, realization of benefit
Use intensity of artifact
Boh and Yellin ( 2007)
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)
Contexts, intervention, mechanisms, organizational outcomes
Foorthuis et al. ( 2015)
EA approach, project compliance with EA, architectural insight, EA-induced capabilities, organizational performance, project performance
Architectural insight, EA-induced capabilities
Lagerström et al. ( 2011)
EAM maturity, successful execution of IT
EAM maturity
Lange ( 2012)
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)
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)
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)
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)
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)
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
van der Raadt et al. ( 2010)
Attributes, consequences, values (main categories)
van der Raadt et al. ( 2007)
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)
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)
Social legitimacy, efficiency, organizational grounding, trust, governance, goal alignment, enforcement, response, EA consistency, benefits
Enforcement, response, EA consistency
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 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; Lagerströ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 constructs (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 (Foorthuis 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 implementation: 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 stakeholder 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 supports EA use. Contextual factors, for example, organizational 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 qualitative 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.
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
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 projects. 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 collection continued until theoretical saturation was reached. Table  4 presents the interviewees and their characteristics.
Table 4
Interviewees and their characteristics
Work role
EA team
Architect A
Technical-functional architect
Architect B
Domain architect
Specialist C
EA framework specialist
Specialist D
Lifecycle management specialist
Project manager E
Project manager
Line manager F
Line manager, specialist in projects
Head of information systems
Project manager H
Project manager
Development manager I
Development manager
Architect J
Technical architect
Program manager K
Program manager
Project manager L
Project manager
Architect M
Functional architect
Architect N
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 possible for informants to tell their stories, from their own viewpoints, without influencing them unnecessarily (Walsham 2006).
The audio-recorded and transcribed interviews that lasted approximately 57 min were conducted between October 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 categories. 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 interrelationships having an impact on the EA benefit realization. Moreover, 51 descriptive attributes related to the constructs were identified. Table  5 presents the constructs, their definitions, and attributes. The resulting EA benefit-realization process is depicted in Fig.  2.
Table 5
Constructs and their attributes in the enterprise architecture benefit-realization process
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
Cohesion and uniformity
EA Service Quality
Measures of EA services
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
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 the situation) either directly from the EA processes or as a result of the First-level Benefits
Improve decision-making
Increase interoperability between solutions
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
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 participation 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 processes 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 processes) in which EA benefits are realized. The use situations 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 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 savings, 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.
Table 6
Examples of benefit-realization chains
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]

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, documentation, 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 stakeholder participation. Although the role of rigid EA processes 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. 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 appropriate 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 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 organization and its components. An obvious benefit is getting a clear overall view of a specific subject area, its components, and interrelationships. For example, during a project, some selected EA products can be used to improve understanding of the project’s interrelationships to processes, solutions, and to other projects. In our case, for example, project architects used the EA documentation from simultaneous neighboring projects and existing systems 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 different 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 highlighted 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 influence 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 interrelationships. 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 stakeholders 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 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 understated 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 stakeholders. Similar documentation should not be required in different 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 remembered 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 technologies, 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 provide 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. Actually, 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-realization 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 benefit-realization process is by no means a complete or perfect 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 realized through an in-depth case study. We have focused on the strategies, resources, and practices which the EA benefits 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 satisfaction, have been observed to influence benefits—also in the long run (Petter et al. 2008).
Our findings help researchers and practitioners to understand how EA benefits are realized. This insight can be used to improve organizational EA practices and procedures, 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, organizationally 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 governance approaches and practices. Therefore, it is not sufficient to merely improve aspects of EA such as its quality or even its utilization. Dialogue between EA and the organization at large should be initiated to integrate EA in parallel 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 AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License ( http://​creativecommons.​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.

Electronic supplementary material

Below is the link to the electronic supplementary material.
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).
The Oxford English Dictionary defines process as “a series of actions or steps taken in order to achieve a particular end”.

Unsere Produktempfehlungen


WI – WIRTSCHAFTSINFORMATIK – ist das Kommunikations-, Präsentations- und Diskussionsforum für alle Wirtschaftsinformatiker im deutschsprachigen Raum. Über 30 Herausgeber garantieren das hohe redaktionelle Niveau und den praktischen Nutzen für den Leser.

Business & Information Systems Engineering

BISE (Business & Information Systems Engineering) is an international scholarly and double-blind peer-reviewed journal that publishes scientific research on the effective and efficient design and utilization of information systems by individuals, groups, enterprises, and society for the improvement of social welfare.

Wirtschaftsinformatik & Management

Texte auf dem Stand der wissenschaftlichen Forschung, für Praktiker verständlich aufbereitet. Diese Idee ist die Basis von „Wirtschaftsinformatik & Management“ kurz WuM. So soll der Wissenstransfer von Universität zu Unternehmen gefördert werden.

Über diesen Artikel

Weitere Artikel der Ausgabe 6/2020

Business & Information Systems Engineering 6/2020 Zur Ausgabe

Premium Partner