1 The Need for Enterprise Architecture

In today’s volatile business environment, organizations constantly adjust their activities to the changing circumstances—business transformationFootnote 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
Full size table

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
Full size table

The studies from the literature review show that EA benefit realization resembles a process,Footnote 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
Full size table

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
Full size table

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.

Fig. 1
figure 1

Data analysis process

Full size image

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
Full size table
Fig. 2
figure 2

Constructs and interrelationships in the enterprise architecture benefit-realization process

Full size image

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
Full size table

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.