# Exploring Causal Factors Influencing Enterprise Architecture Failure

Yiwei Gong, Marijn Janssen

<figure><img src="image_1.png" /></figure>

► To cite this version:

Yiwei Gong, Marijn Janssen. Exploring Causal Factors Influencing Enterprise Architecture Failure. International Working Conference on Transfer and Diffusion of IT (TDIT), Dec 2020, Tiruchirappalli, India. pp.341-352, 10.1007/978-3-030-64849-7_31. hal-03701792

HAL Id: hal-03701792

https://inria.hal.science/hal-03701792

Submitted on 22 Jun 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>
# Exploring Causal Factors Influencing Enterprise Architecture Failure

Yiwei Gong<fnref n="1" />* and Marijn Janssen<fnref n="2" />

**Abstract.** Organizations have adopted enterprise Architecture (EA) for managing their IT-landscape and ensuring coherence among projects and activities. There is much work about approaches, methods, and tools for EA based on the assumption that their use will create business value. However, the failure of many EA efforts results in the need to investigate the factors influencing EA failure in practice. In this paper, we used a literature review to identify ten EA failure factors. Then we employed the grey-DEMATEL method to explore and analyze the influence of the ten EA failure factors based on the input of five EA experts. The result shows that failure factors are not in isolation, and they can be divided into either causal or effect factors. The factors do not have equal importance but differ in the levels of influence. For the causal factors, the ranking from most to least important is the inability to handle complexity, lack of proven EA methodology, lack of EA knowledge, lack of communication, and lack of tools. For the effect factors, the factors are a lack of support, too high effort, lack of motivation, parallel processes, and unused artifacts. We recommend practitioners to pay more attention to the five causal factors in their EA efforts. Further research is needed to generalize the findings, to understand the dependencies among factors, and to take into account situational dependency of EA failure.

**Keywords:** Enterprise Architecture, IT architecture, IT failure, value, multi-criteria decision-making, grey-DEMATEL.

## 1 Introduction

Enterprise Architecture (EA) has been heralded for the many benefits that it can bring to organizations. EA can bring agility [1] and interoperability [2], facilitate decision-making in IT investments [3], reduce IT costs [4], and so on. Today, EA is widely used in industry and government to manage the IT-landscape, as a continuously changing process for organizations [5].

Although many benefits are accounted for by EA, these benefits are difficult to measure in practice [4], and many business operations managers do not see the value returned

<footnote n="1">¹ School of Information Management, Wuhan University,
Wuhan 430072, China
yiweigong@whu.edu.cn</footnote>

<footnote n="2">² Faculty of Technology, Policy and Management, Delft University of Technology,
Jaffalaan 5, 2628 BX Delft, The Netherlands
M.F.W.H.A.Janssen@tudelft.nl</footnote>
from their EA investments [6]. In the literature, there are limited empirical studies that address the benefits of EA by providing reliable evidence. In contrast, many claims of EA benefits are given without any support, resulting in ill-understanding of and many myths about EA [7, 8]. In the end, EA as a means, becomes a goal in itself.

Consultancy reports have indicated that two-third of EA initiatives failed in the past [9], and about 40% of EA programs were shut down within three years [10]. More recently, many organizations are either unable to implement their EA plans or only able to implement a part of their plans [11]. EA has shown to be countered with effectiveness and has even been blamed for failure. In this sense, avoiding failure should be first considered instead of achieving success, especially for the practitioners and organizations with limited EA experience.

Many studies have addressed the challenges and issues in EA management, but their practical help is limited. For example, many studies only proposed taxonomies without going further to guide EA practice [12]. Much research is about how to achieve the benefits of EA, but scant attention is given to EA failure [13]. Despite its importance, EA failure is undertheorized. This study aims to explore and better understand the factors failing EA initiatives. The study is explorative in nature, as this is one of the first studies in this area. For this, we employed the grey-DEMATEL method to analyze inputs from five EA experts. The findings provide practitioners and researchers with the identified factors determining the failure or success of EA implementation, provide insights into improving EA practice, and result in several further research directions.

The paper is structured as follows. In Section 2, we briefly discuss the background of EA failure. Thereafter, the research method is explained in Section 3. In Section 4 we present research findings of failure factors in practice and discuss the implications and recommendations for practitioners. Section 5 contains the conclusion and future research agenda.

## 2 Background

