ArticlePDF Available

Abstract and Figures

Enterprise architecture (EA) is widely employed to reduce complexity and to improve business–information technology (IT) alignment. Despite the efforts by practitioners and academics in proposing approaches to smoothen EA development, it is not easy to find a fully successful EA. Because EA development is a complex endeavour, it is important to understand the obstacles that practitioners face during EA development. With the grounded theory, we studied how obstacles during EA development emerged from practitioners’ point of view in 15 large enterprises. The study identifies lack of communication and collaboration as the core obstacle that can explain many other obstacles. Communication and collaboration were also harmed by other perceived EA development obstacles, including lack of knowledge and support inside organization and issues imposed by external parties, hesitation in training personnel, setting too ambitious goals, constant change of management, (lack of) clarity in EA development process, lack of budget, forcing personnel to adopt EA, lack of motivation, organizational culture, and organizational structure deficiencies. The lack of communication and collaboration caused several undesired effects to organizations, such as being unable to set common goals and achieve a shared understanding, personnel’s distrust, endangered EA governance, lack of innovation capability, lost competitive edge, and ineffective EA outputs. The study highlights that organisations should improve their communication and collaboration before embarking on EA to encounter fewer obstacles. We provide four recommendations for practitioners to improve communication and collaboration in EA development.
Content may be subject to copyright.
1
Lack of Communication and Collaboration
in Enterprise Architecture Development
Negin Banaeianjahromi
School of Business and Management, Lappeenranta University of Technology, Lappeenranta, Finland
Kari Smolander
Department of Computer Science, Aalto University, Espoo, Finland
Correspondence details: Negin Banaeianjahromi, negin.banaeianjahromi@lut.fi , School of Business and
management, Lappeenranta University of Technology, P.O. Box 20, 53851 Lappeenranta, Finland
Tel: +358 46 9414496
Abstract
Enterprise architecture (EA) is widely employed to reduce complexity and to improve businessinformation
technology (IT) alignment. Despite the efforts by practitioners and academics in proposing approaches to smoothen
EA development, it is not easy to find a fully successful EA. Because EA development is a complex endeavour, it is
important to understand the obstacles that practitioners face during EA development. With the grounded theory, we
studied how obstacles during EA development emerged from practitioners’ point of view in 15 large enterprises. The
study identifies lack of communication and collaboration as the core obstacle that can explain many other obstacles.
Communication and collaboration were also harmed by other perceived EA development obstacles, including lack of
knowledge and support inside organization and issues imposed by external parties, hesitation in training personnel,
setting too ambitious goals, constant change of management, (lack of) clarity in EA development process, lack of
budget, forcing personnel to adopt EA, lack of motivation, organizational culture, and organizational structure
deficiencies. The lack of communication and collaboration caused several undesired effects to organizations, such as
being unable to set common goals and achieve a shared understanding, personnel’s distrust, endangered EA
governance, lack of innovation capability, lost competitive edge, and ineffective EA outputs. The study highlights that
organisations should improve their communication and collaboration before embarking on EA to encounter fewer
obstacles. We provide four recommendations for practitioners to improve communication and collaboration in EA
development.
Keywords: Enterprise architecture, enterprise architecture development, obstacles, communication and collaboration,
grounded theory, large enterprises.
Acknowledgement
This study was funded by Academy of Finland grant #259454.
2
1. Introduction
Enterprise architecture (EA) manages the complexity of an organisation by providing a structured description of an
enterprise and its relationships (Niemann 2006; Ross, Weill, and Robertson 2006; Simon, Fischbach, and Schoder
2014; Winter and Fischer 2006; Zachman 1987). Despite being considered a relatively young discipline (Boucharas
et al. 2010; Bucher et al. 2006), people from both business and academia have become interested in EA and realised
its importance. EA has been acknowledged to improve business and IT alignment, which is recognised to be critical
for organisations’ success (Alaeddini and Salekfard 2013; Löhe and Legner 2014; Schmidt and Buxmann 2011; Tamm
et al. 2011; Winter and Schelp 2008; Wu and Lu 2007). According to recent surveys and studies, business and IT
alignment is the most critical concern among CIOs (Guillemette and Paré 2012; Luftman and Ben-Zvi 2011; McGee
2008). EA has been reported to be used as a communication tool for business and IT alignment (Niemi and Pekkola
2015; Tamm et al. 2011). Organisations are increasingly initiating EA projects to achieve suitable business and IT
alignment and EA is receiving more attention from industry as well as from academy due to its potential to gear IT to
the needs of business (Wan and Carlsson 2012).
Many studies exist about the benefits of EA, for example reduce IT costs, more effective use of resources, improve
agility and innovation, reduce complexity, and improve business and IT alignment (Boucharas et al. 2010; Foorthuis
et al. 2010; Niemi 2008; Tamm et al. 2011; Wan et al. 2013; Foorthuis et al. 2016). Several studies addressed the
significant role of EA in organisations (Alaeddini and Salekfard 2013; Kappelman and Zachman 2013), and EA
frameworks and methods (Bernus and Noran 2010; Erol, Sauser, and Mansouri 2010; Fatolahi et al. 2007; Hoogervorst
2004; Kilpeläinen 2007; Kim et al. 2006; Lankhorst 2013; Sowa and Zachman 1992; Vargas et al. 2014; Nogueira et
al. 2013; Bernaert et al. 2016). Commonly, EA is adopted by organizations to facilitate enterprise integration issues
and reduce complexities (Chen, Doumeingts, and Vernadat 2008; Henderson and Venkatraman 1993;
Banaeianjahromi and Smolander 2016b), to increase quality and responsiveness to the ever changing environment
(Huysmans and Verelst 2013), for better institutionalization (Chung et al. 2009), for better decision making (Jensen,
Cline, and Owen 2011), and to increase business performance (Boucharas et al. 2010; Van Steenbergen et al. 2011) .
Well implemented EA is both stable and flexible which assist an organization to innovate and change (Rouhani et al.
2014).
In the context of enterprise integration, EA can be utilized as a tool to determine the interconnections and technologies
used between systems to evaluate the needs and impacts of integration. In our previous study, we identified the issue
of inefficient architectural descriptions as a potential challenge in enterprise integration projects (Banaeianjahromi et
al. 2016). EA is inefficient when it is not up to date, complete, understandable, nor in detail. Kähkönen, Smolander,
and Maglyas (2016), also mention the need of a complete, detailed and up to date EA in order to facilitate integration
in the organizations and to ensure that integration is aligned with organizational goals and also to evaluate the
integration needs, requirements, and impacts. The issue of inefficient EA not only hinders the integration projects but
also puts the organization in chaos as there is no guideline or plan to determine the consequences of actions in the
organization. Therefore, it is crucial to have an efficient EA in the organization.
Despite the popularity of EA in the last decade, it is not easy to find a successfully developed EA in an organisation
(Iyamu 2009). According to Roeleven's (2010) white paper, 66 percent of EA projects did not fulfil the expectations
of the surveyed organisations. Furthermore, the challenges that are faced during EA development are rarely technical
but political, project management, and organisational issues (Kaisler, Armour, and Valivullah 2005). Although
numerous studies have reported organisational experiences and best practices to develop EA (Hjort-Madsen 2006;
Isomäki and Liimatainen 2008; Nakakawa, Bommel, and Proper 2010; Seppänen, Heikkilä, and Liimatainen 2009),
the ineffectiveness of EA development is present in many studies (Kähkönen, Smolander, and Maglyas 2016;
Bricknall et al. 2006; Ross, Weill, and Robertson 2006).
In practice, EA development projects encounter different challenges, and not all of these projects end with success
(Haki, Legner, and Ahlemann 2012; Roeleven 2010; Schmidt and Buxmann 2011; Seppänen, Heikkilä, and
Liimatainen 2009). Many studies have addressed the challenges and issues in EA development, but none of these have
gone further than proposing taxonomies (Armour and Kaisler 2001; Bricknall et al. 2006; Chuang and van
Loggerenberg 2010; Hauder et al. 2013; Isomäki and Liimatainen 2008; Iyamu 2009; Jahani, Reza Seyyed Javadein,
3
and Abedi Jafari 2010; Kaisler, Armour, and Valivullah 2005; Löhe and Legner 2014; Lucke, Krell, and Lechner
2010; Nikpay et al. 2013; Roth et al. 2013; Saarelainen and Hotti 2011; Seppänen, Heikkilä, and Liimatainen 2009;
Valtonen et al. 2011; Wan, Luo, and Luo 2014; Ylimäki 2008). Therefore, there is a need for research to move further
than categorising the challenges of EA to a more theoretical direction.
We wanted to increase our understanding of obstacles in EA based on an empirical qualitative approach. Therefore,
we investigated the process of EA development in 15 large enterprises using the grounded theory method (GTM). We
made inquiries in three rounds through interviews and organisational documents. With this paper, first we aim to
explain the EA development obstacles in the studied enterprises. Second, we look for core obstacles that can explain
most of the other obstacles as their root cause. Finally, we investigate the causes and effects imposed by the core
obstacle to the organizations. Additionally, we suggest recommendations to facilitate the removal of the core obstacle
in EA development.
The paper is organised as follows. First, we review existing research on EA and its development obstacles. We then
explain our choice of research methodology. Then we present the analyses and interpretations of the data, and we
present our findings. In the discussion section, we compare our results to the literature and discuss the implications of
the results on practice and research. We also discuss limitations and possible future study paths. Finally, we conclude
with the key contributions.
2. Background
2.1. Enterprise architecture
Goethals et al. (2006) referred to enterprises as ‘living things’, meaning that they need to be (re-)architected constantly
to achieve their necessary agility, alignment, and integration. Taking all of the architecture of the entire enterprise into
consideration, all enterprise entities, such as systems, stakeholders, relationships, dependencies and business
strategies, can be architected in an EA effort (Goethals et al. 2006). EA is referred to as a holistic management of
information systems in organisational approaches (Ross, Weill, and Robertson 2006; Tamm et al. 2011; Winter and
Fischer 2006). It describes how different entities in an organisation, such as systems, processes, organisations and
people, work together as a whole to reduce costs and respond to new business opportunities (Morganwalp and Sage
2004; Penttinen and Isomäki 2010; Ross, Weill, and Robertson 2006).
There are different perspectives to EA (Niemann 2006; Ross, Weill, and Robertson 2006; Simon, Fischbach, and
Schoder 2014; Winter and Fischer 2006; Zachman 1987) and there is no universally accepted definition of EA (Rohloff
2005; Ross, Weill, and Robertson 2006; Zachman 1987). The Center for Information Systems Research (CISR)
defines enterprise architecture as ‘the organizing logic for business process and IT capabilities reflecting the
integration and standardization requirements of the firm’s operating model’. They consider architecture as ‘a
strategic, rather than technical, exercise’(MIT CISR 2016). EA has also been defined as ‘the blueprint or the
organizing logic that binds together aspects of (1) business planning, (2) business operations, (3) process
rationalization, and (4) enabling IT infrastructure’ (Kamoun 2013).
Commonly, EA is considered as a ‘bridge’ between strategy and implementation that aligns the business and IT
(Hiekkanen et al. 2013). Bacon and Fitzgerald (2001) described the purpose of EA as a framework or method to align
business and IT as well as cover both organisational and technical aspects. According to Tamm et al. (2011), EA’s
organisational role is positioned between IT and business strategy. Being similar to a strategy, EA aims to describe a
long-term and organisation-wide vision of business processes and IT systems in great detail (Tamm et al. 2011). In an
EA, the organisation is viewed as a complicated system that need to be broken down into manageable entities to
improve the understandability of the organisation’s complexity (Kamoun 2013). EA reduces the complexity of the
current state and provides a mechanism for making decisions about the future state of the enterprise (Hiekkanen et al.
2013; Van Der Raadt, Hoorn, and Van Vliet 2005). EA development is a planned process of evolution that is usually
triggered by a business strategy shift, mergers and acquisitions, or when the current EA is not sufficient (Postina et al.
2010). EA development provides a long-term view by analysing the current status (As-Is) and determining the target
4
status (To-Be) of the processes, systems, technologies, and strategies of an organization through a transition plan
(Ross, Weill, and Robertson 2006; Winter and Fischer 2006).
EA projects are continuous programmes that must be updated at different periods of time based on the enterprise’s
needs and changes (Jahani, Reza Seyyed Javadein, and Abedi Jafari 2010). Thus, in this paper, by EA project we mean
a continuous project that cannot be done all at once and is developing continuously.
2.2. Enterprise architecture development obstacles
According to Cambridge Dictionary, an obstacle is ‘Something that blocks you so that movement, going forward, or
action is prevented or made more difficult’. We define EA obstacles as the factors confronting the EA project with
difficulties and loss of resources that cannot be solved easily and therefore they create risks of project failure.
EA frameworks and methodologies assist enterprise architects by providing guidelines through different steps of EA
development (Hoogervorst 2004; Lankhorst 2013; Zachman 1987; Medini and Bourey 2012). Many enterprises fail
because they only focus on the framework, without considering how to implement and maintain the EA (Bricknall et
al. 2006). Practitioners face many challenges that need to be solved in EA development, and in some cases, they face
obstacles that cause project termination and failure. Therefore, in order to mitigate these issues, it is crucial to
understand the challenges and obstacles that hinder EA development.
Several studies have addressed different EA challenges and obstacles. EA development challenges can be
environmental, technical, managerial, or social (Banaeianjahromi and Smolander 2016a). Lucke, Krell, and Lechner
(2010) categorise the EA issues into management, semantic problems, insufficient resources, complexity, and
representation, while Bricknall et al. (2006) describe EA issues in terms of three categories: management, scope, and
content. According to Isomäki and Liimatainen (2008), the three most pivotal challenges of EA are implementation
ability and governance, structure of the state government and advancement of interoperability.
Management buy-in is mentioned as a critical factor in EA development to establish the documentation and the
processes to keep the EA project ongoing (Bricknall et al. 2006). Insufficient management commitment during EA
development is reported as a major issue in the literature (Lucke, Krell, and Lechner 2010; Seppänen, Heikkilä, and
Liimatainen 2009; Valtonen et al. 2011; Ylimäki 2008). A lack of shared understanding of EA is another major issue
that is frequently reported in the literature (Hjort-Madsen 2006; Iyamu 2009; Saarelainen and Hotti 2011; Seppänen,
Heikkilä, and Liimatainen 2009; Ylimäki 2008). The issues of shared understanding and communication are related
to each other. According to Saarelainen and Hotti (2011), communication and shared understanding have major roles
in group working and decision-making. Communication and common understanding during EA facilitate information
exchange between different EA stakeholders (Nikpay et al. 2013). Bricknall et al. (2006) mentioned communication
as being an important and necessary component during EA implementation. Hjort-Madsen (2006) pointed out that a
successful EA implementation requires constant communication and cooperation across different levels and functions.
Chuang and van Loggerenberg (2010) studied the challenges faced by enterprise architects. They identified five
challenges: communication, obtaining buy-in from the stakeholders, ownership, perceptions of the enterprise architect,
and organisational politics. In another study, Roth et al. (2013) reported the EA challenges faced by organisations by
conducting a survey focussing on EA documentation. They identified ‘huge effort of data collection’ and ‘bad quality
of EA model data’ as the most reported issues among 140 valid responses. ‘Insufficient tool support’, ‘No management
support’, and ‘low return on investment’ were the other important reported challenges.
Jahani, Reza Seyyed Javadein, and Abedi Jafari (2010) listed employing experienced and educated consultants as a
success factor of enterprise architecture planning. Armour, Kaisler, and Liu (1999) suggested employing good
consultants who can offer expert advice, facilitate meetings, and train the team. However, they did not mention
anything about the challenges of employing EA consultants. Also, Lucke, Krell, and Lechner (2010) pointed out ‘lack
of experienced architects’ as an issue in EA development. Nevertheless, they did not mention what they meant by
architects: are they companies’ trained personnel or consultants from outside? The literature suggests that the most
common EA development challenges are not technical issues but human related. Insufficient management support,
lack of shared understanding and lack of communication are among the most cited EA development issues. Although
5
many scholars have identified communication and collaboration as a major issue during EA development, the
explanation of why and how lack of communication and collaboration leads to a permanent or temporary EA project
failure is incomplete and not grounded in theory (Nikpay et al. 2013; Schmidt and Buxmann 2011; Van der Raadt et
al. 2010; Ylimäki 2008; Kang et al. 2010; R. Abraham et al. 2013; Niemietz, De Kinderen, and Constantinidis 2013).
According to the literature, most EA development obstacles occur during the development stage of an EA project.
Very little attention has been given to the issues raised in the pre-development and post-development stages of EA
projects.
3. Research method
We applied the interpretivist paradigm to understand the whole complex phenomenon and selected a qualitative
strategy using the grounded theory methodology (GTM) to carry out this study. Glaser and Strauss outlined a research
methodology to systematically derive theory from empirical data on social contexts (Glaser and Strauss 1967). In this
study, GTM helped us to make sense of the obstacles that organisations faced during their EA development projects.
In GTM, the systematic procedure of data collection and analysis is the major source of its effectiveness, which allows
it to ground the created theory in reality (Corbin and Strauss 1990). We collected and analysed the data iteratively by
investigating the obstacles perceived from each organisation at a time. To analyse our data, we used Strauss and
Corbin’s coding approach, which includes open, axial and selective coding. Coding represents ‘the analytic processes
through which data are fractured, conceptualised, and integrated to form theory’ (Strauss and Corbin 1998).
One of the major strengths of GTM is that it has an ‘open-minded’ but not ‘empty headed’ attitude toward the empirical
data to let empirical observations and theoretical insights influence the research interest (Goldkuhl and Cronholm
2010; McGhee, Marland, and Atkinson 2007). As we went forward in our research, the research questions developed
according to our observations and insights, which we could note from the memos that we wrote during the research to
keep track of our thoughts.
3.1. Data collection
We collected the data in three rounds. In the first round of interviews, we employed snowball sampling (Corbin and
Strauss 2008) to gather data from three organisations (Cases K, M, and P) in May and June 2014. In total, nine experts
were interviewed, with the average duration of the interviews being 1 hour and 15 minutes. The interviewed companies
were large, with sizes from 1,000 to 30,000 employees. In the second round, we gathered data from 14 organisations
(Cases A to N) with purposeful sampling (Patton 2005) in the period from May to July 2015. In total, 20 experts were
interviewed, with the average duration of the interviews being 1 hour and 10 minutes. The interviewed companies
were large, with sizes from 600 to 35,000 employees. All of these organisations had finished at least one round of EA
development, and some of them were in the stage of updating their EA.
During the first round of interviews, we collected interviewees’ feedback on the definition of EA, the utilization of
EA in their work, the influence of EA in their company, Enterprise Integration (EI) challenges, and any concerns
regarding EA development and maintenance. The aim of the first round of the interviews was to get a better
understanding of the position of EA in the organizations and to identify any challenges regarding EA and EI. We
deemed semi-structured interviews with open-ended questions to be suitable for data collection. This way, the
interviewer could ensure that all of the pre-planned themes were covered and the interviewees could think about and
reflect on the topics as well as bring their experience and perceptions to the discussion (Lange and Mendling 2011).
When required, more detailed questions were asked based on the intervieweesresponses.
For the second round of data collection, we initiated our purposeful sampling in the beginning of May 2015 and sent
an email to an EA specialist group with 335 members to request qualified members of the group to assist us with
interviews. We received 38 replies from the group members who were ready to do the interviews. Then, we telephoned
them, explained the purpose of the interview and asked for more information about their background and their
experience with EA development projects. From these 38 responses, we selected the experts who were intensely
involved with an EA development projects in a large organisation. In total, we interviewed 20 experts including chief
executive officers (CEO), chief information officers (CIOs), project managers, IT managers, and heads of related
6
departments. All of the interviews took place in the interviewees’ workplaces. The main questions addressed the
obstacles, missions, and goals of the EA project in different EA development stages as well as the results and outcomes
of the project. Table 1 presents the information about the interviewed organisations.
For the third round of data collection, we sent emails to the interviewees and asked for their EA documents. Out of 14
organisations from the second round of the data collection, five organisations (Cases A, G, I, K and L) sent us
documents regarding their EA development project. In total, we analysed nine documents (329 pages). Furthermore,
during the analysis, we contacted some of the interviewees to get more information or clarification on an issue or topic
that they had had mentioned during the interviews.
Table 1 Case organisations and interviewees information
3.1.1. Case descriptions
We collected data from 15 large organizations.
Case A: is a governmental organization with several branches in different cities. The interviewee was the CIO of the
head branch of the organization with the educational background in business administration. In total the organization
has 30 branches and 1500 employees. Their main goal to develop EA was to achieve organizational integration not
Cases
Industry
No. of
employees
No. of
interviews
Roles of interviewees
1st Round
P
Global manufacturing enterprise
30,000
6
Business-IT negotiator
IT manager of business area
Manager of E-business and integration
Head of E-business and integration
Business support manager of a business
area
Director of business process development
K
Automotive industry
1570
2
CIO
Head of IT department
M
Automotive industry
1,600
1
Head of systems analysis and design
2nd Round
A
Governmental organisation
1,500
1
CIO
B
Banking industry
800
1
CIO
C
Consulting industry
2,000
1
Project manager
D
Governmental organisation
20,000
1
IT manager
E
Cement industry
720
1
CIO
F
Consulting industry
600
1
Project manager
G
Governmental organisation
10,000
3
CIO
Head of systems analysis and design
Head of business process development
H
Automotive industry
9,700
3
CEO
R&D director
Head of business process development
I
Automotive industry
35,000
1
CIO
J
Automotive industry
11,000
2
CIO
Head of R&D
K
Automotive industry
1,570
1
CIO
L
Banking industry
1,000
2
Head of software development
IT manager
M
Automotive industry
1,600
1
Head of systems analyse & design
N
Governmental organisation
1,860
1
IT manager
7
only in the system level but also in processes and strategies. EA development was outsourced to an EA consultant
company.
Case B: provides services to banks. Case B is a large organization with 800 employees in several branches. They
developed EA to improve integration and standardization in their organization. The interviewee was the CIO of the
organization and he had experience in the field of IT. B wanted to increase the level of maturity in their organization.
They developed EA internally with minor help from external consultants.
Case C: provides IT consulting services to companies. Case C has about 2000 employees in different branches around
the country. The interviewee was the one of the project managers of the organization and involved in the EA
development project of the organization. The interviewee has experience in software development. Case C developed
EA internally. Their goal was to reduce costs and improve integration within their organization.
Case D: is a governmental organization with several branches in different cities. In total Case D has 20,000 employees.
The interviewee was the IT manager of one of the branches. The interviewee had experience in the field of IT. Case
D outsourced their EA development. Their goal was to integrate business processes and information systems.
Case E: is in the cement industry with 720 employees. The interviewee was the CIO of the organization with IT
experience. They developed EA internally. The goal was to reduce costs and improve decision making in the
organization.
Case F: is a consulting organization with 600 employees. The interviewee was one of the project managers of the
organization. The interviewee has experience in IT and business. They outsourced their EA development. Their goal
was to provide information systems integration, have detailed and up to date documentation, improve business
processes, and increase the maturity of the organization.
Case G: is a governmental organization with 10,000 employees. The interviewees were CIO with experience in IT,
head of system analysis and design with experience in software engineering, and head of business process development
with experience in business and industrial management. They outsourced their EA development. Their goal was to
provide information systems integration, increase maturity of the organization, reduce costs, and improve business
processes.
Case H: is in automotive industry with 9,700 employees. The interviewees were the CEO of the organization with
industrial management experience, R&D director with experience in innovation management, and head of business
process design with experience in IT and business. They developed EA internally with getting minor help from an
external consultant. Their goal was to provide information systems integration and reduce costs.
Case I: is in automotive industry with 35,000 employees. The interviewee was the CIO of the organization with
experience in software development. EA was developed partly by EA consultant in the past but then they continued
to develop EA internally. Their goal was to provide information systems integration and reduce costs.
Case J: is in automotive industry with 11,000 employees. The interviewees were the CIO of the organization with
experience in industrial management and IT and the head of R&D with experience in IT. They developed their EA
internally. Their goal was to provide information systems integration, reduce costs, and provide faster production.
Case K: is in automotive industry with 1,570 employees. The interviewees were the CIO of the organization with
experience in IT and business and the head of IT department with experience in software development. They
developed their EA internally. Their goal was to provide information systems integration and reduce costs.
Case L: is in banking industry with 1,000 employees. The interviewees were the head of software development with
experience in software development and IT manager with experience in IT and business. They outsourced their EA
development to an EA consulting company. Their goal was to provide information systems integration and have a
detailed up to date documentation.
8
Case M: is in automotive industry with 1,600 employees. The interviewee was the head of systems analysis and design
with experience in software engineering and business. They developed EA internally. Their goal was to improve
business processes and provide information systems integration.
Case N: is a governmental organization with 1,800 employees. The interviewee was the IT manager of the
organization with experience in IT. They outsourced their EA development. Their goal was to provide information
systems integration and reduce costs.
Case P: is a global manufacturing enterprise with 30,000 employees. We interviewed six persons from this
organization. They all had experience in IT and business. They developed their EA internally.
3.2. Data analysis
We analysed the data by adopting the interpretivist paradigm (Easterbrook et al. 2008). All the interviews were
transcribed to text format and then analysed with the qualitative data analysis tool Atlas.ti. Also the organisational
documents were imported to Atlas.ti for analysis. Based on ‘open coding’, ‘axial coding’ and ‘selective coding’
principles from the grounded theory method (Strauss and Corbin 1998), we analysed our dataset as we collected them.
Open coding is defined as ‘the analytic process through which concepts and categories are identified and their
properties and dimensions are discovered in data’ (Strauss and Corbin 1998). The key activities of this phase are
naming, comparing, and memo writing (Locke 2001). Axial coding is ‘the process of relating the categories to their
subcategories. It is termed “axial” because the coding occurs around the axis of a category, linking the category at the
level of properties and dimensions’ (Strauss and Corbin 1990). The final step of the analysis process was selective
coding. Determining the central category that all other major categories are related to is a part of selective coding
(Strauss and Corbin 1998). Figure 1 presents the process of data analysis in this study.
Fig 1 Phases of data analysis
3.2.1. Phase 1 and 2open coding and axial coding
In the open coding, we read all of the interview transcripts and conceptually labelled words, sentences, and paragraphs
through constant comparison (Strauss and Corbin 1998). ‘Budget’, ‘teamwork’, ‘organization and consultant
9
relationship’, ‘EA updates’ and ‘infrastructure’ are the examples of open codes that we created. For example, we
assigned the code ‘training personnel’ to the following interview quotation: ‘When you lose your trained human
resource, it is harmful for the organisation because the organisation is losing its knowledge and potential’ Case B,
CIO. Then, we grouped the conceptually similar ones to form categories and subcategories using theoretical
comparison (Strauss and Corbin 1998).We also used the interview questions and themes to lead us in conceptually
categorising the data.
We also provided a categorisation level to increase the understandability of the codes during the coding process. For
example, we identified ‘hesitation in training personnel’ as a pre-development EA obstacle, which we coded as
EA::obstacle::hesitation in training personnel’. During the open coding, we constantly compared the codes and
merged similar codes. For instance, ‘confusion in governmentand political changes of the country’, were merged
into one category: ‘EA::obstacle::government-related political issues’.
Open coding and axial coding processes happened in parallel. During the axial coding, we dug into the data to identify
the relationships, such as the conditions, cause-and-effect relationship, and interactions, between the categories and
subcategories. For instance, we noted that confusion in government is associated with the political changes of the
country that has a direct impact on the management of governmental organisations, which results in constant change
of management.
According to Bowen (2008), it is challenging for qualitative researchers to recognise the theoretical saturation point.
This is a milestone that should be met in a grounded theory study to prove that the data categories are well established
and validated (Bowen 2008; J. M. Corbin and Strauss 1990). Corbin and Strauss (2008) explains saturation as the
situation ‘when no new categories or relevant themes are emerging’(p.148). We believe that we reached the point of
data saturation or theoretical saturation, as new data did not add new insights and we faced data replication and
redundancy. According to Pandit (1996), theoretical saturation has been met when the marginal value of new data is
minimal. For instance, during the second round of interviews, we noticed that codes in the data started to repeat after
the 12th interview. We reached the point of theoretical saturation as (1) no new and relevant data created any new
categories; (2) the properties and dimensions of the EA obstacles were being assigned to the already established
categories, and no new categories were added; and (3) the patterns in data were repeated and the relationship among
categories were well established (Duchscher and Morgan 2004; Morse 1995). We ended up with 319 codes and 15
categories in the initial phase of analysis. Appendix III presents the categories and their descriptions as well as
examples of codes in each category and their relationships to other categories.
After open and axial coding of the first round of interviews, we identified three EA obstacles:
(1) Lack of collaboration in different forms, such as lack of collaboration between other personnel and architects,
and lack of collaboration between members of a team.
(2) Lack of management support to prioritize the EA development and to assign enough budget and resources
(3) Personnel resistance to change due to several reasons, such as lack of knowledge, lack of trust, and fear of
losing jobs
Interestingly, while the organisations knew about the issues of collaboration, resistance and support in their
organizations, they still started the EA development and hoped that these issues will be eliminated after EA
development. However, this did not happen, because these issues constantly hindered the quality of EA. Based on
these observations, obstacles such as personnel resistance to change, lack of collaboration, and lack of management
support, which had already appeared before EA development, seemed to continue during and after EA development
when they were not addressed properly. So, besides further investigation of EA obstacles we also got interested in
understanding how obstacles appeared in different EA development stages (pre-development, development, post-
development).
3.2.1.1. Investigating the EA obstacles
We continued the process of data collection and analysis and moved to the second round of data collection. This
included the identification of the relationships between EA obstacles and related concepts. We investigated especially
10
how the mentioned three EA obstacles that we identified initially have emerged and what are the causes and effects
of these obstacles in an EA development project. With regard to axial and selective coding (Corbin and Strauss 2014),
we wanted to understand the possible relationships between the identified obstacles to identify the core category. We
made a table (Appendix II) that presents all of the identified obstacles and their relationships (Is cause of, Is associated
with, Contradicts, Is part of, and Two-way causality) with other obstacles. Using Atlas.ti we constructed network
diagrams to illustrate the relationship between the codes. Figure 2 presents the network diagram of all the identified
EA obstacles and their relationships.
Fig 2 Network diagram of the identified obstacles and their relationships
11
We identified five types of relationships between the elements of interest in the data. For example, we used the ‘is
part of’ relationship when denoting that several obstacles‘EA consultant being inflexible’, ‘EA consultant being
inefficient’, ‘Lack of EA consultant innovation’, and ‘Inexperienced EA consultant’were parts of a higher-level
category named ‘EA consultantrelated issues’. ‘Is cause of’ is another type of relationship. For example, ‘political
changes in the country’ is a cause of ‘constant change of management’. Another identified type of relationship is
referred to as ‘is associated with’. For example, ‘Forcing personnel to adopt EA’ and ‘Hesitation in training personnel’
are associated with each other. ‘Contradicts’ is another type of relationship. For instance, we identified several
obstacles during EA development that prevented the project from being finished on time, like constant change of
management, lack of management support and lack of knowledge among personnel.
Besides identifying the EA development obstacles, we also wanted to see how the obstacles appeared in different
stages of EA development. We employed semi-structured and theme-based interview questions that focused on
obstacles observed during pre-development, development, and post-development in EA projects.
We defined EA obstacles as factors that confront the EA project, slowing progress or diminishing resources. Such
problems cannot be solved easily and may potentially cause project failure.
The interview questions were based on three EA development stages, and we used these stages to conceptualize the
identified obstacles. Appendix IV presents the identified obstacles in EA development assigned to the three stages,
which we define for this study as follows:
1) Pre-development: the stage in which the organisation is in the process of deciding to implement EA, form
an EA team, select the EA consultant and set the mission and vision of the EA project.
2) Development: this stage consists of analysing the current situation of the organisation, planning the transition
stage to reach to the target situation and proposing the necessary projects to reach the target situation.
3) Post-development: the stage in which the organisation starts the projects defined in the previous stage to
develop the EA outputs. Also, it is in post-development stage that the EA updates occur.
From our analysis, we identified six obstacles that occurred more often across the stages than others. These obstacles
are:
(1) Lack of communication and collaboration
(2) Lack of management support
(3) Lack of knowledge among management
(4) Lack of motivation among personnel
(5) Lack of knowledge among personnel
(6) Personnel resistance to change
(7) EA consultant-related issues
(8) Government-related political issues
Appendix IV shows how the obstacles appeared in different stages of EA development. To simplify the network
diagram presented in Figure 2, we decided to move to a higher level of abstraction (Table 2).
Table 2 Providing higher level of abstraction
Higher level of abstraction
Most frequently repeated obstacles
Lack of support inside the organization
Lack of management support
Lack of motivation among personnel
Personnel resistance to change
Lack of knowledge inside the organization
Lack of knowledge among personnel
Lack of knowledge among management
Issues imposed by external parties
EA consultant-related issues
Government-related political issues
Lack of communication and collaboration
Lack of communication and collaboration
12
For each of the above four obstacles we drew diagrams to present their emergence with the most relevant obstacles
related to them. The diagrams are presented in Appendix V Figures V1, V2, V3, and V4. In these figures the circles
represent the higher level of abstraction for the most frequently repeated obstacles and the rectangle boxes are the
obstacles related to the most frequently repeated obstacles. The arrows shows Is cause of, Is part of, and Two-way
causality relationships identified using both Figure 2 and Appendix II.
3.2.2. Identifying the core category
In the third phase of analysis we identified the core category for selective coding. We used the diagrams presented in
Appendix V Figures V1, V2, V3, and V4 that illustrate the main EA development issues: (1) Lack of support inside
organizations, (2) Lack of knowledge inside organizations, (3) Issues imposed by external parties, and (4) Lack of
communication and collaboration.
These diagrams show how lack of communication and collaboration was present in all four diagrams. Therefore, we
considered lack of communication and collaboration as the core obstacle (Figure 3). At this point of the research we
asked the following research questions:
(1) What are the causes that hindered communication and collaboration in EA development projects?
(2) What are the effects of the lack of communication and collaboration in EA development projects?
Fig 3 The emergence of core category
3.2.3. Determining the causes and effects of lack of communication and collaboration
We identified lack of communication and collaboration as the core category and explained the relationships of other
major issues with this category. We could explain the emerging theory by revisiting the data from the core category
perspective. We noticed that lack of communication and collaboration is the obstacle that can explain other obstacles.
13
Besides the three general obstacles (lack of knowledge inside the organization, lack of support inside the organization
and issues imposed by external parties), we aimed to understand more specific causes and effects that are related to
these three general obstacles. Figure 4 illustrates the causes and effects of lack of communication and collaboration in
EA development projects. Besides lack of knowledge and support inside organization and issues imposed by the
external parties, we identified 11 causes (white boxes) and 6 effects (grey boxes) of lack of communication and
collaboration in EA development. Most of the obstacles presented in Figure 4 were already identified during axial
coding. In selective coding we were able to reveal more causes and effects of lack of communication and collaboration
in EA development, ‘Organizational culture’ and ‘clarity in EA development process’ as causes and ‘Personnel’s trust’
and ‘organization loses its competitive edge’ as effects. We were also able to determine the relationships between
causes and effects, how they affect each other and how the effects reflect to the EA development effort. We also
changed the code names to more abstract ones. For example, ‘lack of motivation among personnel’ was renamed to
‘lack of motivation’.
Fig 4 Causes and effects of lack of communication and collaboration
4. Findings
In this section, we explain our findings from the research phases. We also explain the line of thought that we followed
in order to find the core obstacle in EA development and construct our theory. First, we will describe the three major
obstacles that hinder communication and collaboration in EA development: Lack of knowledge inside organization,
lack of support inside organization, and issues imposed by external parties. Then we will also explain our observations
of the organizational documents and, finally, we will present our theoretical conclusion of the causes and effects of
lack of communication and collaboration in EA development.
4.1. Lack of knowledge and support inside organization
Knowledge and support inside organization are two connected concepts; being supportive is because of having enough
knowledge and lack of knowledge causes unsupportiveness. Thus, we decided to describe these two issues in one
section. We identified lack of knowledge inside organization and lack of support inside organizations as two of the
four major EA development obstacles. Figures V1 and V2 in Appendix V present the obstacles related to the lack of
14
knowledge and lack of support inside organization. We understood that lack of knowledge and support could be among
personnel as well as managers. Some examples of these issues are discussed in the follow.
In Case E the CIO pointed out that, because of the lack of management knowledge, the EA development project did
not have enough support from the management. Similarly, the CIO of Case G mentioned that, ‘because high-level
managers’ education background usually is in human sciences, they don’t have any knowledge of EA […] and they
don’t understand the benefits of EA’. Thus, they did not support the project. The Head of Systems Analysis and Design
of Case M and the CIO of Case K mentioned that, because of the constant change of management, the organisations
were faced with difficulties in developing the EA as the new management did not approve the continuation of the
previous management’s approach. So, the EA projects did not get enough support from the management. The severity
of this was mentioned by the CIO of Case K: ‘I remember that we were arguing the about 6 months with the CEO to
convince him to do the EA. There was no other option, EA had to be developed […] we had a lot of discussions with
the CEO to assure him that we could not continue doing our routine work if we wanted to reach to our goals. We
needed his approval and support; that was our biggest obstacle’. The CIO of Case E explained the constant change
of management as a ‘terrifying situation for EA development, as managers with different strategies and priorities
constantly came and went’. Furthermore, the CIO of Case B mentioned that, usually, ‘the high-level managers do not
have enough IT-related knowledge to understand the necessity of developing EA’. This situation hindered the EA
project in Case B in all the stages of development.
Regarding the personnel-resistance-to-change issue, the Business Support Manager of Case P mentioned, ‘You are
keen to like what you are used to and you are not always very open to change’. Furthermore, the Manager of E-
business and Integration of Case P also mentioned,Sometimes that is kind of hard for the people to understand and
to change the way they are used to working’; it is not ‘roses and sunshine all the timeas they encountered human
issues in the background. Also in Case K, when the personnel were told that the organisation was going to develop
EA and their tasks might change, they resisted the changes by not collaborating with the EA developers. As was
pointed out by the Head of the IT Department of Case K, ‘everyone understands the changes that are caused by EA
development, but they are not knowledgeable enough to understand how these changes will improve the maturity of
the organisation, […] and maybe this is partly because they are forced to adopt EA and consequently they show
resistance to changes’.
High-level management support seems to play a major role during EA development. The IT Manager of Case K
mentioned, ‘one of our biggest challenges was to convince the high-level manager that developing EA would be
beneficial for the organisation, […] even though the high manager says that EA is beneficial, but in practice the
manager does not fully support the project’. The high-level manager was against EA development, but the CIO and
IT Manager of the organisation tried hard to convince him and get his approval to start the EA project. However, as
they went on with the project, the manager showed less interest in the EA project, and at some point the EA
development even stopped as the high-level management refused to assign more resources to continue the project.
The CIO of Case A mentioned personnel resistance to change as an obstacle in the pre-development stage, and he
pointed out that the organisation addressed this issue by taking actions such as educating their personnel, conducting
seminars and info sessions and involving personnel in the EA development progress report meetings. Furthermore,
the CIO of Case G mentioned that, ‘During EA development, most of the personnel were concerned about losing their
jobs. We told them don’t be concerned, developing EA just means correcting our views and models; it does not mean
that someone else will get your job and you will lose your job. But still, we could see the resistance’.
The CIO of Case B mentioned that they started the EA project without considering personnel resistance to change as
an issue. They thought that developing EA was something that only managers should be concerned with, and so they
did not involve the personnel in any of the decision-making sessions or meetings regarding EA development. They
assumed that the personnel would adapt to the changes that the EA would bring to the organisation without asking
questions. So they started to develop the EA without providing any training or offering information sessions on how
EA can improve jobs while keeping them secure. But later, in the development and post-development stages, they
noticed that the personnel did not collaborate as planned and sometimes even gave ‘wrong information’ to the
architecture team. Later, in the post-development stage, there was personnel dissatisfaction regarding the changes that
EA had brought to their jobs.
15
‘Lack of motivation among personnel’ was another obstacle that hindered EA projects during the development and
post-development stages. In order to keep personnel motivated and collaborating with the EA project, the human
resource department should work efficiently to educate them beforehand about EA and its influence on their jobs and
assure them of their job security. Failing to do so brings difficulties during the EA development and post-development
stages. For instance, in Case B the personnel were forced to adopt EA without the management asking their opinion
or involving them more in the project. Thus, they lost their motivation to adapt to the new procedures brought by EA
development. In Case K the personnel lost motivation as they realised that the high-level management was not very
supportive of the EA project, and hence they did not like to get involved in it.
4.2. Issues imposed by external parties
In Cases A, F, G, I, J, L and M, ‘government-related political issues’ appeared in all stages of development. This issue
is beyond the scope of the organisations’ authorities, and it sometimes hindered the process of EA development,
especially in governmental organisations. This issue cannot be solved easily by the organisations themselves
(Banaeianjahromi and Smolander 2016a).
Confusion in governmentwas mentioned as a common obstacle in governmental organizations. Both of the CIOs
from Cases A and E mentioned that ‘the inappropriate definition of business in the governmentand confusion in the
government regarding the long term goalsaffected their EA development in the initial stages. Also political changes
of the countrywere mentioned by Cases G and J. They imposed difficulties to the organizations, for example when
the government changes. In this situation, the government changes, the cabinet will change, the industry minister will
change. Therefore, [the organization’s] boss will change’. Thus, it is so likely that the project will be terminated in
the middle.
Another obstacle that was mentioned in the two stages of development and post-development was ‘EA consultant
related issues’, which was mentioned in Cases A, B, G, I, L and N. For the organisations that outsourced their EA
development, one of the activities in the pre-development stage was to select the best EA consultant based on their
budget and the consultant’s reputation. So, in the pre-development stage, organisations usually did not have any
problems with the EA consultants, since the consultant companies showed their bright side and made promises to win
the tender. The EA consultant of Case G was inexperienced with amateur members. This situation faced the EA project
with difficulties as it tookmuch longer than expected to finish and almost failed.
According to the CIO of Case A, Lack of innovation in consultant’s teamis another EA development obstacle. The
interviewee mentioned that consultant team just wants to draw a diagram and to show that they have known and
modelled processes without bringing any innovation to the job, which results in consultant being inflexible in their
job. Further, the interviewee mentioned that sometimes EA consultants become inefficient in a way that instead of
consulting they were taking orders and acted like our employees’. EA development in this situation brought no
innovation to the organization.
‘Restricted rules in governmental organisations’ was also repeated in both the development and post-development
stages. The organisations faced rules imposed by the government that restricted their freedom in EA development,
such as rule involving changes in organisational hierarchies and roles. In governmental organisations (Cases G and J),
this obstacle was mentioned as being more influential. According to the Head of System Analysis and Design of Case
G EA development in a governmental organization is more difficult than in private organizations because of restricted
rules and laws in governmental organizations’. In governmental organizations there are managers, ministers, and
president who impose rules and restrictions on the organization’. Case J faced with a situation of laws contradicting
with the EA results. As a result of EA they realized that sales management in one of their divisions should be removed.
However, the laws of the county made this impossible.
4.3. Lack of communication and collaboration
‘Lack of communication and collaboration’ has both direct and indirect relationships with most of the other obstacles.
This obstacle repeated in all three development stages in most of the interviewed cases. In the following, we will
describe how the obstacle Lack of communication and collaborationfunctioned on a case-by-case basis.
16
Case A’s organization outsourced their EA development to an EA consulting company. The lack of communication
was clear between the high-level management and the personnel, and the little communication that existed was
characterised as formal. The personnel did not want to make a bad impression on the management because of the fear
of losing their jobs. Consequently, they did not make their opinions clear to the management. This lack of
communication caused personnel not to have enough knowledge about the ongoing projects in the organisation, and
this probably resulted in resistance to change. Furthermore, the CIO of Case A mentioned that ‘managers do not pay
attention to EA when it is needed; they prefer to do their everyday routine tasks’. The CIO pointed out that, when
high-level managers did not show support for the EA project, the ‘personnel’s performance decreased and they lost
motivation’. It was also mentioned that, when developing the EA, the ‘personnel should have reached a level of
maturity and knowledge that they could collaborate with the EA consultant and could provide accurate and correct
information about the processes’. However, they were faced with the ‘immaturity of the personnel’, which caused
delays in the data gathering and interview sessions, making these processes take ‘longer than what was expected’.
The CIO of Case A also mentioned that EA consultants sometimes did not collaborate efficiently as they were
supposed to do. The CIO of Case A pointed out, ‘Sometimes we contract with an EA consulting company, but in the
middle of the work we see that, instead of consulting, they are taking orders and acting like our employees’. It seemed
that the EA consultant had an established structure and that they were only acting based on that. ‘They have a
framework and they just want to perform it and leave’. The consultant’s ‘flexibility, agility, and innovation’, which
are determining factors in a successful EA project, did not exist. According to the CIO of Case A, ‘the [EA consultant]
must be innovative to efficiently integrate processes and create harmony and integration in architecture’.
Case B’s organization did not outsource the EA development project. However, they sometimes had an outside
consultant for various tasks. One of their biggest challenges was ‘ineffective use of human resources during EA
development’. As the CIO of Case B mentioned, they hired the wrong people for the new positions created as a part
of the EA development and failed to produce results. We also noticed an issue with communication and collaboration,
as the interviewee mentioned that the ‘personnel do not need to know about the EA project; […] they should only
adopt EA in their job’. However, this attitude did not succeed, as the personnel resisted changes and were unsatisfied
with the EA results. The CIO of Case B believed that the root of the organisation’s problem lay in their organisational
structure, as they did not have ‘an official central and powerful EA unit in [their] organisational structure that was
responsible for business processes design and re-engineering and monitoring these tasks to check the performance
and ensure the quality’.
Case C’s organization developed the EA internally without any consulting help. Having an old infrastructure,
establishing communication between different information systems and departments was challenging in the beginning
of the EA development project. The Project Manager of Case C mentioned that, because ‘employees are attached to
their desk, they think that if the processes improve they might lose their jobs’. The Project Manager continued: ‘If the
personnel do not get enough knowledge about EA development and how EA will benefit them, they will resist adopting
the EA and endanger the project’. Furthermore, the interviewee mentioned that ‘teamwork’ was an issue in his
organisation and that the personnel did not communicate or collaborate effectively during EA development. Due to
the lack of communication and collaboration in Case C, ‘the outputs provided by the EA team were not usable for the
system developer’s team. […] EA outputs were so abstract and not up to date that [they] had to interview the personnel
again to get more details that bothered both personnel and managers’.
Case D’s organization outsourced their EA development. Similar to Case C, this organisation also faced the issue of
old infrastructure in the beginning of the EA development. The IT Manager of Case D mentioned that, due to the lack
of communication and collaboration, different divisions did not know about the processes that were happening in other
divisions, and this caused problems in initiating a big project like EA development in which everyone in the
organisation should be involved. Furthermore, the interviewee pointed out that the systems were not integrated and
that the communication between systems sometimes had to be done manually, and the risks of data manipulation and
cheating were high.
Case E’s organization developed EA internally without consultants’ help. Besides the unsupportiveness of the
management, the personnel of Case E did not have enough EA knowledge, and the EA team and personnel could not
communicate efficiently. When Case E started the EA project, they were ‘assuming that the personnel of each unit
17
was working with valid data’, meaning that they knew where the data came from and exactly how they should process
the data. But they were wrong, because most of the personnel had no idea about the origin of their data, which was
caused by the lack of communication and collaboration between different units and personnel. Additionally, the
constant change of management was another obstacle that was mentioned by the interviewee as being terrifying during
the EA development project, as managers with different strategies and priorities constantly came and went.
Case G’s organization outsourced their EA development to a consulting company. The Head of Systems Analysis
and Design in Case G pointed out that the ‘academic background of the high-level managers is in social sciences’;
therefore, they did not have any knowledge of EA, IT or industry, and they could not understand the results or benefits
of EA. The high-level managers did not have enough IT knowledge, and ‘convincing them of the usefulness of adopting
EA’ for the organisation was difficult. Furthermore, the CIO of Case G mentioned that ‘it is crucial that the CIO is
directly under the CEO in order to get more support, especially for the big projects like EA development’. Afraid of
losing their jobs, the personnel sometimes ‘jeopardised’ the EA development project by ‘hiding the truth or giving
wrong information to the EA consultant. According to the Head of Business Process Development of Case G, the
personnel did not always understand what the consultants were asking from them, and the answers they provided were
sometimes unreliable or false. When errors were detected, sometimes ‘the whole thing had to be redone’. Furthermore,
the CIO of Case G mentioned that sometimes, because of lack of resources, EA development was considered to be a
‘luxury project’, and the management lost interest in allocating a budget to continue the project.
The Head of Systems Analysis and Design of Case G also mentioned that, at first, the consultant had a professional
team that knew what they were doing. However, ‘in the middle of the project, suddenly the EA consultant team
changed to an inexperienced team; […] collaboration and coordination became difficult, the project faced almost
certain failure and the consultant company hardly managed to finish the project’. Furthermore, the CIO of Case G
mentioned that ‘our contract with the [consulting company] was to develop EA in 9 months, but it took one and half
years […] because [the consulting company] was not employing experienced persons to do the job’.
Case J’s organization developed EA internally without getting help from EA consultants. The CIO of Case J believed
that outsourcing had its difficulties and that it would have taken too much time for the consulting company to become
familiar with their business. The CIO of Case J mentioned, ‘We know our organisation and this was our trump card’.
Although they knew their organisation and business, they did not have the necessary EA knowledge. They formed a
group internally and studied EA development. The CIO of Case J also mentioned that their organization had the issue
of constant change in high management due to the economic crisis. The CIO of Case J mentioned that new
management usually meant new management principles: ‘Therefore, a change in management highly affects a project
like EA that takes several years to develop in a large enterprise, and it needs constant updates and improvements’.
As in Case G, the personnel of Case J also sometimes gave false information to the EA team because they were afraid
of losing their jobs. Additionally, Case J recently merged with other organisations, and they still were not able to unify
their organisation. Organizations involved in the merger were also acting competitively toward each other. This
situation made the EA development harder as the merged organisations did not like to collaborate or communicate
with each other.
Case K’s organization developed EA internally without any external consultancy. According to the CIO of Case K,
getting the CEO’s approval to start the EA development project was the biggest obstacle’. As the CEO did not have
any EA knowledge, he did not want to get involved or spend resources on the EA project. The CIO of Case K
mentioned, ‘I remember that we were arguing for about 6 months with the CEO to convince him to do the EA; there
was no other option, EA must be developed. […] We had a lot of discussions with the CEO to assure him that we could
not continue doing our routine work. If we wanted to reach to our goals, we needed his approval and support. That
was our biggest obstacle’. Because of the CEO’s lack of knowledge about EA, he was not eager to collaborate during
the project or provide the required resources. Thus, the communication and collaboration between the mid-level
managers and the CEO was not at a desirable level during EA development. Lack of personnel motivation was another
issue during the EA development project, as the CIO of Case K mentioned: ‘Sometimes the employee is in a good
spirits and the project progresses very well, but sometimes the employee is not motivated, and then even continuing
the project seems difficult’ The results of the EA project included project proposals in order to reach the target
18
situation, and according to the CIO of Case K, they did not benefit from all of the EA results because they did not
have enough knowledge or innovation to carry out the proposed projects.
Case L’s organization outsourced their EA development to a consulting company. According to the IT Manager of
Case L, they had a small IT team, and the IT department was weak. The team did not have much EA knowledge: ‘they
had heard about EA and now they wanted to have it without knowing what it was’. In this situation, communication
and collaboration between the organisation’s personnel and the EA consultant team was difficult, as they could not
understand each other. Furthermore, as the management of the organisation changed constantly during the EA
development project, new managers were not supportive of the project.
Several problems hindered the communication between the EA consultant and the company in the middle of the
project. According to the IT Manager of Case L, one of the problems was that ‘the organisation couldn’t pay [the
consultant’s] wages on time, and it affected the EA project. […] The consultant’s performance reduced’. Furthermore,
in the middle of the EA project, the company and the EA consultants were ‘arguing about some issues that affected
their communication, and the company did not like to cooperate with the EA consultant’. Also, on the consultant’s
side, some people left the team, which practically halted the EA project.
Case M’s organization developed EA internally without external consultants. Some of the IT personnel received EA
education. According to the Head of Systems Analysis and Design of Case M, ‘managers do not really know what EA
is, they just say that they must have it, but in practice they do not support the project’. Furthermore, Case M’s
management changed several times during EA development, and some of the managers were against developing EA
because of their lack of knowledge about EA and also the budget. Case M did not develop all of the EA results because
the management changed constantly and, sometimes, a project terminated in the middle because the new manager did
not want the project to continue. The Head of Systems Analysis and Design of Case M mentioned that, for ‘the survival
of projects such as EA development, which involves the whole organisation and takes more time to finish, it is crucial
to choose someone from inside of the organisation who knows about the business and background of the organisation
as a manager’.
The Head of Systems Analysis and Design of Case M also mentioned that, although the personnel of each unit knew
what was going on in their units, , they did not know ‘the effect that a change would have on other units; [they] could
not align [themselves] with each other’. This was because of a lack of communication and collaboration between
different units. In this situation, developing EA was a tough task as there was a lack of knowledge of the effects and
interdependencies between the units.
4.4. Causes and effects of lack of communication and collaboration in EA
development
In this section, we explain about the causes and effects of lack of communication and collaboration in EA development
that presented in Figure 4. During selective coding we identified six additional items that hinder communication and
collaboration in EA development.
The organizational culture turned out to be an issue that influence communication and collaboration in EA
development. In Cases B and G personnel got used to old procedures and therefore they did not like to change their
habits and they resisted to change and jeopardized the EA project by giving wrong information to the EA team.
Moreover, different cultures in different departments and divisions caused communication and collaboration issues.
For example the CIO of Case J mentioned that ‘[…] the organizational culture in [division x] was very different from
the culture of [division y]. During EA development different culture of divisions caused difficulties as personnel in
[division y] did not believe in the positive changes that EA development brings […]’. Furthermore, the CIO of Case J
mentioned that division y still resists to the changes that are happening as the result of EA development, ‘[…] because
EA has reduced their independency in decision making and they were not motivated at all to collaborate with us. The
difference in organizational culture between divisions in Case J was obvious as division y was merged with the
organization few years ago.
19
Case I started five years ago to develop EA with the help of an EA consultant from another country but due to several
organizational and political reasons their collaboration failed and later they continued to develop EA internally. The
CIO of Case I pointed out that ‘[…] although our collaboration with the foreign EA consultant was unsuccessful but
the positive point of this effort was that our organizational culture changed and the road to develop EA in future was
facilitated as we succeeded at that time to reach to a common point between different units that we need EA to be
developed’. Case I’s initial unsuccessful EA development attempt affected the organizational culture and triggered
their motivation to continue EA development internally.
Being clear about the EA development process is one of the requirements of EA development that most organizations
stated in the pre-development but gradually this clarity faded away in the development phase. For example, Case B
started to develop EA without explaining to the personnel about what is EA and how it will affect their jobs and how
they are going to develop it. Consequently Case B was not able to gain their personnel’s trust which results in personnel
dissatisfaction. Also in Case A we understood the issue of clarity during their EA development caused by EA
consultant. The interviewee mentioned that ‘sometimes it seemed that the EA consultant did not want us to know how
they are progressing or what steps they are taking to develop EA […] because they wanted us to be dependent on
them in future […]’. In such a situation the personnel lost their trust and collaboration with the EA consultant became
difficult.
Losing personnel’s trust is one of the effects of lack of communication and collaboration in EA development. Clarity
and trust are associated with each other. According to the CIO of Case K ‘It is important to be clear about the steps
that we are going to take during EA development and being able to explain it to the personnel so that personnel can
accept changes easier. If personnel does not understand why he/she has to answer to the detail questions about his/her
job, the employee will feel threatened and not collaborate well. Thus, Case K arranged several meetings and
educational seminars to make sure that employees understand the positive effects of EA on their jobs and everyone
has a common understanding of EA. Same thing also happened in Case J. They conducted several seminars, and
meetings before starting EA development for their personnel to explain to them about EA development in their
organization and gain their trust to facilitate their resistance to change. In Case G the personnel was worried about
losing their jobs as they did not trust their managers who tried to ensure them about their job security. The personnel
tried to jeopardize the EA development project by giving wrong information to the EA team. Furthermore, we also
realized that when management shows its support towards EA development project it will influence the personnel’s
trust.
To remain competitive is one of the EA development goals. Before initiating EA development in Case J, the company
studied how their competitors have developed EA and what were their results and how EA could benefit the
organization. Through benchmarking and best practices they tried to imitate the big successful companies in the same
industry. In Case A the issue of lack of innovation in EA consultant’s team was an obstacle (explained in sections 4.2
and 4.3). Case L wanted to remain competitive and be among the best in their industry. They decided to develop EA
to improve their business process, bring innovation to the organization and compete with their competitors. However,
due to the constant change of management and lack of management support in Case L, people lost their motivation to
collaborate with the project and consequently no innovation occurred in the organization and the organization lost its
competitive edge as time passed.
Ineffective EA outputs also hinders the organization’s competitiveness. For example in Case M the result of EA
development was not effective for the organization because the documents produced by the EA team were not
understandable by developers. This situation hindered the organization’s competitiveness as they were not able to
continually improve their business. For example, when a new integration project initiated in the organization, the
integration team was not able to properly identify the project requirements. One of the reasons was that documents
which were produced as part of the EA development outcome were not understandable and utilizable by the integration
team. This situation caused the integration project to take more time than what was planned and increased the risk of
customers’ dissatisfaction.
The EA governance was endangered in Case B as their organizational structure had deficiencies. Case B did not have
a central powerful EA unit defined in their organizational structure. There was no governance on their business process
design and re-engineering to check and monitor their performance and quality. Similarly, in Case G there was no unit
20
defined in their organization that would have been responsible for EA governance and therefore EA was not effective
in the organization. We understood that EA must be defined on the highest level of the organization management in
order to be effective and successful.
4.5. Findings from organizational documents
Identifying ‘Lack of communication and collaboration’ as the core obstacle during EA development projects, we
contacted the interviewees via email to seek more information. In this third round of data collection, we sent an email
to the interviewees requesting their EA documents in order to look for new information about anything related to
communication and collaboration. Out of 14 organisations from second round of data collection, five organisations
(Cases A, G, I, K and L) answered, and we received nine documents (329 pages) regarding the EA development
projects. Using the open coding technique (Strauss and Corbin 1998), we analysed the organisational documents,
specifically looking for indications of communication and collaboration during EA development.
The documents showed that an architect plays a major role in EA development and maintenance. The organisations
considered architects to be persons who should be able to predict an organisation’s needs, resources and priorities
before anyone else. The documents also suggested that architects should coordinate between the business and the IT
team. Thus, architects play a major role in establishing communication and providing coordination between the
business and the IT team.
The documents suggested that one of the major goals of the EA in the organisations was to improve collaboration and
communication. However, having communication and collaboration problems before starting EA development
seemed to lead to several obstacles in the EA development process itself. The documents provided by Case A
expressed this issue explicitly and showed that 35% of their problems were rooted in organisational and
communication issues, such as resistance to change, deficiency in organisational structure, constant change in policies
from upstream, lack of communication and collaboration between departments and lack of standardization in project
plans.
4.6. Summary of findings
Table 3 summarizes the steps that we took in this study and the results that we obtained. In the first round we focused
on the enterprise integration issues and asked some general questions about EA development in those organizations.
We identified lack of communication and collaboration as a major issue in EA development. This finding led us to
the next phase of data collection focusing on the obstacles in EA development based on three development stages.
In the second round we focused on EA obstacles in different EA development stages. We understood that the obstacles
remain through EA development stages if they are not addressed properly in the initial stage of development. We
followed the relationships between different obstacles and identified lack of communication and collaboration as the
core obstacle that can explain most of the other obstacles. We revisited the data and investigated the causes and effects
of lack of communication and collaboration in EA development. The research process and its findings are summarized
in Table 3.
Table 3 Overview of research process and findings
Data
analysis/collection
Focus of the study
Results
Data collection and
analysis from first
round of interviews
Focused more on enterprise
integration issues and asked
general questions about EA
in the organizations
- Lack of collaboration as a major issue in EA development
- The obstacles remain even after EA development
Data collection and
analysis from second
round of interviews
Focused on EA obstacles in
different development
stages to understand the
reasons behind the
inefficiency of architectural
descriptions
- Identifying obstacles in different EA development stages
- EA obstacles remain through EA development stages if they are not
addressed properly in the initial stage of development
- Understanding the relationships between EA obstacles
- Determining lack of communication and collaboration as the core
obstacle that can explain other obstacles
21
- Revisiting the data
(first and second
round of interviews)
- Data collection and
analysis from
organizational
documents
Focus on communication
and collaboration during EA
development
- Revealing organizational culture and clarity in EA development
process as additional causes of lack of communication and
collaboration in EA development.
- Revealing ‘personnel’s distrustand ‘organization loses its
competitive edgeas other effects of lack of communication and
collaboration in EA development.
- Improving communication and collaboration as one of the main
goals of EA development
- Enterprise architect has a significant role in enhancing
communication and collaboration during EA development
5. Discussion
This study contributes to the field of EA research and practice. Our work focused on the obstacles that practitioners
experienced during EA development. Our contribution provides an empirical foundation for EA development
obstacles and emphasises the importance of communication and collaboration. A lack of communication and
collaboration may also explain other EA obstacles. Thus, organisations should solve their communication and
collaboration issues before embarking on EA development initiatives. Lack of knowledge and support inside
organization as well as issues imposed by external parties are three general obstacles that hinder communication and
collaboration in EA development. Furthermore, organizational culture, personnel’s motivation, and clarity in EA
development process are among several causes of lack of communication and collaboration. Personnel’s (dis)trust,
endangered EA governance, lack of innovation, organization losing its competitive edge, ineffective EA outputs, and
unable to set common goals and achieve a shared understanding are the effects of lack of communication and
collaboration in an EA development project.
5.1. Relation to earlier research
Communication and collaboration have always been challenging in organisations. Yuhashi and Iijima (2010) define
communication as ‘the interactive processes employed by human beings in order to communicate their psychological
content (including knowledge, emotions and will) between one another, using symbols such as body language, words,
text, images, and so on, as mediational means’. Collaboration can be defined as ‘an activity that leads to an emergent
result, which takes place alongside an act of communication within a group that has a mutually beneficial
relationship’ (Yuhashi and Iijima 2010). Collaboration is also referred to as lasting relationships and a strong
commitment to a common goal (Kvan 2000). According to Yuhashi and Ijima (2009), communication precedes
collaboration, or as Evans and Wolf (2005) mention, communication creates an organisation in which it is easy to
produce collaboration.
It is believed that ‘Communication calls organisation into being’ (Bisel 2009a). According to Bisel (2009a),
organisations are not fixed and stable but are rather called into being by interacting and sensemaking persons who
attempts to coordinate their behaviours to accomplish goals, meaning that organisations function through members’
communication and sensemaking. Furthermore, empirical observations indicate that poor workplace talk causes
inefficiencies, errors, and an inability to interact (Bisel 2009b). Among organisational communication scholars, the
above explanations are called the communicative constitution of organisations (CCO) theory (Bisel 2009a) . This
theory emphasizes the importance of communication in organisations.
Our findings share commonalities with the earlier findings (Armour and Kaisler 2001; Kaisler, Armour, and
Valivullah 2005; Bricknall et al. 2006; Hjort-Madsen 2006; Kappelman and Zachman 2013) that highlighted the
importance of communication and collaboration in EA development. Armour and Kaisler (2001) and Kaisler, Armour,
and Valivullah (2005) mention communication networks as one of the main components that architects require in
order to communicate with others and with systems, and failing to establish this communication is a challenge in an
EA effort. Bricknall et al. (2006) also mention communication as an important and necessary component in EA
implementation. A successful EA implementation requires constant communication and cooperation across different
levels and functions in an organization (Hjort-Madsen 2006). The importance of communication is also emphasized
by Kappelman and Zachman (2013), who concluded that ‘the enterprises that survive and thrive in the next few
22
generation will consist of people able to communicate efficiently and effectively in order to quickly achieve a shared
vision[…]’.
The impact of cultural diversity on the effectiveness of EA has been studied by Faller and De Kinderen (2014). Their
study indicated that communication defects are an important intermediary factor between an organisational subculture
and the EA function’s effectiveness. This complies with our finding that organizational culture is one of the causes of
a lack of communication and collaboration in EA development. In their previous study, Niemietz, De Kinderen, and
Constantinidis (2013) identified three levels of communication defects in EA-guided enterprise transformations: lack
of communication, inappropriate communication and over-communication (Niemietz, De Kinderen, and
Constantinidis 2013). Furthermore, a lack of EA effectiveness is partly because of the problematic interaction between
architects and other stakeholders. Establishing shared understanding among diverse organisational communities
during EA-driven enterprise transformation enables and supports collaborative efforts (Abraham, Aier, and Winter
2015; Bisel and Barge 2010; Nicolini, Mengis, and Swan 2012; Stensaker, Falkenberg, and Grønhaug 2008). Based
on our findings, lack of common understanding among EA stakeholders can be associated with their trust and
dissatisfaction in EA development, which are the effects of lack of communication and collaboration. According to
Abraham et al. (2013), communication is a key success factor in coordinating collaborative efforts during EA-driven
enterprise transformation.
Löhe and Legner (2014) studied EA implementation challenges to develop a design theory for overcoming the
implementation challenges in EA. They identified a number of EA implementation challenges, including old and low-
quality documents, low usage of existing EA artefacts, a lack of EA acceptance in the organisation and coordination
problems. However, as they focused only on the information technology (IT)-driven EA perspective, their design
theory may not be able address EA development challenges beyond the four challenges they identified. In another
study about issues that organisations face while documenting EA, Roth et al. (2013) studied the key EA challenges
that organisations face during EA development. Besides the bad quality of EA model dataas one of the key
challenges, other challenges that they found comply with our list of obstacles. For instance, data collection, insufficient
tool support and no management support have similarities with our findings.
Based on a literature review Lucke, Krell and Lechner (2010) studied the critical issues in enterprise architecting and
created a list of EA challenges. Our findings can be considered an extension of this list. Similarly, we found insufficient
management commitment, a lack of communication and collaboration, difficulty in establishing a common
understanding, a lack of experienced architects, complexity, a rapidly changing environment, a lack of knowledge and
insufficient tool support to be obstacles in EA development.
Jahani, Reza Seyyed Javadein and Abedi Jafari (2010) studied effective factors in evaluating EA readiness, and they
included a list of EA obstacles that complies with our findings. They concluded that because EA is a continuous and
permanent programme in organisations, it is crucial that organisations be aware of their weaknesses before embarking
on EA. This aligns with our findings. We also posited that organisations should address their communication and
collaboration issues before starting EA projects. Van der Raadt et al. (2010) studied the relationship between EA
effectiveness and stakeholder satisfaction with a case study. Their findings align with ours, that active participation
and communication between EA stakeholders is one of the main critical success factors for EA.
Based on empirical data and literature, Ylimäki (2008) proposed a list of critical factors for EA. She referred to
communication as an important means of gaining commitment to an EA effort. This complies with our finding that
management support and personnel’s commitment and trust is a result of good communication and collaboration in
the organisation. Similarly, Chuang and van Loggerenberg (2010) studied the challenges in enterprise architecting
using qualitative data. They considered communication issues to be one of the biggest challenges. They further divided
communication during EA development into internal communication and communication with stakeholders.
Our findings share commonalities with the findings of Nakakawa, Bommel and Proper (2010), who studied the
challenges of involving stakeholders when creating EA. Considering collaboration to be a core thread in EA
development, Nakakawa, Bommel and Proper (2010) studied factors that hinder effective collaboration. Time,
organisation politics, a lack of communication, a lack of common understanding, a lack of architecture governance, a
lack of the architect’s knowledge, a constrained project budget and a lack of documentation are factors hindering
23
collaboration. Successful EA development requires planning, training and communication along with other elements,
and training should be carried out not only during development but also in the EA initiatives (Bricknall et al. 2006).
This aligns with our findings, which emphasised the importance of communication and collaboration and of training
EA stakeholders before EA development begins.
In this paper, we have divided the EA development process into the three stages of pre-development, development
and post-development. Based on our definitions of these three development stages the majority of earlier research on
EA development obstacles focused only on the development stage of the process (Chuang and van Loggerenberg
2010; Hauder et al. 2013, 2013; Löhe and Legner 2014; Nakakawa, Bommel, and Proper 2010; Nikpay et al. 2013;
Seppänen, Heikkilä, and Liimatainen 2009; Van der Raadt et al. 2010; Ylimäki 2008), along with a few studies on the
pre-development stage (Jahani, Reza Seyyed Javadein, and Abedi Jafari 2010; Lucke, Krell, and Lechner 2010). In
this study, we extended the body of knowledge by also identifying pre-development and post-development EA
obstacles and increased the understanding of EA obstacles in the three stages of development.
Comparing our findings with the previous research in this area we understood that:
(1) Organizational culture influences personnel’s motivation in EA development.
(2) Clarifying the EA development process to the personnel will result in their trust and collaboration.
(3) Instability of the organization, which is caused by constant change of management and their lack of support
causes the personnel to lose their motivation to collaborate with the EA project. Consequently, the
organization faces with lack of innovation and loses its competitive edge.
(4) EA must be defined on the highest level in the organization in order to be successful and effective.
(5) It is crucial that organizations address their communication and collaboration issues before initiating EA
development, because obstacles, such as lack of communication and collaboration will remain through all
the development stages and constantly hinder the project.
5.2. Recommendations to improve communication and collaboration in EA
development
This section provides recommendations for practitioners to improve communication and collaboration in EA
development. The current way of communication and collaboration should be reconsidered before initiating an EA
development project, since the major part of EA development is about communication and collaboration between
different stakeholders. However, some of the obstacles, such as organizational culture or the issues that are caused by
government cannot be easily addressed.
Be clear and precise about EA development process to increase personnel’s trust. One of the reasons that
employees resist to collaborate with the EA project is because they feel threatened and insecure about their job and
the reassurances by managers are not sufficient. Lack of personnel’s knowledge about EA is also a major reason for
the resistance to collaborate. Employees may be told that EA will improve their job and they have to collaborate with
the EA team. However, based on our findings things do not progress as expected. Sometimes personnel gave wrong
information to the EA team intentionally because they were thinking that if they give all the information about their
tasks and jobs they will lose their job. Improve personnel’s knowledge in educational seminars and courses could add
trust and reduce resistance. It is important that the EA team can clarify the EA development processes and steps,
benefits, and effects for each employee before initiating EA. Each employee should understand the benefits that he/she
will get from EA development and what are the challenges of not adopting EA.
Motivate personnel to communicate and collaborate in order to bring innovation to the EA development.
Organisations should be able to motivate and encourage their personnel to become more cooperative with the project
and EA consultants. According to Boster, Liu and Thomas (2000), motivation is a big part of an EA effort. Individuals
and organisations will not adopt changes unless they are encouraged. A strong leader can increase personnel’s
motivation through communication and collaboration. Employees will become motivated to embrace an EA project
when they see that their manager is supportive of and involved in it. Also, if personnel have enough knowledge about
24
the process of EA development and how EA can positively influence their jobs, they will become motivated to
collaborate as part of the project as well.
EA must be placed on the highest level of the organization. To become successful in EA development, EA must
be positioned on the highest level of organization. The decisions related to the EA should be directly come from the
high-level management of the organization, with the full support of the management. EA should not be defined only
as a part of IT or business departments. Issues related to the EA development should be discussed directly with the
high-level management without any mediators.
EA team should consist of not only EA experts but also non-EA expert people from other departments. If EA
is developed only by EA experts, it may be difficult to understand by the other people in the organization who are not
experts in the models and documents produced by EA experts. For instance, in one of our cases after the EA expert
team developed EA, the result was not very useful, because the IT people could not understand the documentation. It
is not necessary to use a specific well-known methodology in EA development to be successful. It is important to use
descriptions that are understandable by the majority of the organization. It could be useful to have at least one people
from each department of the organization in the EA team.
5.3. Limitations
This study has limitations. One of the limitations is the limited number of individuals interviewed. The study would
be more reliable if we had more cases. Another limitation is that the cases from the second and third rounds of data
collection were selected from one country, and some of the mentioned obstacles may not apply to another country.
Obstacles such as the government-related political issues and restricted rules in governmental organisations might not
appear as obstacles in other countries’ large organisations. Another limitation of this study is the limited number of
gathered organizational documents. We got only nine EA-related documents from five out of 17 organizations.
Therefore, we were not able to double-check the interviewees’ statements with what had actually been documented
during their EA development. The documents that we received from the five organizations (Cases A, G, I, K and L)
revealed more information and increased our understanding about the process of EA development in those cases. For
example, in Cases A, G and L that outsourced their EA development, the documents revealed how EA was developed
from the EA consultant perspective.
Moreover, we investigated only large enterprises. Meanwhile, EA development obstacles in medium-sized or small
organisations may not be the same, as these organisations are less complex. Furthermore, all of the interviewees were
from the management levels of their organisations. Having other stakeholders’ perspectives, such as those of EA
consultants and personnel, could clarify and explain some issues. Therefore, the generalisation of these results should
be made with caution.
6. Conclusions and future research
In this study, we identified EA development obstacles in 15 organisations. We investigated the obstacles that kept
appearing in the different stages of EA development: pre-development, development and post-development. By
looking at cause-effect relationships and dividing EA development into the three stages of pre-development,
development and post-development, we further analysed the obstacles and their repetitions. We pointed out that lack
of communication and collaboration is the core obstacle that could explain other obstacles. Lack of knowledge inside
organization, lack of support inside organization and issues imposed by the external parties were identified as the
general obstacles that can be both causes and effects to the lack of communication and collaboration. Further
investigation of causes and effects of lack of communication and collaboration revealed organizational culture as an
important issue in communication and collaboration during EA development. Organizational culture effects people’s
motivation to persuade them to communicate and collaborate actively. Clarity in the process of EA development will
improve common understanding in the organization, which may consequently increase trust and satisfaction among
employees and motivate them to communicate and collaborate better in EA development.
To reduce issues in EA development, organisations should at least address their existing communication and
collaboration problems before starting EA development. An architect plays a major role in facilitating communication
25
and collaboration in an EA development project. We provided four recommendations to facilitate communication and
collaboration in EA development. Being clear and precise about the EA development process will increase personnel’s
trust and satisfaction. Organizations should be able to motivate personnel to communicate and collaborate in order to
bring innovation to the EA development. EA must be placed on the highest level of organization and the decisions
related to the EA must be discussed and approved by the highest level of organization, meaning that EA should have
the high management support and attention all the time. EA development team should consist of EA experts as well
as non-EA experts across the departments of an organization.
Our findings partly converge with the existing literature but also increase the understanding of the obstacles that
practitioners face in EA development. The recommendations made in this paper can help practitioners in facilitating
communication and collaboration in EA development. The findings of this study not only contribute to the field of
EA but also can be useful in the context of complex information systems projects in large enterprises. In turn, this
study advances the theoretical and empirical understanding of EA development obstacles. This benefits both academia
and industry by providing an accurate and pragmatic perspective on EA development.
In the future, we will expand the scope of this study to get other stakeholders’ perspectives as well. We will specifically
focus on communication and collaboration among the different stakeholder groups involved in EA development. Also,
as enterprise integration is one of the most desired goals of EA development, it is important to study the role of
integration in relation to EA development. Further research is required to provide a better answer to the question how
to mitigate the effects of lack of communication and collaboration in EA development. Also the question of how to
improve communication and collaboration in EA development deserves a further inquiry.
References
Abraham, Dipl-Wirtsch-Inf Ralf, Stephan Aier, and Robert Winter. 2015. ‘Crossing the Line: Overcoming Knowledge
Boundaries in Enterprise Transformation’. Business & Information Systems Engineering 57 (1): 313.
Abraham, Ralf, Hella Niemietz, Sybren De Kinderen, and Stephan Aier. 2013. ‘Can Boundary Objects Mitigate
Communication Defects in Enterprise Transformation? Findings from Expert Interviews.’ In EMISA, 2740.
Alaeddini, Morteza, and Sepideh Salekfard. 2013. ‘Investigating the Role of an Enterprise Architecture Project in the
Business-IT Alignment in Iran’. Information Systems Frontiers 15 (1): 6788.
Armour, Frank, and Stephen Kaisler. 2001. ‘Enterprise Architecture: Agile Transition and Implementation’. IT
Professional 3 (6): 3037.
Armour, J., Stephen H. Kaisler, and Simon Y. Liu. 1999. ‘Building an Enterprise Architecture Step by Step’. IT
Professional 1 (4): 3139.
Bacon, C. James, and Brian Fitzgerald. 2001. ‘A Systemic Framework for the Field of Information Systems’. ACM
Sigmis Database 32 (2): 4667.
Banaeianjahromi, Negin, A. Alanne, K. Smolander, and others. 2016. ‘Integration Obstacles During ERP
Development’. In 2016 49th Hawaii International Conference on System Sciences (HICSS), 46974706.
IEEE. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7427769.
Banaeianjahromi, Negin, and Kari Smolander. 2016a. ‘Understanding Obstacles in Enterprise Architecture
Development’. In ECIS 2016.
———. 2016b. ‘What Do We Know about the Role of Enterprise Architecture in Enterprise Integration? A Systematic
Mapping Study’. Journal of Enterprise Information Management 29 (1): 140–64. doi:10.1108/JEIM-12-
2014-0114.
Bernaert, Maxime, Geert Poels, Monique Snoeck, and Manu De Backer. 2016. ‘CHOOSE: Towards a Metamodel for
Enterprise Architecture in Small and Medium-Sized Enterprises’. Information Systems Frontiers 18 (4): 781
818. doi:10.1007/s10796-015-9559-0.
Bernus, Peter, and Ovidiu Noran. 2010. ‘A Metamodel for Enterprise Architecture’. In Enterprise Architecture,
Integration and Interoperability, edited by Peter Bernus, Guy Doumeingts, and Mark Fox, 5665. IFIP
Advances in Information and Communication Technology 326. Springer Berlin Heidelberg.
http://link.springer.com/chapter/10.1007/978-3-642-15509-3_6.
26
Bisel, Ryan S. 2009a. ‘A Communicative Ontology of Organization? A Description, History, and Critique of CCO
Theories for Organization Science’. Management Communication Quarterly.
http://mcq.sagepub.com/content/early/2009/12/03/0893318909351582.full.pdf.
———. 2009b. ‘On a Growing Dualism in Organizational Discourse Research’. Management Communication
Quarterly. http://mcq.sagepub.com/content/early/2009/02/03/0893318908331100.short.
Bisel, Ryan S., and J. Kevin Barge. 2010. ‘Discursive Positioning and Planned Change in Organizations’. Human
Relations, 0018726710375996.
Boster, Mark, Simon Liu, and Rob Thomas. 2000. ‘Getting the Most from Your Enterprise Architecture’. IT
Professional 2 (4): 4351.
Boucharas, V., M. van Steenbergen, S. Jansen, and S. Brinkkemper. 2010. ‘The Contribution of Enterprise
Architecture to the Achievement of Organizational Goals: A Review of the Evidence’. In Trends in
Enterprise Architecture Research, 70:115. Springer Berlin Heidelberg.
Bowen, Glenn A. 2008. ‘Naturalistic Inquiry and the Saturation Concept: A Research Note’. Qualitative Research 8
(1): 13752. doi:10.1177/1468794107085301.
Bricknall, Richard, Gunilla Darrell, Hans Nilsson, and Kalevi Pessi. 2006. ‘Enterprise Architecture: Critical Factors
Affecting Modelling and Management.’ In ECIS, 2349–2361.
http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1064&context=ecis2006.
Bucher, Tobias, Ronny Fischer, Stephan Kurpjuweit, and Robert Winter. 2006. ‘Enterprise Architecture Analysis and
Application. An Exploratory Study’. In EDOC Workshop TEAR.
https://www.alexandria.unisg.ch/publications/230014.
Chen, David, Guy Doumeingts, and François Vernadat. 2008. ‘Architectures for Enterprise Integration and
Interoperability: Past, Present and Future’. Computers in Industry, Enterprise Integration and Interoperability
in Manufacturing Systems, 59 (7): 64759. doi:10.1016/j.compind.2007.12.016.
Chuang, Cheng-Hui, and J. van Loggerenberg. 2010. ‘Challenges Facing Enterprise Architects: A South African
Perspective’. In 2010 43rd Hawaii International Conference on System Sciences (HICSS), 110.
doi:10.1109/HICSS.2010.449.
Chung, Lawrence, Hyun-Kyung Song, Yeong-Tae Song, and Nary Subramanian. 2009. ‘Understanding the Role of
Enterprise Architecture towards Better Institutionalization’. In Software Engineering, Artificial Intelligences,
Networking and Parallel/Distributed Computing, 2009. SNPD’09. 10th ACIS International Conference On,
316320. IEEE. http://ieeexplore.ieee.org/abstract/document/5286648/.
Corbin, Juliet M., and Anselm Strauss. 1990. ‘Grounded Theory Research: Procedures, Canons, and Evaluative
Criteria’. Qualitative Sociology 13 (1): 321.
Corbin, Juliet, and Anselm Strauss. 2008. Basics of Qualitative Research: Techniques and Procedures for Developing
Grounded Theory. 3rd Edition. London: Sage.
———. 2014. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. Sage
Publications.
http://books.google.com/books?hl=en&lr=&id=MaKWBQAAQBAJ&oi=fnd&pg=PP1&dq=the+basics+of
+qualitative+research&ots=QrC9vMd-N0&sig=Q4o-Uz1kRu4zbZTHDDH0fmkrK1U.
Duchscher, Judy E. B., and Debra Morgan. 2004. ‘Grounded Theory: Reflections on the Emergence vs. Forcing
Debate’. Journal of Advanced Nursing 48 (6): 605–12. doi:10.1111/j.1365-2648.2004.03249.x.
Easterbrook, Steve, Janice Singer, Margaret-Anne Storey, and Daniela Damian. 2008. ‘Selecting Empirical Methods
for Software Engineering Research’. In Guide to Advanced Empirical Software Engineering, 285311.
Springer. http://link.springer.com/10.1007/978-1-84800-044-5_11.
Erol, Ozgur, Brian J. Sauser, and Mo Mansouri. 2010. ‘A Framework for Investigation into Extended Enterprise
Resilience’. Enterprise Information Systems 4 (2): 111–136.
Evans, Philip, and Bob Wolf. 2005. ‘Collaboration Rules’. IEEE Engineering Management Review 33 (4): 5057.
Faller, Hella, and Sybren De Kinderen. 2014. ‘The Impact of Cultural Differences on Enterprise Architecture
Effectiveness: A Case Study’. In 8th MCIS Conference, Verona, Italy, 3-5 September 2014.
http://orbilu.uni.lu/handle/10993/18157.
Fatolahi, Ali, Shahram Jalalinia, Zahra Dabestani, and Masoumeh Eskandari. 2007. ‘Extracting Business Process
Decomposition: A Practical Approach Using the ISIran V Methodology’. Business Process Management
Journal 13 (2): 214222.
Foorthuis, Ralph, Marlies van Steenbergen, Sjaak Brinkkemper, and Wiel A. G. Bruls. 2016. ‘A Theory Building
Study of Enterprise Architecture Practices and Benefits’. Information Systems Frontiers 18 (3): 54164.
doi:10.1007/s10796-014-9542-1.
27
Foorthuis, Ralph, Marlies van Steenbergen, Nino Mushkudiani, Wiel Bruls, Sjaak Brinkkemper, and Rik Bos. 2010.
‘On Course, but Not There Yet: Enterprise Architecture Conformance and Benefits in Systems
Development.’ In ICIS, 110.
https://tunguska.home.xs4all.nl/Publications/Docs/EA%20Conformance%20and%20Benefits%20in%20Sy
stems%20Development%20(ICIS%202010)%20-%20Foorthuis%20et%20al.pdf.
Glaser, Barney G., and Anselm L. Strauss. 1967. The Discovery of Grounded Theory: Strategies for Qualitative
Research. Transaction Publishers.
http://books.google.com/books?hl=en&lr=&id=rtiNK68Xt08C&oi=fnd&pg=PP1&dq=The+Discovery+of+
Grounded+Theory,&ots=UVvSTkXLWO&sig=MzcNz8FcLGSiZTPYUwLK0o55eoA.
Goethals, Frank G., Monique Snoeck, Wilfried Lemahieu, and Jacques Vandenbulcke. 2006. ‘Management and
Enterprise Architecture Click: The FAD(E)E Framework’. Information Systems Frontiers 8 (2): 67–79.
doi:10.1007/s10796-006-7971-1.
Goldkuhl, Göran, and Stefan Cronholm. 2010. ‘Adding Theoretical Grounding to Grounded Theory: Toward Multi-
Grounded Theory’. International Journal of Qualitative Methods 9 (2): 187–205.
doi:10.1177/160940691000900205.
Guillemette, Manon G., and Guy Paré. 2012. ‘Toward a New Theory of the Contribution of the IT Function in
Organizations’. Mis Quarterly 36 (2): 529551.
Haki, Mohammad Kazem, Christine Legner, and Frederik Ahlemann. 2012. ‘Beyond EA Frameworks: Towards an
Understanding of the Adoption of Enterprise Architecture Management.’ In ECIS, 241.
http://www.researchgate.net/profile/Mohammad_Kazem_Haki/publication/271762576_Beyond_EA_Frame
works_towards_an_Understanding_of_the_Adoption_of_Enterprise_Architecture_Management/links/54d2
19b30cf25ba0f0425887.pdf.
Hauder, Matheus, Sascha Roth, Christopher Schulz, and Florian Matthes. 2013. ‘An Examination Of Organizational
Factors Influencing Enterprise Architecture Management Challenges.’ In ECIS, 175.
http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1398&context=ecis2013_cr.
Henderson, John C., and Natarajan Venkatraman. 1993. ‘Strategic Alignment: Leveraging Information Technology
for Transforming Organizations’. IBM Systems Journal 32 (1): 416.
Hiekkanen, Kari, Janne J. Korhonen, Jussi Collin, Elisabete Patricio, Mika Helenius, and Juha Mykkanen. 2013.
‘Architects’ Perceptions on EA UseAn Empirical Study’. In Business Informatics (CBI), 2013 IEEE 15th
Conference On, 292–297. IEEE. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6642890.
Hjort-Madsen, Kristian. 2006. ‘Enterprise Architecture Implementation and Management: A Case Study on
Interoperability’. In System Sciences, 2006. HICSS’06. Proceedings of the 39th Annual Hawaii International
Conference On, 4:71c–71c. IEEE. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1579432.
Hoogervorst, Jan. 2004. ‘Enterprise Architecture: Enabling Integration, Agility and Change’. International Journal of
Cooperative Information Systems 13 (03): 213233.
Huysmans, Philip, and Jan Verelst. 2013. ‘Towards an Engineering-Based Research Approach for Enterprise
Architecture: Lessons Learned from Normalized Systems Theory’. In International Conference on Advanced
Information Systems Engineering, 5872. Springer. http://link.springer.com/chapter/10.1007/978-3-642-
38490-5_5.
Isomäki, Hannakaisa, and Katja Liimatainen. 2008. ‘Challenges of Government Enterprise Architecture Work
stakeholders’ Views’. In Electronic Government, 364374. Springer.
http://link.springer.com/chapter/10.1007/978-3-540-85204-9_31.
Iyamu, Tiko. 2009. ‘The Factors Affecting Institutionalisation of Enterprise Architecture in the Organisation’. In
Commerce and Enterprise Computing, 2009. CEC’09. IEEE Conference On, 221225. IEEE.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5210794.
Jahani, Bahman, Seyyed Reza Seyyed Javadein, and Hassan Abedi Jafari. 2010. ‘Measurement of Enterprise
Architecture Readiness within Organizations’. Business Strategy Series 11 (3): 177191.
Jensen, Claus T., Owen Cline, and Martin Owen. 2011. Combining Business Process Management and Enterprise
Architecture for Better Business Outcomes. IBM Redbooks.
http://books.google.com/books?hl=en&lr=&id=E6nEAgAAQBAJ&oi=fnd&pg=PP1&dq=Combining+Bus
iness+Process+Management+and+Enterprise+Architecture+for+Better+Business+Outcomes&ots=fS-
iFfbMa4&sig=rkHjPddOZNZeqPSrm7Vym8VYmkg.
Kähkönen, Tommi, Kari Smolander, and Andrey Maglyas. 2016. ‘Lack of Integration Governance in ERP
Development: A Case Study on Causes and Effects’. Enterprise Information Systems, 134.
28
Kaisler, Stephen H., Frank Armour, and Michael Valivullah. 2005. ‘Enterprise Architecting: Critical Problems’. In
System Sciences, 2005. HICSS’05. Proceedings of the 38th Annual Hawaii International Conference On,
224b–224b. IEEE. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1385698.
Kamoun, FAOUZI. 2013. ‘Rethinking the Role of Enterprise Architecture During Times of Economic Downturn: A
Dynamic Capabilities Approach’. Journal of Information Technology Management 24 (1): 26.
Kang, Dongwoo, Jeongsoo Lee, Sungchul Choi, and Kwangsoo Kim. 2010. ‘An Ontology-Based Enterprise
Architecture’. Expert Systems with Applications 37 (2): 1456–64. doi:10.1016/j.eswa.2009.06.073.
Kappelman, Leon A., and John A. Zachman. 2013. ‘The Enterprise and Its Architecture: Ontology & Challenges’.
Journal of Computer Information Systems 53 (4): 87–95.
Kilpeläinen, Turo. 2007. ‘Business Information Driven Approach for EA Development in Practice’. In The
Proceedings of the 18th Australasian Conference on Information Systems. Australia, 57. Citeseer.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.8418&rep=rep1&type=pdf.
Kim, Jin-Woo, Ju-Hum Kwon, Young-Gab Kim, Chee-Yang Song, Hyun-Seok Kim, and Doo-Kwon Baik. 2006.
‘EAFoC: Enterprise Architecture Framework Based on Commonality’. Journal of Computer Science and
Technology 21 (6): 95264. doi:10.1007/s11390-006-0952-5.
Kvan, Thomas. 2000. ‘Collaborative Design: What Is It?’ Automation in Construction 9 (4): 40915.
doi:10.1016/S0926-5805(99)00025-4.
Lange, Matthias, and Jan Mendling. 2011. ‘An Experts’ Perspective on Enterprise Architecture Goals, Framework
Adoption and Benefit Assessment’. In Enterprise Distributed Object Computing Conference Workshops
(EDOCW), 2011 15th IEEE International, 304313. IEEE.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6037633.
Lankhorst, Marc. 2013. ‘Enterprise Architecture at Work: Modelling, Communication and Analysis’.
http://library.wur.nl/WebQuery/clc/2004404.
Locke, Karen. 2001. Grounded Theory in Management Research. Sage.
http://books.google.com/books?hl=en&lr=&id=OcDWB-
rWvWUC&oi=fnd&pg=PR7&dq=grounded+theory+in+management+research&ots=XpJKgN-74o&sig=-
TyCttfGr7qRou_Vj0YUzDqFvJA.
Löhe, Jan, and Christine Legner. 2014. ‘Overcoming Implementation Challenges in Enterprise Architecture
Management: A Design Theory for Architecture-Driven IT Management (ADRIMA)’. Information Systems
and E-Business Management 12 (1): 101137.
Lucke, Carsten, Sascha Krell, and Ulrike Lechner. 2010. ‘Critical Issues in Enterprise Architecting A Literature
Review’. AMCIS 2010 Proceedings, August. http://aisel.aisnet.org/amcis2010/305.
Luftman, Jerry, and Tal Ben-Zvi. 2011. ‘Key Issues for IT Executives 2011: Cautious Optimism in Uncertain
Economic Times’. MIS Quarterly Executive 10 (4): 20312.
McGee, M. K. 2008. ‘IT And Business Alignment Remains CIO’s Top Concern’. InformationWeek.
http://www.informationweek.com/wireless/it-and-business-alignment-remains-cios-top-concern/d/d-
id/1071597?
McGhee, Gerry, Glenn R. Marland, and Jacqueline Atkinson. 2007. ‘Grounded Theory Research: Literature
Reviewing and Reflexivity’. Journal of Advanced Nursing 60 (3): 33442. doi:10.1111/j.1365-
2648.2007.04436.x.
Medini, Khaled, and Jean Pierre Bourey. 2012. ‘SCOR-Based Enterprise Architecture Methodology’. International
Journal of Computer Integrated Manufacturing 25 (7): 594–607.
MIT CISR. 2016. ‘Enterprise Architecture « Center for Information Systems Research - MIT Sloan School of
Management’. Accessed June 8. http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-
architecture/.
Morganwalp, Jillian M., and Andrew P. Sage. 2004. ‘Enterprise Architecture Measures of Effectiveness’.
International Journal of Technology, Policy and Management 4 (1): 8194.
Morse, Janice M. 1995. ‘The Significance of Saturation’. Qualitative Health Research 5 (2): 147149.
Nakakawa, A., P. van Bommel, and H. A. Proper. 2010. ‘Challenges of Involving Stakeholders When Creating
Enterprise Architecture’. In 5th SIKS/BENAIS Conference on Enterprise Information Systems, 4355.
http://ceur-ws.org/Vol-662/EIS2010_proceedings.pdf#page=57.
Nicolini, Davide, Jeanne Mengis, and Jacky Swan. 2012. ‘Understanding the Role of Objects in Cross-Disciplinary
Collaboration’. Organization Science 23 (3): 612–629.
Niemann, Klaus D. 2006. From Enterprise Architecture to IT Governance. Vol. 1. Springer.
http://link.springer.com/content/pdf/10.1007/978-3-8348-9283-6.pdf.
29
Niemi, Eetu. 2008. ‘Enterprise Architecture Benefits: Perceptions from Literature and Practice’. Evaluation of
Enterprise and Software Architectures: Critical Issues, Metrics and Practices:[AISA Project 2005-
2008]/Eetu Niemi, Tanja Ylimäki & Niina Hämäläinen (Eds.). Jyväskylä: University of Jyväskylä,
Information Technology Research Institute, 2008.-(Tietotekniikan Tutkimusinstituutin Julkaisuja, ISSN
1236-1615; 18). ISBN 978-951-39-3108-7 (CD-ROM). https://jyx.jyu.fi/dspace/handle/123456789/41370.
Niemi, Eetu, and Samuli Pekkola. 2015. ‘Using Enterprise Architecture Artefacts in an Organisation’. Enterprise
Information Systems, 126.
Niemietz, Hella, Sybren De Kinderen, and Christina Constantinidis. 2013. ‘Understanding The Role Of Subcultures
In The Enterprise Architecture Process.’ In ECIS, 129.
http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1352&context=ecis2013_cr.
Nikpay, Fatemeh, Harihodin Selamat, Babak Darvish Rouhani, and Pourya Nikfard. 2013. ‘A Review of Critical
Success Factors of Enterprise Architecture Implementation’. In Informatics and Creative Multimedia
(ICICM), 2013 International Conference On, 3842. IEEE.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6702779.
Nogueira, Juan Manuel, David Romero, Javier Espadas, and Arturo Molina. 2013. ‘Leveraging the Zachman
Framework Implementation Using Actionresearch Methodologya Case Study: Aligning the Enterprise
Architecture and the Business Goals’. Enterprise Information Systems 7 (1): 100132.
Pandit, Naresh. 1996. ‘The Creation of Theory: A Recent Application of the Grounded Theory Method’. The
Qualitative Report 2 (4): 1–15.
Patton, Michael Quinn. 2005. Qualitative Research. Wiley Online Library.
http://onlinelibrary.wiley.com/doi/10.1002/0470013192.bsa514/full.
Penttinen, Katja, and Hannakaisa Isomäki. 2010. ‘Stakeholders’ Views on Government Enterprise Architecture:
Strategic Goals and New Public Services’. In Electronic Government and the Information Systems
Perspective, 18. Springer. http://link.springer.com/chapter/10.1007/978-3-642-15172-9_1.
Postina, Matthias, Sebastian Rohjans, Ulrike Steffens, and Mathias Uslar. 2010. ‘Views on Service Oriented
Architectures in the Context of Smart Grids’. In Smart Grid Communications (SmartGridComm), 2010 First
IEEE International Conference On, 2530. IEEE. http://ieeexplore.ieee.org/abstract/document/5622009/.
Roeleven, Sven. 2010. ‘Why Two Thirds of Enterprise Architecture Projects Fail - Whitepaper’. CIO.
http://www.cio.com.au/whitepaper/370709/why-two-thirds-of-enterprise-architecture-projects-
fail/?type=other&arg=0&location=featured_list.
Rohloff, Michael. 2005. ‘Enterprise Architecture-Framework and Methodology for the Design of Architectures in the
Large’. ECIS 2005 Proceedings, 113.
Ross, Jeanne W., Peter Weill, and David C. Robertson. 2006. Enterprise Architecture as Strategy: Creating a
Foundation for Business Execution. Harvard Business Press.
http://books.google.com/books?hl=en&lr=&id=5MVcnOyJ2bEC&oi=fnd&pg=PR7&dq=Enterprise+Archi
tecture+As+Strategy:+Creating+a+Foundation+for+Business+Execution.&ots=qS0or7s0t7&sig=ypWdYtd
FifzGZvXOa-gZFGSHOHc.
Roth, Sascha, Matheus Hauder, Matthias Farwick, Ruth Breu, and Florian Matthes. 2013. ‘Enterprise Architecture
Documentation: Current Practices and Future Directions.’ In Wirtschaftsinformatik, 58.
http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1057&context=wi2013.
Rouhani, Babak Darvish, Mohd Nazri Mahrin, Fatemeh Nikpay, and Bita Darvish Rouhani. 2014. ‘Current Issues on
Enterprise Architecture Implementation Methodology’. In New Perspectives in Information Systems and
Technologies, Volume 2, 23946. Springer, Cham. doi:10.1007/978-3-319-05948-8_23.
Saarelainen, M.-M., and V. Hotti. 2011. ‘Does Enterprise Architecture Form the Ground for Group Decisions in
EGovernment Programme? Qualitative Study of the Finnish National Project for IT in Social Services’. In
Enterprise Distributed Object Computing Conference Workshops (EDOCW), 2011 15th IEEE International,
11–17. doi:10.1109/EDOCW.2011.26.
Schmidt, Christian, and Peter Buxmann. 2011. ‘Outcomes and Success Factors of Enterprise IT Architecture
Management: Empirical Insight from the International Financial Services Industry’. European Journal of
Information Systems 20 (2): 168185.
Seppänen, Ville, Jukka Heikkilä, and Katja Liimatainen. 2009. ‘Key Issues in EA-Implementation: Case Study of
Two Finnish Government Agencies’. In Commerce and Enterprise Computing, 2009. CEC’09. IEEE
Conference On, 114–120. IEEE. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5210807.
Simon, Daniel, Kai Fischbach, and Detlef Schoder. 2014. ‘Enterprise Architecture Management and Its Role in
Corporate Strategic Management’. Information Systems and E-Business Management 12 (1): 542.
doi:10.1007/s10257-013-0213-4.
30
Sowa, John F., and John A. Zachman. 1992. ‘Extending and Formalizing the Framework for Information Systems
Architecture’. IBM Systems Journal 31 (3): 590–616.
Stensaker, Inger, Joyce Falkenberg, and Kjell Grønhaug. 2008. ‘Implementation Activities and Organizational
Sensemaking’. The Journal of Applied Behavioral Science.
http://jab.sagepub.com/content/early/2008/03/05/0021886307313794.short.
Strauss, Anselm, and Juliet Corbin. 1990. Basics of Qualitative Research: Grounded Theory Procedures and
Techniques. Sage Publications.
———. 1998. The Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. 1st
Edition. Sage, London.
Tamm, T., P.B. Seddon, G. Shanks, and P. Reynolds. 2011. ‘How Does Enterprise Architecture Add Value to
Organisations?’ Communications of the Association for Information Systems 28 (1): 141–68.
Valtonen, K., S. Mäntynen, M. Leppänen, and M. Pulkkinen. 2011. ‘Enterprise Architecture Descriptions for
Enhancing Local Government Transformation and Coherency Management: Case Study’. In Enterprise
Distributed Object Computing Conference Workshops (EDOCW), 2011 15th IEEE International, 36069.
doi:10.1109/EDOCW.2011.39.
Van der Raadt, Bas, Marc Bonnet, Sander Schouten, and Hans Van Vliet. 2010. ‘The Relation between EA
Effectiveness and Stakeholder Satisfaction’. Journal of Systems and Software 83 (10): 19541969.
Van Der Raadt, Bas, Johan F. Hoorn, and Hans Van Vliet. 2005. ‘Alignment and Maturity Are Siblings in Architecture
Assessment’. In Advanced Information Systems Engineering, 357371. Springer.
http://link.springer.com/chapter/10.1007/11431855_25.
Van Steenbergen, Marlies, Ralph Foorthuis, Nino Mushkudiani, Wiel Bruls, Sjaak Brinkkemper, and Rik Bos. 2011.
‘Achieving Enterprise Architecture Benefits: What Makes the Difference?’ In Enterprise Distributed Object
Computing Conference Workshops (EDOCW), 2011 15th IEEE International, 350359. IEEE.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6037638.
Vargas, Alix, Llanos Cuenca, Andrés Boza, Ioan Sacala, and Mihnea Moisescu. 2014. ‘Towards the Development of
the Framework for Inter Sensing Enterprise Architecture’. Journal of Intelligent Manufacturing, 118.
doi:10.1007/s10845-014-0901-z.
Wan, Haining, and Sven Carlsson. 2012. ‘Towards an Understanding of Enterprise Architecture Analysis Activities’.
In European Conference on Information Management and Evaluation; Reading, 334–XII. Reading, United
Kingdom: Academic Conferences International Limited.
http://search.proquest.com/docview/1326437913/abstract/40D6D6E7584B4FC9PQ/1.
Wan, Haining, Aimin Luo, and Xueshan Luo. 2014. ‘How Enterprise Architecture Formative Critical Success Facets
Might Affect Enterprise Architecture Success: A Literature Analysis’. In Service Science and Knowledge
Innovation, 197–209. Springer. http://link.springer.com/chapter/10.1007/978-3-642-55355-4_20.
Wan, Haining, Xueshan Luo, Björn Johansson, and Honghui Chen. 2013. ‘Enterprise Architecture Benefits’. ICISO
2013, 62.
Winter, Robert, and Ronny Fischer. 2006. ‘Essential Layers, Artifacts, and Dependencies of Enterprise Architecture’.
In Enterprise Distributed Object Computing Conference Workshops, 2006. EDOCW’06. 10th IEEE
International, 3030. IEEE. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4031290.
Winter, Robert, and Joachim Schelp. 2008. ‘Enterprise Architecture Governance: The Need for a Business-to-IT
Approach’. In Proceedings of the 2008 ACM Symposium on Applied Computing, 548–552. ACM.
http://dl.acm.org/citation.cfm?id=1363820.
Wu, Raymond Cheng-Yi, and Jie Lu. 2007. ‘Enterprise Integration Strategy of Interoperability’. In Advances and
Innovations in Systems, Computing Sciences and Software Engineering, edited by Khaled Elleithy, 36974.
Springer Netherlands. http://link.springer.com/chapter/10.1007/978-1-4020-6264-3_64.
Ylimäki, Tanja. 2008. ‘Potential Critical Success Factors for Enterprise Architecture’. Evaluation of Enterprise and
Software Architectures: Critical Issues, Metrics and Practices:[AISA Project 2005-2008]/Eetu Niemi, Tanja
Ylimäki & Niina Hämäläinen (Eds.). Jyväskylä: University of Jyväskylä, Information Technology Research
Institute, 2008.-(Tietotekniikan Tutkimusinstituutin Julkaisuja, ISSN 1236-1615; 18). ISBN 978-951-39-
3108-7 (CD-ROM). https://jyx.jyu.fi/dspace/handle/123456789/41369.
Yuhashi, Hiroyasu, and Junichi Iijima. 2010. ‘The Power to Activate a Creative Core in Enterprise’. Power 6: 12010.
Yuhashi, Hiroyasu, and Junichi Ijima. 2009. ‘How Can We Manipulate a Communication Network to Create
Collaboration?’ AMCIS 2009 Proceedings, 97.
Zachman, John A. 1987. ‘A Framework for Information Systems Architecture’. IBM Systems Journal 26 (3): 276
292.
31
Appendix I
Interview questions:
1st round of interviews (May and June 2014):
Can you tell us about your job?
1. What is your job position/title?
Integration questions
1. IT architecture: Can you briefly summarise the most important
a. internal and
b. external systems the Enterprise Resource Planning (ERP) system is integrated with?
2. Can you tell us about the key technologies and standards that are used in integration?
3. When developing the ERP system, how do you determine when to integrate the ERP system with another
system?
4. Who states the requirements for integration (think about the roles of the business and IT departments of your
organisation, the role of the vendor and the role of external consultants)?
5. Integration projects: Can you identify different types of integration projects—for example, when integrating
the ERP system with a. another internal system?
b. an external system?
6. Who are involved in integration projects (business, IT, vendor, consultants)? Can you tell us especially about
the vendor’s role?
7. Can you think of any common challenges that are always present in integration projects?
8. Let’s say you realise that the ERP system has to be integrated with an external system of the supply chain.
What kind of approach is used? How do things progress after the decision to integrate has been made?
9. How do you measure the success of an integration project?
EA questions
1. What is EA, in your opinion?
2. Who are involved in the creation/development of EA in your organisation? Do you have your own full-time
architecture team?
3. Are you involved with EA in your work? How is EA related to your work?
4. Can you tell us about the history of EA development in your organisation? (From when did you realise the
need for EA in your company, or has it always been there?)
5. What standard methodologies and frameworks do you use in EA development (such as The Open Group
Architecture Framework [TOGAF], Zachman)? (Regarding readymade practices, are they useful at all, and if not,
why?) a. Why did you choose to use this specific framework?
b. Have you customised the framework, or have you used it as it is?
6. What are the challenges you have faced during EA development? (EA is often considered a difficult thing;
why do you think it is difficult to create and manage EA?)
7. Can you describe how EA is used or how it can be used in your organisation? In which situations is EA
needed?
8. When you are making investments, is EA considered in the decision-making process (for example, when you
think about the current Business-to-Business [B2B] project)?
9. Is your EA meeting your expectations? Does it match the needs of your company?
10. How about managing knowledge about EA? Is this knowledge always documented? How do you train people
on EA?
32
Concluding questions
1. Can you name other persons whom we should interview based on the topics we have been discussing?
2. Can we interview you again next year?
2nd round of interviews (May to July 2015):
General questions
1. What is your current position?
2. How long have you been working at this company?
3. How many people are working at your company?
4. How many people are working in the IT department of your company?
5. Do you have a permanent IT team at your company, or do vendors from outside of the company meet your
IT needs? a. With which companies do you have contracts, and what do they do for you?
EA questions
1. What is EA, in your opinion?
2. Do you employ EA in your daily work? How?
3. Please tell us the story behind EA development at your company?
a. When did you realise your need for EA (reasons for developing EA)?
4. Who makes decision regarding EA at your organisation?
5. Have you provided any education for your personnel regarding EA?
a. In which development stage are you, and who has received training?
EA team
1. How many people are employed on the EA team at your organisation?
2. In general, what are the EA team’s responsibilities at your organisation?
3. How does the EA team at your organisation take action on a project?
4. When does the EA team usually engage in projects at your organisation?
Pre-implementation stage
1. What actions did you take before starting your EA project? How did you make you organisation ready to
adopt EA?
2. What were your primary goals for EA development?
3. What were the challenges you faced during this stage?
Development stage
1. How did you implement EA (insourcing or outsourcing)?
a. How did you choose your consultant?
b. How satisfied are you with your EA consultant?
c. How is the cooperation between your EA consultant and IT personnel? Is it satisfactory?
d. Do you have any problems with your EA consultant?
2. What standard methodologies and frameworks do you use in EA development (such as TOGAF,
Zachman…)? a. How did you choose to use this specific framework?
b. Have you customised the framework or used it as it is?
3. How long did it take to implement EA at your organisation?
4. Has the EA had any influence on your company’s investments? How?
33
5. What are the challenges you faced during EA development?
EA results
1. What results have you gotten from EA development? What are the outcomes of this development?
2. How have these results been determined?
3. To what extent are you satisfied with the results obtained from the implementation of EA?
a. If you are not satisfied with the results of your EA, what are the reasons for this
dissatisfaction?
4. In your opinion, what are the challenges in the results obtained from EA development?
5. How many of your initial goals were fulfilled?
Post-implementation stage
1. Does your organisation have any programme for reviewing and updating its EA?
a. Has it been performed yet?
b. How often does your organisation update its EA?
c. How important is the EA update? What challenges are faced in updating EA?
2. If you had the chance to redo the EA development at your organisation, what might you do differently, and
why?
3. What were the challenges you faced after EA implementation?
a. What solutions did you adopt to eliminate these challenges?
4. How do you evaluate the EA’s success and effects at your organisation?
5. In your opinion, what is the role of EA in enterprise integration?
Final questions
1. Is there anything else you would like to mention regarding this topic?
2. Can you name other persons whom we should interview based on the topics we have been discussing?
3. Can we interview you again in the future?
Appendix II
Identified obstacles and their relationships with one another.
Identified obstacle
Is Cause of
2way Causality
Is associated with
Is Part of
Contradicts
with
Confusion in
government
-Unclear
organisational
strategies
-Government-
related political
issues
Government-related
political issues
-Political changes in
the country
-Confusion in
government
Unclear
organisational
strategies
Inexperienced EA
consultants
-Setting too
ambitious goals
-EA
consultant
related issues
-Finishing the
project on time
Outdated
organisational
statutes
-Unclear
organisational
strategies
Political changes in
the country
-Constant change of
management
-Government-
related political
issues
34
Restricted rules in
governmental
organisations
-Laws contradict
with the EA results
EA consultants
becoming inefficient
-EA
consultant
related issues
EA consultant’s
being inflexible
-EA
consultant
related issues
Lack of EA
consultant
innovation
-EA
consultant
related issues
EA consultant
related issues
-Lack of
communication
and collaboration
Lawscontradicting
the EA results
-Restricted rules in
governmental
organisations
Organisational-
structure deficiencies
-CIO is not directly
managed by CEO
Being function
oriented instead of
process oriented
-Old infrastructure
Old infrastructure
-Being function
oriented instead of
process oriented
Lack of change-
management tools
-Lack of central and
powerful EA unit
Ineffective EA
outputs
Lack of knowledge
among management
-Personnel resistance
to change
-Unable to set
common goal and
achieve shared
understanding
-Setting too
ambitious goals
Lack of management
support
-Lack of motivation
among personnel
-Unable to set
common goal and
achieve shared
understanding
-Lack of budget
-Favouritism in
hiring new and
unqualified
personnel
-EA’s being a
governance
project
-Finishing the
project on time
-Personnel’s
motivation
CIO is not directly
managed by CEO
-Organisational-
structure
deficiencies
-Finishing the
project on time
Setting too ambitious
goals
Unable to set
common goal and
achieve shared
understanding
Favouritism in hiring
new and unqualified
personnel
-Lack of
management
support
Constant change of
management
-Unable to set
common goal and
achieve shared
understanding
-Finishing the
project on time
35
Lack of budget
-Budget provision
Lack of central and
powerful EA unit
-Lack of change
management tools
-Organizational
structure
deficiencies
Personnel resistance
to change
-Lack of
communication
and collaboration
-Finishing the
project on time
Lack of knowledge
among personnel
-Unable to set
common goal and
achieve shared
understanding
-Personnel resistance
to change
-Lack of
communication
and collaboration
-Finishing the
project on time
Fluctuation in
personnel’s
motivation
-Lack of motivation
among personnel
-Finishing the
project on time
Lack of
communication and
cooperation
-Lack of knowledge
among management
-Lack of
management support
-Ineffective EA
outputs
-Personnel
resistance to
change
-EA consultant
related issues
-Lack of
knowledge among
personnel
Hesitation in training
personnel
-Lack of knowledge
among personnel
-Forcing personnel
to adopt EA
Forcing personnel to
adopt EA
-Hesitation in
training personnel
Lack of motivation
among personnel
-Personnel resistance
to change
-Lack of
communication and
collaboration
-Forcing personnel to
adopt EA
-Lack of knowledge
among personnel
-Fluctuation in
personnel’s
motivation
Appendix III
Codes, categories, and their relationships created as the result of open coding and axial coding.
Category
Description
Example of codes
Relationships to other
categories
EA::team
Individuals who are part of EA
development team
- Highly knowledgeable persons
- Advisors during integration
project
- Consists of IT and business
people
- Virtual EA team
- Consists of people from different
departments
- Carries out the EA
development process
- Maintains the EA
EA::goals
Includes the primary goal and
expectations of the
organizations from EA
- Cost reduction
- Establishing a new department to
manage the organizational
processes
- Putting all the enterprise entities
in their right places
- Is determined by the
organization
- Is done in the pre-
development stage
36
- Forecasting the market needs
- Finishing project on time
- Gaining higher level of maturity
- Having a detailed documentation
about organizational processes
- Improving business processes
- To remain competitive among
competitors
- Improve communication
- EA governance
EA::obstacle
Consists of different obstacles
that observed during EA
development that classified
into pre-development,
development, and post-
development
- Change of management
- Change resistance
- Inadequate budget
- Lack of monitoring equipment
- Lack of cooperation
- Consultant inflexibility
- Inexperienced consultant
- Lack of knowledge
- Invalid data
- Old infrastructure
- Unrealistic goals
- Lack of team work
- Unclear organizational strategy
- CIO is not directly managed by
CEO
- Personnel’s training
- Can have relationship with
any of the codes and
categories
EA::benefits
Includes benefits that
organizations gained through
EA development
- Filled the gap between CIO and
CEO
- Reduced redundancy
- Reduced costs
- Customers’ satisfaction
- Less error in managerial decisions
- Increased agility
- Improved business processes
- Help in finding the right solutions
- Improve organizational
competitive advantage
- Can have relationship with
any of the codes and
categories
EA::CriticalFactors
Factors or actions that is
considered critical during EA
development
- CEO directly track the
development process
- Being innovative
- Being realistic
- CEO has IT knowledge
- Receiving consultancy from
successful experienced people in
EA development
- Team work
- Separating business IT and
organizational IT
- Regular updates of EA
- Selecting motivated persons for
EA team
- High level management support
- Previous experience on EA
- Gaining personnel’s trust
- Can have relationship with
any of the codes and
categories
EA::development
The process of EA
development from pre-
development to post-
development stage
- Pre-development:
- Being clear about the
development process
- Development:
- Organizational culture
- Post-development:
-EA updates
- Aimed to develop EA and
facilitate EI
37
EA::regrets
Things that practitioners might
had done differently if they
had the opportunity to go back
in time
- More realistic goals
- More strict on timetable
- More experienced consultant
- Pilot test before making contract
with the consultant company
- More accurate plans
- More accurate data
- Is determined by the EA
team and managers
- Is associated with EA
obstacles
EA::consultants
The EA consulting company
that provides consultancy or
develops EA for the
organization
- Outsourcing EA development
- Getting consultant
- Educating personnel
- Communication and collaboration
- Previous experience
- Is associated with the EA
project
EI::benfits
Consists of benefits that are
gained through integration
- Reduce complexity
- Reduce redundancy
- Reduce costs
- Improve communication
- Can have relationship with
any of the codes and
categories
EI::obstacle
Consists of different obstacles
that practitioners faced during
an integration project
- Inexperienced consultant
- Lack of budget
- Lack of corporation
- Systems incompatibility
- Different interests of stakeholders
- Wrong architecture
- Lack of architectural descriptions
- Change resistance
- Change of management
- Lack of knowledge
- Lack of management support
- Can have relationship with
any of the codes and
categories
- Is associated with the
EI::CriticalFactors
Factors or actions that is
considered critical during an
integration project
- Accurate planning
- Assigning enough budget
- Testing before deploying
- Experienced consultant
- Enough knowledge
- Manager’s support and
knowledge
- Can have relationship with
any of the codes and
categories
EI::consultants
The consulting company that
provides consultancy or
solutions for integration
projects
- Previous experience
- Flexibility
- Availability
- Is associated with
integration project
- Is part of external parties
EI::goals
Includes the primary goal and
expectations of the
organizations from integration
project
- Cost reduction
- Customers’ satisfaction
- Facilitating business processes
- Remain competitive
- Improve collaboration
- Is determined by the
organization
EnterpriseSystems
Enterprise systems existing in
organizations, such as ERP,
CRM, sales, and logistics.
- Internal
- External
- Messaging
- Is part of organization
ExternalParties
Partners, suppliers, customers,
and other external parties of
the organizations.
- Consultants
- Customers
- Agencies
- Shareholders
- Government
- Suppliers
- Vendors
- Is associated with the
organization
38
Appendix IV
Identified obstacles in EA development categorised based on cases and the development stages. Numbers in the table
refer to the three development stages. 1: Pre-development, 2: Development and 3: Post-development.
Obstacle/Case
A
B
C
D
E
F
G
H
I
J
K
L
M
N
Government-related political issues
1
2
3
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
Outdated organisational statutes
1
Lack of knowledge among management
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
1
2
3
Lack of management support
1
2
3
1
2
3
1
2
3
1
2
3
1
1
2
3
1
2
3
Unable to set common goals and achieve a shared
understanding
1
1
1
1
1
1
Unclear organisational strategies
1
Personnel resistance to change
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
Lack of knowledge among personnel
1
2
1
2
3
1
2
3
1
2
3
1
2
1
1
2
3
1
2
Lack of communication and collaboration
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
1
2
3
EA consultantrelated issues
2
3
2
3
2
3
2
3
2
3
Organizational structure deficiencies
1
2
3
3
1
3
Lack of motivation among personnel
2
3
2
3
Inappropriate budget provision
2
3
2
3
2
3
Lack of central and powerful EA unit
3
3
Hesitation in training personnel
1
Old infrastructure
1
1
1
1
1
Ineffective EA outputs
3
3
3
39
Constant change of management
3
1
2
3
2
3
2
3
1
2
3
1
2
3
1
2
3
1
2
3
Setting goals that are too ambitious
1
1
1
Restricted rules in governmental organisations
2
3
2
3
Appendix V
Fig V 1 Lack of support inside organization
40
Fig V 2 Lack of knowledge inside organizations
Fig V 3 Issues imposed by external parties
41
Fig V 4 Lack of communication and collaboration
Negin Banaeianjahromi is currently a PhD candidate at Lappeenranta University of Technology, Finland. She has a
Master (2013) degree in Computer Science from Lappeenranta University of Technology. Her current research
interests include social and organizational issues of Enterprise Architecture and Enterprise Integration development.
Kari Smolander is Professor of Software Engineering in Department of Computer Science, Aalto University and in
School of Business and Management, Lappeenranta University of Technology, Finland. He has a PhD (2003) in
Computer Science from Lappeenranta University of Technology and a Licentiate (1993) and Master (1988) degree
from University of Jyväskylä, Finland. He has more than 140 refereed research papers in international journals and
conferences. His current research interests include change in software and systems development practices and software
development organizations.
... Much research is contributing to achieving the benefits of EA, but scant attention is given to EA failure (Kotusev, 2017). EA practice encounters many challenges and difficulties, such as complexity (Iyamu, 2019), stakeholder engagement , communication (Banaeianjahromi & Smolander, 2019), modelling (Pérez-Castillo et al., 2020), and proper use of EA artifacts (Niemi & Pekkola, 2017). Although these studies provide implications to practitioners in addressing EA challenges, the knowledge is in fragments, reflecting a fundamental problem of lacking explanatory theory in the field of EA (Tamm et al., 2011). ...
... Furthermore, poor motivation and insufficient understanding of EA by stakeholders could result in ineffective interactions with them during EA development (Votto et al., 2021). According to Banaeianjahromi and Smolander (2019), lack of communication and collaboration refers to a cause type influencing the failure of EA efforts. Specifically, it refers to the lack of knowledge and support inside organizations. ...
... This makes them hard to be involved and reach agreements on architectural questions and solutions . Such a situation could be even worse if high-level management does not understand the benefit of EA and provide sufficient support and commitment to it (Banaeianjahromi & Smolander, 2019). ...
Article
Full-text available
Enterprise architecture (EA) initiatives consist of functions, processes, tools, instruments, and principles to guide the design of IT and its alignment with business. EA is often presented as a silver bullet to ensure that IT contributes to business. Yet, many EA initiatives do not work out or even fail, but in the literature this area is undertheorized. This study aims to understand the factors influencing the failure of EA initiatives. We identified 15 factors and invited 8 EA experts to evaluate the factors and their influence based on an approach combining grey systems theory, Decision-Making and Trial Evaluation Laboratory (DEMATEL), and Interpretative Structural Modeling (ISM). The findings indicate that the factors are correlated and interwoven in complex causal chains. This study reveals the root factor and suggests enhancing high-level managers' EA knowledge and ensuring communication and leadership skills of enterprise architects as the starting point to avoid EA failure. Only later, organizing the EA function becomes important.
... A more collaborative way of EAM is required in today's organisations [6]. Hence, a stronger focus on communication and collaboration with corporate stakeholders is necessary [5] [44]. EAM should provide tangible benefits and contribute to corporate objectives [18]. ...
... Another challenge to implement EA are business functions not being flexible enough and the IT structure not being well organized. In essence, the core challenges seem to be a lack of communication and collaboration [5]. ...
... Preferably those who are directly affected by results of these key figures. This proved one of the main challenges within the EA discipline: The lack of communication and collaboration as revealed in [5]. Many practitioners would like to work based on key figures but almost no one uses or knows how to use such figures to prove the value of EA. ...
Article
Full-text available
Enterprise Architecture Management is a well-established discipline fostering business-IT alignment and driving innovation in an organisation. It provides an extensive set of methods and tools for visualising and analysing an organisation using several perspectives. However, critical voices are increasing in recent years. A significant amount of initiatives for establishing Enterprise Architecture are not meeting expectations. Furthermore, Enterprise Architecture is often recognised as a burden to corporate stakeholders rather than providing benefits. Current research is aiming at providing a stronger focus on corporate needs while performing Enterprise Architecture work. There seems to be a shift towards collaborative and agile approaches. The paper at hand presents the results of a survey among Enterprise Architecture practitioners to understand the expected benefits from Enterprise Architecture. The results of the survey are used to develop a framework that supports measuring the success of Enterprise Architecture decisions. This framework does not only focus on specific Enterprise Architecture goals but also incorporates the impact of Enterprise Architecture Management on corporate objectives. A first version of such a framework has been specifically developed for a German logistics company. This specific framework will be the starting point for future research on a generic framework for determining EA benefits in a company.
... March 2021 edition Vol.17, No.8 www.eujournal.org 37 Researchers such as Saint-Louis et al. ( 2019); Dang and Pekkola (2017); Foorthuis et al. (2020); Banaeianjahromi and Smolander (2019); and Szabó and Öri (2017) led studies whose findings showed the importance of EA in supporting organizations in addressing complexity if EA is involved in the process of managing organization. These scholars established that organizations must develop models of EA frameworks in line with their business context to gain the maximum benefit of EA as a tool for addressing complexity. ...
... EA and IS/IT Management This sub-section is essentially focused on IS within organizations and the support of EA in the ecosystem of digital transformation of organizations (Kasemsap, 2018;Banaeianjahromi & Smolander, 2019;Gampfer et al., 2018). Information system is an integrated set of components for collecting, storing, and processing data and for providing information, knowledge, and digital products (Zwass, 2020). ...
... It helps to educate stakeholders and show to business owners and decision makers the role and nature of information as a resource in the organization. Although they agree on the potential of EA to address challenges of managing IS, some of them highlighted the challenges related to implementation of EA itself (Olsen, 2017;Lauvrak et al., 2017;Banaeianjahromi & Smolander, 2019). ...
Article
The paper focuses on exploring the perceptions of stakeholders (medical doctors, nurses, pharmacists, IT staff and other employees) in healthcare organizations in Canada on how they developed Enterprise Architecture (EA) to improve managerial decision making and align business activities and Information Technology (IT). Both quantitative and qualitative methods were adopted for this research. A total of 120 questionnaires were sent out but only 72 responses were received. Participants included industry professionals involved in implementing information systems (IS) within healthcare organizations. Data was collected physically and through emails. Also 3 subject matter experts (experts) were interviewed for the study. These experts each have over ten years’ experience in EA practice and are doctorate degree holders (PhDs). The results of the study showed that stakeholders see the potential for EA to be a tool for planning IT/IS projects, breaking down organizational silos, creating digital transformation, and proactively responding to disruptive forces. They do not see EA as the necessary tool for integrating IT solutions.
... Nurse managers face challenges in leadership roles in a mining primary healthcare setting in South Africa. Banaeianjahromi and Smolander (2017) and Nene et al. (2020) confirmed that these challenges experienced by nurse managers in a mining primary healthcare setting include lack of effective communication, bureaucratic mining management and union influence. Primary healthcare is a frontline service that manages the health problems at this level for all the mine workers. ...
... Nurse managers posit that there is a communication gap between them and the mining management, and this gap affects the execution of their leadership roles. Communication gap makes it difficult to set common goals and achieve a shared understanding, and this put the organisation at risk of personnel's distrust, lack of innovation and loss of competitive edge (Banaeianjahromi & Smolander, 2017 ...
Article
Full-text available
Background: The challenges in leadership roles hinder the rendering of quality primary healthcare service in the mines. Mining, the heart of the South African economy, requires good health to its personnel to carry out operations. However, nurse managers, the leaders in a mining primary healthcare setting experience difficulties in their leadership roles. Objectives: The aim of this study was to explore and describe the challenges in leadership roles experienced by nurse managers in a mining primary healthcare setting in South Africa. Method: The study was conducted in a mining primary healthcare setting in West Rand, Gauteng province, South Africa. A qualitative, exploratory, descriptive design that is contextual in nature, using a phenomenological approach, was adopted. Data from nurse managers in the mine were collected and data saturation was reached by the seventh participant. The study followed Giorgi’s four stages of the phenomenological descriptive data analysis. An expert independent coder in qualitative research coded the data, and consensus on the findings was reached with the researcher. Results: Three subthemes emerged from the study: mining management and unions interfere with nurse managers’ leadership roles, incongruent mining primary healthcare policies and communication gap between nurse managers and mining management. Conclusion: The triangulation of nurse managers, mining management and unions requires a collective fusion to directly tackle the challenges in leadership roles in mining primary healthcare. Keywords: leadership roles; challenges; experiences; nurse managers; primary healthcare.
... Even though these EA frameworks provide established methods and tools, they tend to focus more on comprehensive and generic EA development processes and less on the identification of organization-specific immediate problems [5], [6]. Thus, communication and collaboration need to be prioritized in order to apply EA to problem solving [7]. ...
Conference Paper
The Enterprise Architecture (EA) discipline evolved during the past two decades and is now established in a large number of companies. Architectures in these companies changed over time and are now the result of a long creation and maintenance process. Such architectures still contain processes and services provided by legacy IT systems (e.g., systems, applications) that were reasonable during the time they were created but might now hamper the introduction of better solutions. In order to support handling those legacies, research on the notion of EA debts has been started. The concept of EA debts widens the scope of technical debts to cover also organizational aspects offering a mean for managing EA in dynamic environments. The research encompasses the development of methods for managing debts together with a repository of typical EA debts. Identifying EA debts for the repository is challenging as required knowledge is usually not documented. Therefore, a structured approach is needed to externalize this knowledge. The paper presents a workshop format that is used to identify EA debts in organizations. Corresponding workshops are performed in two distinct companies to support them in understanding certain issues they face. First results from those workshops are presented in the second part of the paper.
... A study conducted by Kar and Jha (2020) suggested that construction practitioners must keep in mind several factors, such as the need for proper communication as well as issues related to finance during procurement and scope changes, in order to improve the cost and schedule performance of a project. Therefore, a lack of communication can be a core obstacle to project success, which can lead to further issues and problems occurring that ultimately impact the performance of the project (Banaeianjahromi & Smolander, 2019). ...
Article
Full-text available
Schedule delays in construction projects are often a major concern and considered as a global phenomenon in the construction industry. In regard to project delivery, lack of senior management support is one of the main issues that impact project outcomes. This empirical research study aims to investigate the moderating effect of senior management support on the relationship between schedule delay factors and project performance. A questionnaire survey method was adopted to collect data from project directors, project managers, civil and construction engineers, project supervisors and experts from small, medium and large construction companies from major cities in Pakistan. A response rate of 84% was obtained based on 310 valid responses from a sample of 368 potential participants that received the survey. The cross sectional data were used to test direct relationships and moderating effect through regression analysis and 'process' method, respectively. The findings indicate that schedule delays in construction projects occur due to lack of commitment, insufficient site management, poor site coordination, lack of clarity in project scope, lack of communication and substandard contracts, in addition to major delays owing to improper planning. Moreover, the relationship between schedule delay factors and project performance is moderated by all dimensions of senior management support, i.e. providing resources, structural arrangements, communication, expertise and power.
... A study conducted by Kar and Jha (2020) suggested that construction practitioners must keep in mind several factors, such as the need for proper communication as well as issues related to finance during procurement and scope changes, in order to improve the cost and schedule performance of a project. Therefore, a lack of communication can be a core obstacle to project success, which can lead to further issues and problems occurring that ultimately impact the performance of the project (Banaeianjahromi & Smolander, 2019). ...
Article
Schedule delays in construction projects are often a major concern and considered as a global phenomenon in the construction industry. In regards to project delivery, lack of senior management support is one of the main issues that impact project outcomes. This empirical research study aims to investigate the moderating effect of senior management support on the relationship between schedule delay factors and project performance. A questionnaire survey method was adopted to collect data from project directors, project managers, civil and construction engineers, project supervisors, and experts from small, medium, and large construction companies from major cities in Pakistan. A response rate of 84% was obtained based on 310 valid responses from a sample of 368 potential participants that received the survey. The cross-sectional data were used to test direct relationships and moderating effects through regression analysis and “process” method, respectively. The findings indicate that schedule delays in construction projects occur due to lack of commitment, insufficient site management, poor site coordination, lack of clarity in project scope, lack of communication and substandard contracts, in addition to major delays owing to improper planning. Moreover, the relationship between schedule delay factors and project performance is moderated by all dimensions of senior management support, i.e. providing resources, structural arrangements, communication, expertise, and power.
Chapter
A company is subject to frequent changes driven by changing business requirements and objectives. Such changes must be managed properly and require a corresponding organisational unit. Traditional organisational forms follow a top-down approach—i.e. Enterprise Architecture Management is driven by top management. Recent experiences show that a more collaborative Enterprise Architecture Management approach is required.
Chapter
Full-text available
Garments tourism, which could be more consonant to fashion tourism, is still in its nascent stage, particularly in the context of developing countries like Bangladesh. Although Bangladesh is one of the largest exporters of apparel suppliers to the global market, most of its export was meant to be for the international fashion companies. By doing so, this has not only brought billions of dollars to the country’s economy but also created an avenue for thousands of businessmen/companies to travel to the country. The main purpose of this study is to look at the overall development of the garment industry in Bangladesh and how the garments industry could be translated into tourism. In so doing, the problem, prospects, and challenges of garments tourism are comprehensively discussed in this study. Overall, we argue that to revive the garments tourism, and the government should take aggressive measures to promote the branding of this industry by establishing and incentivizing the entrepreneurs, as well as making travel safe and sound for foreigners.
Chapter
Full-text available
Enterprise Architecture (EA) becomes a strategy plan for enterprises to align their business and Information Technology (IT). EA is developed, managed, and maintained through EA implementation methodology (EAIM) processes. There are some problems in current EAIMs that lead to ineffectiveness implementation of EA. This paper represents current issues on EAIM. In this regard, we set the framework in order to represent EAIM’s issues based on the processes of EAIM including: modeling, developing, and maintaining. The results of this research not only increase the knowledge of EAIM, but also could be useful for both scientific and practitioner in order to realize the current situation of EAIMs.
Conference Paper
Full-text available
Today’s enterprise environment is more sophisticated than ever and being able to manage this complexity is not possible without having a planned approach. Enterprise architecture (EA) has emerge as a planned approach to mitigate the organizational complexities and control the constant environmental changes. How-ever, despite the numerous EA development step-by-step methods and approaches not all of the EA efforts end with success. In this study we aimed to identify the obstacles that endanger the EA projects. Employing the multiple case study research method we collected data from 14 large enterprises by interviewing 20 experts. In total, we identified 20 obstacles that we further categorized into four main themes. Compared to earlier literature we found five types of obstacles that have not been mentioned before: political issues of the government, EA consultant related issues, outdated organizational statutes, constant change of management, and inefficient human resource department. Further we discussed about the relationships among the identi-fied obstacles and provide advice for managers to reduce the obstacles during EA development. Because this study is based on real world cases, provided understanding can benefit practitioners to alleviate obstacles during EA development.