For investigating the failure of EA efforts, we will use normative literature about IT-project failure as the categorical base. The underlying premise is that EA implementation can be considered as a special kind of IT-project, and the categorization of IT-project failures can be used for mapping the failures of EA implementation. IT-project failure factors can be categorized into people, process, product, and technology [14]. Nelson [15] list of classical project management mistakes contains factors in each category influencing IT-projects. Recent empirical research in EA also indicates that the scope of EA covers these aspects [16]. From Nelson's list, complexity, uncertainty, scope creep, opposing stakeholder requirements, lack of top-management support, and resistance are frequently mentioned in the literature as factors that contribute to IT-project failure [15, 17-20].

In contrast to IT-projects, EA initiatives focus on the enterprise as a whole and should ensure coherency among projects, ensuring a flexible and adaptive IT-landscape, the alignment between IT and business, and so on. While IT-project failures are general to various occasions of IT-implementations, EA failures are specific to an
architect's effort, and concern often many projects. EA has a wider scope and objectives than IT-projects. Hence, it is not surprising that EA failure factors can be different from those influencing IT-project failures. In the literature, there are only a few publications about the failure of EA. Table 1 summarizes the factors of EA failures from literature based on Nelson's categorization of classical IT-project failure factors.

<table><caption>**Table 1.** EA failure factors from literature</caption><thead><tr><td>Label</td><td>EA failure factor</td><td>Source</td><td>Category</td></tr></thead><tbody><tr><td>F1</td><td>Lack of communication and collaboration leads to an EA project failure.</td><td>[12, 21]</td><td rowspan="4">People</td></tr><tr><td>F2</td><td>The EA development project does not have enough support from the management.</td><td>[12, 22]</td></tr><tr><td>F3</td><td>Lack of motivation among personnel hinders EA development projects.</td><td>[12]</td></tr><tr><td>F4</td><td>High-level managers do not understand the benefits of EA.</td><td>[12]</td></tr><tr><td>F5</td><td>EA initiatives set up processes for managing the EA life cycle parallel to the established IT processes, resulting in coordination problems.</td><td>[22]</td><td rowspan="2">Process</td></tr><tr><td>F6</td><td>EA approach is highly complex, preventing it from achieving its objectives.</td><td>[23]</td></tr><tr><td>F7</td><td>Requiring too high effort regarding the initial EA documentation hampers the willingness to further maintain the EA artifacts.</td><td>[22]</td><td rowspan="2">Product</td></tr><tr><td>F8</td><td>Existing EA artifacts remain unused in daily work and decision-making due to the poor quality.</td><td>[22]</td></tr><tr><td>F9</td><td>Lack of accurate and smart modeling tools makes the EA development inefficient.</td><td>[24]</td><td rowspan="2">Technology</td></tr><tr><td>F10</td><td>Lack of clear methodologies for EA implementation projects makes the EA development inefficient.</td><td>[24, 25]</td></tr></tbody></table>

According to Banaeianjahromi and Smolander [12], lack of communication and collaboration refers to a type of the cause influencing the failure of EA efforts. Specifically, it refers to the lack of knowledge and support inside organizations or issues imposed by external parties, such as supply chain partners or government oversight organizations. In practice, enterprise architects are required to liaise with business and technology stakeholders. If the architects are not able to bridge the gap between themselves and their stakeholders, it will be hard to obtain support for and commitment to the implementation of EA [21]. At the root, the organizational culture turned out to be an issue that influences communication and collaboration during EA implementation.

EA is often regarded as a separate and parallel initiative, although it needs to be embedded in the established management processes. This often results in coordination
problems requiring additional adjustments effort, which in turn decreased the EA initi-
atives' acceptance [22]. For example, a lack of coordination between the EA initiative
and a parallel ITIL initiative created contradictory perceptions and redundant documen-
tation.

EA products are the outcome artifacts of EA development, which can refer to EA
models, policies, standards, and principles. EA products are intended to be used to en-
able organization's events, processes, and activities. But when they become complex,
they constraint the same activities that it was meant to support and enable [23]. Com-
plete EA products are not feasible due to the many stakeholders, the high organizational
complexity, the continuous change, and the large scope. Even worse, organizations of-
ten do not update EA documents continuously. EA repositories gradually become out-
dated and are perceived as being of low quality. The poor quality of EA artifacts makes
it remaining unused in daily work and decision-making [22].

Factors in the category of technology, such as the lack of accurate and smart model-
ing tools and lack of clear methodologies for EA implementation, are often considered
as risks rather than the reasons of failures [24]. According to Hope, Chew and Sharma
[11], these factors were found reflecting the technical sophistication of EA tools rather
than that they determine project success. In their case studies, they found EA failures
were more likely caused by communication and commitment problems. In contrast,
Nam, Oh, Kim, Goo and Khan [25] argued that EA methodology applied to a single
organization tends to fail when EA is applied at the national level by the central gov-
ernment to aggregate diverse agencies and organizations.

There are limited studies in literature focusing on the failures of EA implementation. Often, various factors influencing EA implementation are discussed as challenges [e.g. 22] or risks [e.g. 24]. Some factors are even arguable on their validity [11]. Furthermore, existing studies are either ignoring or not able to identify the interrelationships between factors, and consequently, they do not reveal the importance of different factors. This motivates our study on clarifying these ten factors of EA failures and their interrelationships. Such clarification and discussion should help enterprise architects to ensure the survival of their EA initiatives by understanding and tackling the root cause of failure.

## 3 Research Method

Our study is explorative in nature, and our aim is to better understand the interrelation-
ship between EA failure factors. To analysis the correlations between the ten factors
that are derived from EA literature, we employed the grey-DEMATEL method. Among
the many multi-criteria decision-making methodologies, the Decision-making Trial and
Evaluation Laboratory (DEMATEL) is best suited for analyzing the interrelationships
and interdependencies when having a small sample size [26, 27]. The grey-DEMATEL
method combines the Grey Set Theory and DEMATEL method to improve the analysis
by resisting human biases, incomplete information, and uncertainty [28]. Especially,
the grey-DEMATEL method includes a sensitivity analysis to help researchers in determining where their calculation results are significantly impacted by the weights assigned to different inputs.

We conducted the grey-DEMATEL method by the following steps in the three stages: 1) data collection, 2) the grey-DEMATEL analysis, and 3) sensitivity analysis.

## 3.1 Data Collection

The five experts from the Netherlands with rich knowledge and experience in a diversity of EA initiatives were selected and invited to fill in the questionnaire. Table 2 provides an overview of their background. We first introduced our study and explained the factors, as listed in Table 1, to the experts. After that, we asked them to complete a direct-relation matrix by indicating their opinions about the degree of influence between factors, using a five-level measurement from “no influence” to “very high influence”. Their personal views relating to these factors were also captured after they filled in the matrix.

<table><caption>**Table 2.** background and experience of EA experts</caption><thead><tr><td></td><td>Industry</td><td>Years of experience</td></tr></thead><tbody><tr><td>Expert1</td><td>Consultancy</td><td>9</td></tr><tr><td>Expert2</td><td>Consultancy</td><td>21</td></tr><tr><td>Expert3</td><td>Government</td><td>15</td></tr><tr><td>Expert4</td><td>Academia</td><td>12</td></tr><tr><td>Expert5</td><td>Academia</td><td>5</td></tr></tbody></table>

## 3.2 Grey-DEMATEL Analysis

The grey-DEMATEL analysis in our study was conducted according to the following six basic steps [26, 28]:

Step 1: Construct the initial EA failure factors interaction matrix, based on the Grey Set Theory and using the five-level measurement. Grey Linguistic Scale from “No influence” to “Very high influence” as shown in Table 3.

<table><caption>**Table 3.** Linguistic scale for assigning greyscale and crisp values</caption><thead><tr><td>Linguistic Assessment</td><td>Crisp Values</td><td>Grey Scale</td></tr></thead><tbody><tr><td>No influence</td><td>0</td><td>[0,0]</td></tr><tr><td>Very low influence</td><td>1</td><td>[0,1]</td></tr><tr><td>Low influence</td><td>2</td><td>[1,2]</td></tr><tr><td>High influence</td><td>3</td><td>[2,3]</td></tr><tr><td>Very high influence</td><td>4</td><td>[3,4]</td></tr></tbody></table>

Step 2: Transform the average grey matrix into crisp numbers by using a modified defuzzification method.
Step 3: Assign weights to respondents based on their expertise and experience. Initially, the weights of each of the experts were equally assigned, as the experts were selected for their profound knowledge of the area. The weighted average method is applied to come up with an overall crisp direct-relation matrix from the individual direct-relation matrices.

Step 4: Develop the *normalized direct relation matrix* (N) by multiplying the matrix in Step 3 using a multiplier, which is the minimum value of the inverse of the max of the sum of a row. Then calculate the total relation matrix by multiplying N with the inverse matrix of the difference of N and the identity matrix.

Step 5: Calculate the causal parameters “R” and “D” which define the summation of all the rows and the summation of all the columns for each of the variables.

Step 6: For a given Factor i, calculate Pi which means R+D and Ei which means R-D. Then use them as x-axis and y-axis to develop the causal diagram. R+D is called “prominence” which denotes the total effect received or given by any factor. R-D is called “relation” of every factor to the other factors. Thereafter perform the *principal component analysis* to derive factors for both causal and effect factors. The greater the value of Pi, the greater the overall prominence (i.e. the influence or importance) of Factor i in terms of the overall relationships with other factors. If Ei > 0, then Factor i is a net cause or the foundation for other factors. If Ei < 0, then Factor i is the net effect of other factors. For each factor the values can then be plotted on a two-dimensional axis.

Table 4 presents the results of the calculation after following the above steps. In total, five factors were identified as causal factors (as R-D > 0) and the other five factors as their effect (as R-D < 0). The digraph is drawn using the Cartesian Coordinate System, based on R-D as Y-axis and R+D as X-axis, as shown in Fig. 1.

<table><caption>**Table 4.** The prominence and net cause or effect for EA failure factors</caption><thead><tr><td>Factor</td><td>R</td><td>D</td><td>R+D</td><td>R-D</td></tr></thead><tbody><tr><td>F1</td><td>1.972</td><td>1.687</td><td>3.660</td><td>0.285</td></tr><tr><td>F2</td><td>1.798</td><td>1.806</td><td>3.604</td><td>-0.007</td></tr><tr><td>F3</td><td>1.329</td><td>1.885</td><td>3.213</td><td>-0.556</td></tr><tr><td>F4</td><td>2.257</td><td>1.550</td><td>3.806</td><td>0.707</td></tr><tr><td>F5</td><td>1.524</td><td>2.237</td><td>3.760</td><td>-0.713</td></tr><tr><td>F6</td><td>2.487</td><td>1.749</td><td>4.237</td><td>0.738</td></tr><tr><td>F7</td><td>1.852</td><td>2.079</td><td>3.931</td><td>-0.227</td></tr><tr><td>F8</td><td>1.478</td><td>2.555</td><td>4.034</td><td>-1.077</td></tr><tr><td>F9</td><td>2.033</td><td>1.892</td><td>3.925</td><td>0.141</td></tr><tr><td>F10</td><td>2.869</td><td>2.160</td><td>5.029</td><td>0.708</td></tr></tbody></table>
<figure><img src="image_3.png" /><figcaption>Fig. 1. Prominence-causal diagram for EA failure factors</figcaption></figure>

## 3.3 Sensitivity Analysis

We carried out the initial calculation by assigning equal weights to all the experts. However, results may suffer from biases due to the difference in their expertise and experience. To check the robustness of the results, we carried out a sensitivity analysis to check if there is a significant change in the pattern of the responses depending on different weights given to the experts. We generated four different scenarios by significantly changing the level of weights assigned to different experts. Table 5 shows the assigned weights for sensitivity analysis in each scenario. Fig. 2 presents the results of sensitivity analysis. By this sensitivity analysis, we found that the patterns of all the factors are similar for all the scenarios with small deviations. This indicates that our results are robust.

<table><caption>Table 5. Weights of experts assigned to different scenarios</caption><thead><tr><th></th><th>Expert1</th><th>Expert2</th><th>Expert3</th><th>Expert4</th><th>Expert5</th></tr></thead><tbody><tr><th>Basic scenario</th><td>0.2</td><td>0.2</td><td>0.2</td><td>0.2</td><td>0.2</td></tr><tr><th>Scenario1</th><td>0.15</td><td>0.15</td><td>0.25</td><td>0.2</td><td>0.25</td></tr><tr><th>Scenario2</th><td>0.3</td><td>0.2</td><td>0.2</td><td>0.15</td><td>0.15</td></tr><tr><th>Scenario3</th><td>0.1</td><td>0.25</td><td>0.15</td><td>0.25</td><td>0.25</td></tr></tbody></table>
<figure><img src="image_4.png" /><figcaption>Fig. 2. Sensitivity analysis using the four scenarios</figcaption></figure>

# 4 Findings and Discussion

There could be many reasons why an EA initiative fails in practice. Literature indicates ten main factors influence EA failure. Our grey-DEMATEL analysis further shows that those factors are not in isolation and they do not have the same importance as well. Five factors are influencing the others, and their level of influence differs. These five factors are the cause of EA failure, whereas the other factors are the effect of these five factors. This implies that those ten factors should not be treated with equal importance in practice. Our findings derived from the EA experts' understanding and knowledge of EA practice in different organizations. The limited sample size brings limitations to generalization of the findings. The results might be different per industry. However, it reflects the common existence of the interdependencies between EA failure factors in different contexts. In this section, we present and discuss the five causal factors which are viewed as the main causes of EA failure.

## 4.1 Inability to Handle Complexity by EA

EA should be able to deal with a complex landscape of systems that is continuously changing. Complexity often results in IT-project failure, and our study also found that complexity is the main cause of EA failure (F6). Although EA is often introduced to deal with complexity, complexity is often too challenging to handle. One expert formulated this as “*EA was initiated 2 years ago ... it now appears that it has become so complex due to all the different links and components that the cause of the malfunction cannot be found anymore*”. Although EA can provide insights into the complexity, it does not reduce the complexity and does not make the landscape simpler. This finding suggests that there are limits to the complexity an organization can handle, despite the various instruments to deal with them.

There are several drivers resulting in the complexity of EA implementation. For example, the everchanging needs, new technology developments, inadequate products, changing of dependencies over time, and difficulty to catch-up with the continuous changes. Also, the scope creep might make EA complex, and EA should not be viewed
as a tool for being able to deal with everything. EA is not a silver bullet, and scoping
should be applied to reduce the overall complexity of EA initiatives, instead of dedi-
cating efforts to manage unlimited complexity.

## 4.2 Lack of Proven Methodology

Given the many years practice by sharing knowledge from well-known EA frameworks such as TOGAF, Zachman, and FEAF, EA practitioners are still not clear which methods work in practice and create business value. The many competing EA methods might hinder the understanding of what works and what does not.

Lack of actionable methodology (F10) is considered the second top influencing fac-
tor for EA failure. The mainstream EA frameworks are general, but each industry has
its own characteristics in IT landscape and management. Between the general EA
frameworks and specific EA for a certain organization, domain-oriented reference ar-
chitectures are needed, and there is much more work to be done in the development of
more solid knowledge base of EA for each industry. Industry-specific EA framework
would help architects better in designing their organization-specific EA.

This factor also reflects that organizations need talents who know how to make use
of existing EA knowledge and are able to translate the strategic goal into tactical plan-
ning. Enterprise architecting is context-depending and requires architects having the
ability to contextualize the working EA processes and routine.

## 4.3 Lack of EA Knowledge

Top management often has limited knowledge of EA (F4). The lack of knowledge con-
stricts the use of EA in their decision-making and weakens their motivation in contin-
uous investment to EA development. Furthermore, EA knowledge is often not wide-
spread in the organization, leaving the architects on their own. One expert stated, "For
*me in my daily work, I experience setting up, executing and maturing EA as a 'difficult
to perform assignment,' especially in an organization that has been doing well accord-
ing to its own insight and movement for 150 years'*. Organization staff should under-
stand EA and its functions and roles to avoid failure. Although there some training and
certifications for practitioners to learn EA systematically, these are not sufficient for
their own organizations to understand EA. Improving the top management's learning
and understanding of EA has become imperative for further improving EA practice.

EA professional readings are often too technical or operational-oriented and use vo-
cularies developed in the EA world, but hardly understandable by people outside this
world. EA consultancy, communities, and consortiums have generated many industrial
reports or white papers to advocate the value of EA. But those are often in fragmenta-
tion, superficial, and marketing-oriented. The CXOs need a more solid, convincing, and
strategy-oriented knowledge about EA.

## 4.4 Lack of Communication

Architects are not able to communicate and collaborate with business people resulting
in EA failure (F1). They take the seat of the business persons, without really under-
standing them. Such a mentality results in low acceptance of architects and their methods and tools. EA should align IT and business, but architects taking on the seat of the business people only enlarges the gap.

Architects and EA consultants are expected to have strong communication skills. This is often mentioned in white papers or handbooks of EA, but suitable approaches to improve communication are hardly provided. In contrast, widely used management approaches often emphasize their specific way of communication. For example, Lean management approach advocates value stream mapping to improve communication and collaboration across different business units and puts the responsibility to the staff instead of to the lean experts [29]. EA can embrace a similar approach by empowering staff instead of telling them what to do. For implementation, it would be useful to develop its specific value-creation-oriented communication approach.

## 4.5 Lack of EA Tools

Last but not least, the lack of suitable EA tools can result in EA implementation failures (F9). Existing tools focus on the modeling of EA artifacts with limited support on other daily works of EA development, including change management, compliance check, impact analysis, comparison of alternative solutions, and so on.

EA has a strong technical origin, and many EA professionals have a technical background. For a long time, the EA practitioners and researchers emphasized on the modeling tools for creating EA models, for example, the ArchiMate language. These are used by experts and cannot be used by the staff like value stream mapping in the Lean management approach. This results in a reliance on a few people and unclarity whether the models represent reality. Furthermore, by relying on a few persons, the maintenance and use of the EA models become challenging. This implies that the threshold for using EA tools should be lowered. The development of smart EA tools should be balanced with consideration of both EA creation and utilization.

# 5 Conclusions and Future Research Agenda

In this study, we extracted ten factors that influencing EA failure from the literature. To explore and understand these factors, the grey-DEMATEL method was employed to analyze the input of five EA experts. The findings indicate that the ten factors are not equally important, and they could be divided into causal or effect types of factors. The five causal factors, listed by their level of influence from high to low, are the inability to handle complexity, a lack of proven EA methodology, lack of EA knowledge, lack of communication, and lack of EA tools. The inability to deal with a high complexity seems to be a root cause of EA failure. The five effect factors are lack of support, too high effort, lack of motivation, parallel processes, and unused artifacts. The improvement of EA practices should focus on the five causal factors, as they are the very foundation of EA failure. This implies that EA initiatives should start with reducing complexity by scoping, instead of managing unlimited complexity. Instead of developing yet another framework, research should focus on identifying practices that work and result in business benefits. Staff should understand the nature and use of EA. EA methodologies should provide corresponding communication methods. Finally, the
threshold of using EA and EA tools should be reduced to empower staff and to avoid overreliance on a few persons. Further research is needed to detail the causes and to understand them better.

EA is likely dependent on the context, and failure factors might be different per situation. This study has its limitation of having a limited number of experts to provide input, which might not fully reflect the EA practice in different industries. In addition, we focused on the discussion of the five causal factors and not on the five effect factors. The number of factors can be extended in further research, and the relationship between cause and effect can be researched. In future research, a diversity of EA initiatives can be investigated within different contexts. Context and situations differ, resulting in different ways EA is employed and different levels of complexity to deal with. This requires the involvement of more EA experts with diverse industrial background to generalize the findings. In addition, further investigation of the interdependencies between factors is needed to generate more insights into the EA failure in practice and how failure can be avoided. To establish the generalizability of these findings, future study should involve a theorization towards the development of a framework to explain the causal relationships of the factors.

## References

1. Smith, H.A., Watson, R.T.: The Jewel in the Crown – Enterprise Architecture at Chubb. MIS Quarterly Executive 14, 195-209 (2015)

2. Janssen, M.: Sociopolitical Aspects of Interoperability and Enterprise Architecture in E-Government. Social Science Computer Review 30, 24-36 (2012)

3. Tamm, T., Seddon, P.B., Shanks, G., Reynolds, P., Frampton, K.: How an Australian Retailer Enabled Business Transformation Through Enterprise Architecture. MIS Quarterly Executive 14, 181-193 (2015)

4. Schmidt, C., Buxmann, P.: Outcomes and success factors of enterprise IT architecture management: empirical insight from the international financial services industry. European Journal of Information Systems 20, 168-185 (2011)

5. Perez-Castillo, R., Ruiz, F., Piattini, M., Ebert, C.: Enterprise Architecture. IEEE Software 36, 12-19 (2019)

6. Kaisler, S.H., Armour, F.: 15 Years of Enterprise Architecting at HICSS: Revisiting the Critical Problems. In: the 50th Hawaii International Conference on System Sciences, pp. 4808-4816. (2017)

7. Gong, Y., Janssen, M.: The value of and myths about enterprise architecture. International Journal of Information Management 46, 1-9 (2019)

8. Shanks, G., Gloet, M., Someh, I.A., Frampton, K., Tamm, T.: Achieving benefits with enterprise architecture. The Journal of Strategic Information Systems 27, 139-156 (2018)

9. Roeleven, S.: Why Two Thirds of Enterprise Architecture Projects Fail. Software AG (2010)

10. Sessions, R.: The IT complexity crisis: Danger and opportunity. ObjectWatch (2009)

11. Hope, T., Chew, E., Sharma, R.: The Failure of Success Factors: Lessons from Success and Failure Cases of Enterprise Architecture Implementation. In: Proceedings of the 2017 ACM SIGMIS Conference on Computers and People Research, pp. 21-27. ACM, (2017)

12. Banaeianjahromi, N., Smolander, K.: Lack of Communication and Collaboration in Enterprise Architecture Development. Information Systems Frontiers 21, 877-908 (2019)
13. Kotusev, S.: Enterprise Architecture: What Did We Study? International Journal of Cooperative Information Systems 26, 1730002 (2017)

14. McConnell, S.: Rapid Development. Microsoft Press (1996)

15. Nelson, R.R.: IT-project Management: Infamous failures, classic mistakes and best practices. MISQ Executive 6, 67-78 (2007)

16. Gong, Y., Yang, J., Shi, X.: Towards a comprehensive understanding of digital transformation in government: Analysis of flexibility and enterprise architecture. Government Information Quarterly 37, 101487 (2020)

17. Lu, X., Liu, H., Ye, W.: Analysis failure factors for small & medium software projects based on PLS method In: The 2nd IEEE International Conference on Information Management and Engineering (ICIME), pp. 676 - 680. IEEE, (2010)

18. Yeo, K.T.: Critical failure factors in information systems projects. International Journal of Project management 20, 241-246 (2002)

19. Pinto, J.K., Mantel, S.J., Jr: The causes of project failure. IEEE Transactions on Engineering Management 37 269 - 276 (1990)

20. Daniels, C.B., LaMarsh, W.J.: Complexity as a Cause of Failure in Information Technology Project Management. In: IEEE International Conference on System of Systems Engineering, 2007 (SoSE '07), pp. 1 - 7. IEEE, (2007)

21. Dale, M., Scheepers, H.: Enterprise architecture implementation as interpersonal connection: Building support and commitment. Information Systems Journal (2019)

22. Löhe, J., Legner, C.: Overcoming implementation challenges in enterprise architecture management: a design theory for architecture-driven IT Management (ADRIMA). Information Systems and e-Business Management 12, 101-137 (2014)

23. Iyamu, k.: Understanding the Complexities of Enterprise Architecture through Structuration Theory. Journal of Computer Information Systems 59, 287-295 (2019)

24. Safari, H., Faraji, Z., Majidian, S.: Identifying and evaluating enterprise architecture risks using FMEA and fuzzy VIKOR. Journal of Intelligent Manufacturing 27, 475-486 (2016)

25. Nam, K., Oh, S.W., Kim, S.K., Goo, J., Khan, M.S.: Dynamics of Enterprise Architecture in the Korean Public Sector: Transformational Change vs. Transactional Change Sustainability 8, 1074 (2016)

26. Govindan, K., Chaudhuri, A.: Interrelationships of risks faced by third party logistics service providers: A DEMATEL based approach. Transportation Research Part E: Logistics and Transportation Review 90, 177-195 (2016)

27. Lee, H.-S., Tzeng, G.-H., Yeih, W., Wang, Y.-J., Yang, S.-C.: Revised DEMATEL: Resolving the infeasibility of DEMATEL. Applied Mathematical Modelling 37, 6746-6757 (2013)

28. Cui, L., Chan, H.K., Zhou, Y., Dai, J., Lim, J.J.: Exploring critical factors of green business failure based on Grey-Decision-making Trial and Evaluation Laboratory (DEMATEL). Journal of Business Research 98, 450-461 (2019)

29. Gong, Y., Blijleven, V.: The role of Lean principles in supporting knowledge management in IT outsourcing relationships. Knowledge Management Research & Practice 15, 533-541 (2017)