=Paper=
{{Paper
|id=None
|storemode=property
|title=Challenges of Involving Stakeholders When Creating Enterprise Architecture
|pdfUrl=https://ceur-ws.org/Vol-662/paper_5.pdf
|volume=Vol-662
|dblpUrl=https://dblp.org/rec/conf/eis/NakakawaBP10
}}
==Challenges of Involving Stakeholders When Creating Enterprise Architecture==
https://ceur-ws.org/Vol-662/paper_5.pdf
5th SIKS/BENAIS Conference on Enterprise Information Systems
Challenges of Involving Stakeholders When
Creating Enterprise Architecture
A. (Agnes) Nakakawa1 , P. (Patrick) van Bommel1 , and H.A. (Erik) Proper1,2
1
ICIS, Radboud University Nijmegen
P. O. BOX 9010 6500, GL Nijmegen, The Netherlands
2
CITI, CRP Henri Tudor Luxembourg, Luxembourg
A.Nakakawa@science.ru.nl, pvb@cs.ru.nl, e.proper@acm.org
Abstract. Although researchers report challenges that occur during en-
terprise architecture development (in general), there is lack of an elab-
orate description of those that occur during enterprise architecture cre-
ation – particularly if organizational stakeholders are to be deeply in-
volved. Yet understanding challenges of involving organizational stake-
holders when creating enterprise architecture is a prerequisite for devis-
ing a relevant solution to enterprise architects. An exploratory survey
was therefore conducted with the aim of investigating challenges that
enterprise architects face when they involve organizational stakeholders
during enterprise architecture creation. This paper presents and discusses
findings from the survey. The survey results generally indicate why 90%
of enterprise architects face challenges when delivering products of enter-
prise architecture creation, although 96% of architects closely collaborate
with organizational stakeholders during enterprise architecture creation.
Keywords: Enterprise Architecture Creation, Stakeholder Involvement.
1 Introduction
Since architecture “is the normative restriction of design freedom”[2], enterprise
architecture can be conceived as a normative instrument (in the form of prin-
ciples, views, and models) that directs and informs a given transformation in
an organization [11]. Enterprise architecture can be used for: decision making
regarding an intended business transformation; formulating business strategy im-
pact; specifying (business) requirements; and informing and contracting service
providers [13]. The main threats in enterprise architecture development include:
choosing an ineffective leader as the lead enterprise architect; and not involving
business (or organizational) stakeholders in the architecture program [3]. How-
ever, involving stakeholders in the architecture development process tends to
result in several challenges. In [15] it is was reported that collaboration between
stakeholders and enterprise architects is often challenging. However, there is lack
of an elaborate description of the problematic nature of this collaboration, or
of the challenges that arise if organizational stakeholders are to be involved in
enterprise architecture development. Yet such a description is a prerequisite for
developing a relevant solution to practitioners (in this case enterprise architects).
43
Proceedings
Therefore, there was need to investigate the challenges architects face when
they involve organizational stakeholders in enterprise architecture development.
Since developing enterprise architecture involves creating (designing/specifying);
applying (implementing); and maintaining the architecture to support an organi-
zation’s business goals [13], investigations of these challenges were limited to cre-
ating architecture. To investigate challenges that enterprise architects face when
they involve stakeholders in creating an enterprise architecture, an exploratory
survey was conducted. The survey specifically investigated: factors that hinder
effective collaboration among organizational stakeholders and enterprise archi-
tects; challenges architects face when evaluating enterprise architecture design
alternatives; methods architects use to manage collaboration with stakeholders;
strengths and weaknesses of the methods used to support collaboration between
stakeholders and architects; challenges architects face when delivering architec-
ture products; and key determinants for successful enterprise architecture cre-
ation. A sample of 70 enterprise architects participated in this survey.
This paper discusses findings from this survey. The findings generally indi-
cate the practical relevance of devising an artifact that will improve enterprise
architecture creation by offering support for effective and efficient stakeholder
involvement in the enterprise architecture creation process. The survey was con-
ducted as part of an ongoing research (reported in [10,11,12]) that generally aims
at developing a standard (but flexible) approach that can support effective and
efficient collaborative problem solving and decision making during enterprise ar-
chitecture creation. The survey findings serve as a motivation for this research.
Section 2 discusses the rationale for undertaking an exploratory survey, section
3 explains the survey design, section 4 discusses the survey results, and section
5 gives the conclusion and ongoing work.
2 Rationale for an Exploratory Survey
According to [8,9], activity theory articulates that: artifacts (i.e. tools, symbols)
mediate between the subject (i.e. the important actor(s) in an activity) and the
object (i.e. the objective of an activity); there are rules that influence or govern
the execution of an activity; the execution of an activity involves a community of
actors; and the execution of an activity requires division of labour. The process of
creating an enterprise architecture can be conceived as an activity (or collection
of sub activities that contribute to completion of the main activity). Thus, table
1 shows how the notions in the activity theory have been interpreted and adapted
in this research.
All aspects of the activity theory (see column 2 of table 1) are explicitly in-
terpreted in the context of enterprise architecture creation (see column 3 of table
1), except item 6 (i.e. the division of labour). According to [19], during enterprise
architecture development, an enterprise architect must identify all stakeholders’
concerns, and then develop architecture views that reflect how all concerns will
be addressed in the architecture and the intended tradeoffs. This implies (as
shown in step 6 of table 1) that in enterprise architecture creation, there are: (1)
44
5th SIKS/BENAIS Conference on Enterprise Information Systems
Table 1. Adaptation of Activity Theory in Enterprise Architecture Creation
Step Aspects to Identify (Based on Perspective in this Research
# Mwanza & Engestrom 2003 )
1 Activity of interest (i.e. type of Creating an enterprise architecture for a given organization
activity of interest)
2 Objective (i.e. why the activity is According to Op’t Land et al., 2008, enterprise architecture can be created for any of the
taking place) following purposes, i.e.:
1. Decision making regarding an intended business transformation;
2. Formulating business strategy impact;
3. Specifying (business) requirements; and
4. Informing and contracting service providers
3 Subjects (i.e. those involved in Enterprise architects and organizational stakeholders
carrying out the activity)
4 Tools (i.e. the means used by the Enterprise architecture approaches, architecture modeling languages (for designing the
subjects to perform the activity) enterprise architecture models), & other (simulation or visualization) tools that may be
relevant depending on the situation in a given organization
5 Rules and regulations (i.e. 1. The organization policies, principles, culture, strategic business drivers, business
cultural norms, rules, or goals, and business requirements;
regulations governing the 2. The external laws of business from regulatory bodies to which the organization is
performance of the activity) accountable; and
3. The guidelines defined by enterprise architecture approaches.
6 Division of labour (i.e. In enterprise architecture creation, there are mainly 2 types of roles, i.e.:
determining who is responsible 1. Roles that are supposed to be accomplished by the enterprise architects,
for what when carrying out the 2. Roles that are supposed to be accomplished by both enterprise architects and
activity, and organizing the roles) organizational stakeholders through effective collaboration.
7 Community (i.e. the environment The environment comprises of enterprise architects and organizational stakeholders.
in which the activity is carried According to TOGAF, stakeholders can be categorized into: corporate, end-user
out) organization, project organization, system operations, and external key stakeholders.
8 Outcome (i.e. the desired Feasible enterprise architecture products that address all stakeholders’ concerns.
outcome from carrying out the According to Op’t Land et al., 2008, architecture products are: tangible & intangible
activity) products including: principles, models, views, intermediate results used to develop the
enterprise architecture models, the evaluation of alternative solutions, shared
understanding, shared agreement, & commitment amongst stakeholders.
some tasks must be accomplished by the enterprise architects; and (2) tasks that
are supposed to be accomplished through effective collaboration between enter-
prise architects and organizational stakeholders. Moreover, several researchers
and practitioners (e.g. [3,6,13,19,18,15,16]) have advocated for the need for col-
laboration between enterprise architects and organizational stakeholders during
architecture creation. Yet in [15], it has been reported that it is often difficult for
enterprise architects and stakeholders to effectively collaborate during enterprise
architecture creation. This implies that during the division of labour, there is
complexity on how roles in category 2 (see row 6 in table 1) can be fulfilled. For
this complexity to be resolved, there is need for an in-depth understanding of
challenges enterprise architects face when they collaborate with stakeholders to
accomplish the roles in category 2. However, literature on enterprise architecture
is silent on the details of the problematic nature of collaboration between stake-
holders and enterprise architects during architecture creation. Therefore, there
was need to undertake an exploratory survey so as to investigate the collabora-
tive aspects in enterprise architecture creation. Findings from the survey would
then give insight on how collaboration between stakeholders and architects can
be improved during architecture creation (see section 4).
3 Design of the Exploratory Survey
This section presents the design of the exploratory survey that was conducted
to find out problems that enterprise architects face when they involve organi-
45
Proceedings
zational stakeholders in the enterprise architecture creation process. The target
respondents in this survey were enterprise architects. Self administered question-
naires were used (see Fig. 1 in appendix), and were pretested using 10 enterprise
architects. Prior to the survey, the suitable sample size and sampling method
had to be determined. According to [7,17], the appropriate sample size to use in
a survey depends on: (1) the acceptable sampling error, i.e. the error that oc-
curs in survey results due to studying a sample instead of the whole population;
(2) the size of the population and its heterogeneity with respect to the features
of interest; (3) the desired level of accuracy (or confidence); (4) the research
budget; and (5) the desired statistical value, i.e. population mean or population
proportion – the percentage of individuals who fall into a given category. For
this survey the desired level of accuracy was at least a 95% confidence interval,
and acceptable sampling error was ± 10%. The statistical values required from
the survey were percentages of the target population (i.e. enterprise architects)
who experience or do not experience the aspects this research was investigating.
Therefore, the following formula, as defined in [5,7,17], was used to calculate the
required sample size in this survey:
z 2 (p(1 − p))
s=
e2
Here s represents the required sample size, z represents the number equivalent
to the desired level of confidence, p represents the estimate of the proportion of
people (i.e. enterprise architects) falling into the whole population of the target
respondents, and e represents the acceptable sampling error. The self adminis-
tered questionnaires were to be posted on international, national, and corporate
mailing lists of enterprise architects. Thus, it was assumed that at least 90%
of the population or subscribers to these mailing lists are enterprise architects.
Hence the value of p is 90%. Moreover, since the desired level of confidence was
95%, then from the z statistical tables z = 1.96. Since the acceptable sampling
error was ± 10%, then e = 0.1. Inserting these values in the equation above, s =
35. Therefore, the required sample size was at least 35 enterprise architects. In
other words, assuming 90% of subscribers on mailing lists of enterprise architects
are real architects, then for us to be at least 95% confident that the conclusions
we draw from the survey results have a sampling error of ± 10%, at least 35
enterprise architects were required to participate in this survey.
The next step was to determine the appropriate method for selecting the
required sample of architects. Sampling methods are divided into two categories
i.e. probability sampling methods (which are used when the list of the whole
population of study is available and it is possible to determine the likelihood
of selecting any of the population units) and non probability sampling methods
(which are used when the list of the population of study is not available and is
difficult to obtain) [5,14,17]. In this survey the list of the target population (i.e.
all enterprise architects) was not available and was difficult to obtain. Therefore,
a non probability sampling method was used, i.e. purposive (or purposeful) sam-
pling. Purposeful sampling is used when there is need to study and understand
something about, or features of, a specific group of people [14]. The survey was
46
5th SIKS/BENAIS Conference on Enterprise Information Systems
conducted online (i.e. via http://www.thesistools.com/), where the target
respondents received the questionnaires through the mailing lists of enterprise
architects. A maximum of 70 enterprise architects participated in this online
survey. This response doubled the earlier required sample size of 35 participants
and consequently lowered the sampling error to ± 7%. This implies that we
are 95% confident that the findings, or conclusions drawn, from the survey (see
section 4) have a sampling error of ± 7%.
4 Survey Results and Discussion
In this section results from the exploratory survey are presented. These include:
the problems architects face when collaborating and evaluating architecture
design alternatives with stakeholders during architecture creation; challenges
encountered when delivering enterprise architecture products; insights on how
problems encountered during enterprise architecture creation can be overcome;
and methods enterprise architects use to manage collaborative tasks during ar-
chitecture creation. Aspects presented in sections 4.1 – 4.6 can be perceived
as (research) requirements that must be fulfilled in order to improve enterprise
architecture creation through effective and efficient stakeholder involvement.
4.1 Factors Hindering Effective Collaboration
Since collaboration (between stakeholders and enterprise architects) is a core
thread in enterprise architecture creation [12], it was vital to investigate the
hindrances of its effectiveness and efficiency during architecture creation. The
following were reported as the factors affecting it. The percentage of enterprise
architects that experience each hindrance is given in brackets.
1. Time constraints i.e. unavailability of key stakeholders because they have
no time or priority to collaborate, and yet project time schedules are taut
(77%).
2. Organization politics, hidden agendas of stakeholders (which cause them to
block a long term vision due to their short term needs), prima donna be-
haviors (i.e. self-centeredness) of some stakeholders, and cases where people
in the organization do not want clear decision making due to selfish reasons
(56%).
3. Difficulty in truly understanding and communicating with stakeholders be-
cause architects mainly talk about abstract concepts and are unable to ex-
plain the true value of architecture in a language that the key decision makers
understand, while stakeholders use words that do not have the same meaning
for everyone (50%).
4. Lack of a well founded and shared vision on the business itself, its future
development, its enterprise architecture, and the consequences of the archi-
tecture on the organization’s sub levels. This is because some people find it
difficult to imagine a new situation (47%).
47
Proceedings
5. Lack of architecture governance and a strong decision making process which
leads to stakeholders not taking responsibility for their decisions (47%).
6. Limited awareness of (infrastructure) architecture or the need for architec-
ture, stakeholders’ perception about architecture (e.g. architecture is per-
ceived to be about only technology), and the gap between (business) opera-
tions and enterprise architecture (44%).
7. Lack of long term planning e.g. long term effects may not be considered
as part of the business case or project goal, members of the architecture
project (i.e. business and IT staff) may be unknown, project managers may
be assigned late when projects are already on critical path (42%).
8. Social complexity of an organization, conflicting agendas or interests of stake-
holders, differences in stakeholders’ perception about ambition levels, and
the ladder of inference - i.e. stakeholders overreacting or quickly drawing
conclusions based on personal beliefs, insecurities (40%).
9. Lack of documentation of knowledge in the organization (31%); the old fash-
ioned distinction between business and IT (30%); and the “not invented
here” syndrome of stakeholders (27%).
10. Lack of methods, tools, and techniques for supporting collaboration (17%).
11. Constrained project budgets (24%) and the “100% syndrome” of the archi-
tect (16%). Other factors include cases where stakeholders are unqualified
for tasks assigned to them, or have an attitude of “the outsider is the expert
but the outsider does not understand our situation” (3%).
Hindrances 3 – 9 and 11 above arise due to lack of a shared understanding
(among stakeholders) of the aspects pertaining to the problem or challenge the
organization is facing, and aspects pertaining to the (possible) solutions to ad-
dress the problem. Where enterprise architecture development is the appropriate
way of synergizing the formulation and implementation of the possible solutions.
A shared understanding among stakeholders can be created through effective and
efficient collaboration between stakeholders and architects, and as the level of
shared understanding increases, stakeholders are motivated to effectively collab-
orate so as to achieve a successful architecture process [12]. Consequently, issues
highlighted in hindrances 1, 3 – 9, and 11 will be (hopefully) overcome, since
the value of architecture will have become explicit to the stakeholders. There-
fore, the key requirement for addressing hindrances 1, 3 – 9, and 11 above, is
to deploy into the architecture creation process, techniques (or approaches) that
enhance a shared understanding of critical aspects among actors. Hindrance 2
however is beyond the scope of this research, and discussions on how to overcome
organization politics are given in [18]. Hindrance 10 is what this research aims
to address through devising an approach that will minimize occurrences of the
issues reported above.
4.2 Methods Used in Practice to Support Collaborative Tasks
To address collaborative issues in enterprise architecture creation, there was need
to first find out the methods currently used in practice, so as to identify their
48
5th SIKS/BENAIS Conference on Enterprise Information Systems
strengths and weaknesses. The following are the methods enterprise architects
currently use when executing tasks that require involvement of organizational
stakeholders during architecture creation. The percentage of enterprise architects
that use a given method is given in brackets.
– Interviews (90%), traditional facilitated workshops (83%), desk research and
modeling (53%)
– Rapid design workshops (24%), Accelerated Solutions Environment (ASE),
and Innovate (13%). Accelerated Solutions Environment (ASE) is a generic
approach used to create commitment, agreement, and approval by aligning a
large group of critical stakeholders at the start of a business transformation
strategy [1].
– Group Support Systems (13%), gaming (9%)
– Other methods (16%): These other methods include massive emailing, Gen-
eral Enterprise Architecturing (GEA), thematic work groups, peer reviews,
elaborate-review sessions, crowd sourcing or co-creation methodologies. GEA
is a tool that helps directors to underpin strategic decisions, connect several
solutions within the organization, increase the cohesion between the organi-
zation’s units and entities, and effectively achieve business objectives [20].
The use of interviews in architecture creation is discussed in [18], while the
successful use of workshops during architecture creation remains ad hoc and
in the hands of professional facilitators. Since workshops are widely used (as
indicated above) to support collaboration between stakeholders and enterprise
architects, there is need for a standard approach of effectively using them during
architecture creation (see weaknesses of workshops in section 4.3). Standard in
this context implies successful use of the approach without overdependence or
reliance on the presence of professional facilitators, yet with minimal occurrences
of the problematic issues reported in sections 4.1, 4.3, 4.4, and 4.5.
4.3 Strengths and Weaknesses of Methods Currently Used
The strengths and weaknesses of the methods currently used in practice gives
insights into what needs to be done in order to improve collaboration between
stakeholders and architects. For example, knowing weaknesses that need to be
addressed in a particular method helps to improve the method through refining
it or supplementing it with other methods. Architects revealed the following as
the strengths and weaknesses of methods given in section 4.2.
Strengths and Weaknesses of Using Workshops. On the one hand, the
strengths of using workshops are: (1) Workshops are suitable for ensuring en-
gagement of stakeholders, enforcing group decision making, achieving common
agreement on future states, and increasing acceptance and ownership of results.
(2) They yield multiple stakeholder views, and make it possible to identify po-
tential conflicts and then develop a common (or shared and supported) view. (3)
They enable stakeholders to undergo the collaboration experience, where there
49
Proceedings
is intensive communication and mutual understanding, and this builds stake-
holders’ commitment and support. Architects also reported that if workshops
are prepared and conducted properly, they are the efficient way of managing
collaborative tasks during enterprise architecture creation.
On the other hand, the following are the weaknesses of using workshops: (1)
Results of workshops are of an informal character. (2) The quality of output
from a workshop depends on the skills of the facilitator(s) and also on the skills
and knowledge of workshop participants (stakeholders). (3) Information from
workshops is not sufficiently detailed. (4) Workshops lack anonymity. (5) It is
time consuming to prepare and conduct workshops, and to process their results.
(6) In workshops it is difficult to stay focused on the agenda. (7) When not all
key stakeholders are available, workshops slow down decision making, and this
negatively affects the momentum of the architecture development process. (8)
Workshops are often not very structured and allow interpretation freedom to a
large degree. Architects also reported that if GSSs are used within a workshop,
they help in sharing and storing content during the workshop, although using
GSS requires a lot of preparation time.
Strengths and Weaknesses of Using Only Interviews. On the one hand,
the strengths of using interviews are: (1) Interviews are necessary if awareness
is low, since they provide detailed information in a little time, and help the ar-
chitect to get a good understanding of the interviewee’s situation. (2) Interviews
are more useful for investigating individual needs and obstacles since they are
private, focused, and flexible to get ideas. They enable the architect to ask very
specific questions and stakeholders to give true and less socially wanted answers.
They prompt introvert persons to disclose their opinions. (3) They are easy to
prepare and schedule, and are suitable for stakeholders who have limited time
for collaborative activities or sessions. (4) Interviews have, by nature, an active
party (the party answering questions) and a passive party (the party asking the
questions) – hence they do not involve non participating parties or stakehold-
ers. (5) They help to manage stakeholders’ expectations, and to get buy-in and
commitment from stakeholders.
Weaknesses of using only interviews include the following: (1) Conducting
interviews with all key stakeholders and processing results from the interviews
is time consuming. Hence a limited number of people can be reached. It is also
often difficult to get the right person or time or right mindset of a stakeholder.
(2) Interviews give single stakeholder view(s), hence several different opinions
or views and there is lack of agreement (on matters) between stakeholders. It
is therefore very difficult to create a shared, well documented, understandable,
prioritizable, referenceable, discussable, and evolutionary architecture. (3) The
lack of interaction between stakeholders leads to insufficient understanding of
each others concerns and issues. (4) Interviews offer limited opportunities for
creativity among stakeholders.
50
5th SIKS/BENAIS Conference on Enterprise Information Systems
Strengths and Weaknesses of Desk Research and Modeling. Desk re-
search is required in all cases to get a deeper understanding of the issues and
objectives involved in a given organization situation. Weaknesses of desk research
and modeling are: (1) division of work between architects is often difficult; and
(2) preparation and processing of results from desk research is time consuming.
Strengths and Weaknesses of ASE and Rapid Design Workshops. The
speed at which things are done when using ASE and rapid design workshops
is good, and they enable thorough discussion with all stakeholders. Weaknesses
of ASE and rapid design workshops are: (1) ASE is sometimes too fixed on
achieving a specific task; and (2) the depth of problem solving and detailing of
an ASE (as well as a rapid design workshop) is also limited.
4.4 Evaluation of Enterprise Architecture Design Alternatives
In enterprise architecture creation there is need to evaluate enterprise architec-
ture design alternatives i.e. alternative ways in which stakeholders’ concerns can
be addressed in the architecture [10]. Survey findings show that 96% of enter-
prise architects involve organizational stakeholders when evaluating architecture
design alternatives, and the problems these architects face are given below. The
percentage of architects who face each problem is given in brackets.
1. Lack of a truly shared vision and strategy by all stakeholders (53%).
2. Organization politics (40%).
3. Lack of shared agreement, i.e. it is hard to reach a compromise or to get
everyone to agree with the same result due to conflicting agendas (36%). Bi-
ased scores due to personal preferences, agendas, and visions; or not invented
here syndrome (34%).
4. Lack of a clear decision making unit in the organization (36%). It is diffi-
cult to make a very good presentation that leads to decision making; and
is very clear, only containing the essentials and alternatives, and prevents
discussions of too much detail (39%).
5. Stakeholders have limited knowledge of the content, the goals of the archi-
tecture, or how to read an architecture document or view (32%).
6. Bridging the gap between the abstract long term consequences and the more
concrete examples that stakeholders can understand (31%).
7. Time or budget constraints rarely allow sufficient interactions with stake-
holders, so as to break the complexity in evaluating alternatives (24%).
8. It is hard to quantify advantages and disadvantages of alternatives (23%).
Issues 1 and 3 – 7 above can be addressed through creating a shared un-
derstanding (among stakeholders) of the problem and solution aspects of the
organization (as discussed in section 4.1).
51
Proceedings
4.5 Acceptance–Related Challenges Faced by Architects
Successful architecture creation is perceived as designing an architecture, gain-
ing stakeholders’ acceptance of the architecture, and being able to implement
it with their support and commitment [13]. It is reported in [12] that although
96% of enterprise architects closely collaborate with organizational stakeholders
during enterprise architecture creation, 90% of them face challenges when de-
livering products of enterprise architecture creation. From the survey, architects
reported the following as the challenges they face when delivering the architec-
tural products. In brackets, the percentage of architects who face each challenge
is indicated.
1. Some organizations lack a clear decision making unit, leading to a loud ap-
plause but no action (44%). In other cases architecture may be too complex
for the decision making unit or organization maturity level (29%).
2. Since architecture is often perceived to be about only technology, some or-
ganizations lack a governance process for ensuring architecture compliancy
(44%).
3. Architecture conclusions may sometimes conflict with personal ambitions or
agendas (37%).
4. The client organization may change its business plans (37%).
5. Using the right language such that every stakeholder understands the archi-
tecture (34%), and making a short and clear description of the architecture
to all stakeholders within a short time (13%).
6. Lack of commitment from people who were not earlier involved in the archi-
tecture process (24%). In other cases concerns arise from other stakeholders
who were not seen as stakeholders before (21%).
7. Difficulty in translating enterprise architecture products to program start
architectures (17%).
8. Architecture products do not often deliver what has been promised or what
was required (11%).
9. Other issues include cases where stakeholders do not want to (or are not able
to) follow the advised architecture, or where the created architecture shows
that the impact of the business strategy is higher than anticipated (3%).
Challenge 4 can be addressed using guidelines in the architecture require-
ments management phase of TOGAF ADM [19]. In our view, other challenges
listed above are byproducts of the quality of, and the preparations for, stake-
holders’ involvement (i.e. collaboration between enterprise architects and orga-
nizational stakeholders) during architecture creation. For example, delivery of
models that are too complex often indicates that the architecture function is not
properly integrated in the organization and this is due to, among other factors,
the problematic nature of collaboration between architects and stakeholders [15].
4.6 Success Factors For Enterprise Architecture Creation
Since successful enterprise architecture creation is a key motivation for this re-
search, it was vital to find out practitioners’ views on its determinants. At least
52
5th SIKS/BENAIS Conference on Enterprise Information Systems
72% of architects recommend that it is vital to first get the business goals clear
i.e. to know the reasons for creating the architecture or which organization prob-
lems should be solved by creating the enterprise architecture. In addition, 51% of
architects agree that there should be an effective (i.e. understood by, and visible
to, all stakeholders) translation of these business goals and concerns into the
actual architecture because enterprise architecture is purely a means by which
an organization can achieve its goals. Moreover, according to [4,13], translation
of strategy into architecture or desired business operations is perceived as archi-
tecture creation.
According to 71% of architects, it is vital to select the right stakeholders and
get involved with them early in the process. Moreover, 66% of the architects
agree that architects need to have good collaboration with these stakeholders
(e.g. owners or subject matter experts) through regular communication in order
to keep everyone on track and create a strong sense of cooperation and shared
objectives. At least 24% of architects further advise that it is important to create
a situation that enables all stakeholders to experience the development process
through, e.g., scheduling short group sessions that fit in the schedules of key
stakeholders early in the architecture process. At least 48% of architects agree
that it is vital for an organization to have a clear and strong decision making
unit or architecture board which can make decisions and give a clear mandate
for architects to make decisions within agreed boundaries. This is because ar-
chitecture concerns assessment of governorship, guidance, and growth. Lastly,
34% of architects recommend that architects, project manager(s), and business
executive(s) need to respect each others’ roles during the architecture process.
5 Conclusions and Ongoing Work
Findings from the exploratory survey on enterprise architects generally indicate
that although involving organizational stakeholders in enterprise architecture
creation is vital, it results in several issues. These issues indicate the problematic
nature of involving stakeholders in enterprise architecture creation. They also
justify the need for supplementing existing enterprise architecture approaches
with support for collaborative problem solving techniques, so as to create a
shared understanding of the organizational problem and solution aspects among
stakeholders. Findings from the survey give insight on how collaboration between
stakeholders and architects can be improved during architecture creation. There-
fore, survey findings are currently being used as a basis for developing a theory
and a method that will (hopefully to a large extent) address the challenges in
collaborative architecture creation.
References
1. Holland ASE Team. The power of group dialog: Accelerated Solutions Environment.
Utrecht, The Netherlands. (2005)
53
Proceedings
2. Dietz, J.: Architecture Building Strategy into Design (Netherlands Architecture
Forum, Academic Service SDU, The Hague, The Netherlands, 2008). ISBN-13:
9789012580861, http://www.naf.nl.
3. Gartner, Inc.: Gartner Identifies Ten Enterprise Architecture Pitfalls. Gartner
Enterprise Architecture Summit 2009 http://www.gartner.com/it/page.jsp?id=
1159617. Accessed on August 15th 2010.
4. Jonkers, H., Lankhorst, M. M., Doest, H.W. ter, Arbab, F., Bosma, H., Wieringa,
R. J.: Enterprise architecture: Management tool and blueprint for the organisation.
Information Systems Frontiers 8(2) 63–66, (2006)
5. Kish, L.: Survey Sampling. John Wiley and Sons Inc. New York (1965).
6. Lankhorst, M. et al.: Enterprise Architecture at Work: Modelling, Communication,
and Analysis. Springer Verlag Berlin, Heidelberg (2005)
7. Lomax, R. G.: An Introduction to Statistical Concepts for Education and Behavioral
Sciences. Lawrence erlbaum associates. Mahwah, New Jersey. (2001).
8. Mwanza, D., Engestrom, Y.: Managing content in e-learning environments. Britisch
Journal of Educational Technology, 36(3), 453 – 463.
9. Nardi, B.: Context and Consciousness: Activity theory and Human Computer In-
teraction. MIT Press Cambridge, Massachusetts (1996).
10. Nakakawa, A., Bommel, van P., Proper, H. A.: Quality Enhancement in Creating
Enterprise Architecture: Relevance of Academic Models in Practice. In E. Proper,
F. Harmsen, and J.L.G. Dietz (Eds.): PRET 2009, LNBIP 28, 109 - 133, 2009.
11. Nakakawa, A., Bommel, van P., Proper, H. A.: Requirements for Collaborative
Decision Making in Enterprise Architecture. Proceedings of the 4th SIKS/BENAIS
Conference on Enterprise Information Systems. Nijmegen: The Netherlands. (2009)
12. Nakakawa, A., Bommel, van P., Proper, H. A.: Towards a Theory on Collaborative
Decision Making in Enterprise Architecture. Global Perspectives on Design Science
Research. LNCS 6105, 538 – 541, Springer (2010).
13. Op ‘t Land, M., Proper, H.A., Waage, M., Cloo, J., Steghuis, C.: Enterprise Ar-
chitecture - Creating Value by Informed Governance. Berlin, Springer. (2008).
14. Patton, M. Q.: Qualitative evaluation and research methods. SAGE Publications.
Beverly Hills. (1980)
15. Raadt, B. van der, Schouten, S., Vliet, H. van: Stakeholder Perspective of Enter-
prise Architecture. In: Morrison, R., Balasubramaniam, D., and Falkner, K. (eds.)
ECSA 2008. LNCS, vol. 5292, 19–34. Springer, Heidelberg (2008)
16. T. W. Rehkopf, N. Wybolt, Top 10 Architecture Land Mines. IT Professional 5
(6) pp. 36 - 43 (2003). doi:10.1109/MITP.2003.1254967
17. Sallant, P., Dillman d. A.: How to Conduct your Own Survey. John Wiley & Sons,
Inc. New York. ISBN 0471012734 (1994).
18. Spewak, S. H.: Enterprise Architecture Planning: Developing a Blue Print for Data,
Applications, and Technology. New York, John Wiley & Sons Inc (1992)
19. The Open Group Architecture Forum. (2009). TOGAF Version 9. Zaltbommel,
The Netherlands: Van Haren Publishing. ISBN: 978-90-8753-230-7
20. Wagter, R.: Focus on consistency, excel with GEA. http://www.ordina.nl/Visie%
20en%20Ervaring/Themas/Organisatiebesturing/GEA.aspx. Accessed on August
20th 2010
Appendix
54
5th SIKS/BENAIS Conference on Enterprise Information Systems
Radboud University Nijmegen, The Netherlands
An Exploratory Survey on Collaborative Aspects in Enterprise Architecture Creation
Introduction: The aim of this survey is to investigate aspects concerning collaboration between stakeholders and enterprise
architects during enterprise architecture development. Results from this survey will be used to determine the practical relevance of
developing an approach that enterprise architects can use to effectively and efficiently execute enterprise architecting guidelines that
are “collaboration dependent”. Collaboration dependent architecting guidelines are architecture creation tasks, whose successful
completion requires enterprise architects to successfully collaborate with organizational stakeholders.
1. Which architecture method(s) are you currently using? (please mark all options that apply, and specify on option “other”)
[due to space limitations the bullet options have been removed]
2. Do you consider the architecture development process to be collaborative in nature?
1. YES 2. NO
3. If YES to question (2) above, which method do you use to manage collaborative tasks during architecture creation? (please
mark all options that apply, and specify on option “other”)
[due to space limitations the bullet options have been removed]
4. Please give a strength and/or weakness of the method(s) you use to manage collaboration during architecture creation.
………………………………………………………………………………………………………………………………………
………………………………………………………………….......……………………………………………………………….
5. Which factors hinder effective collaboration between architects and key stakeholders during architecture creation? (please mark
all options that apply, and specify on option “other”)
[due to space limitations the bullet options have been removed]
6. Do you also engage organisation stakeholders during the evaluation of architecture design alternatives?
1. YES 2. NO
7. If YES to question (6) above, which type of organisation stakeholders do you engage in the evaluation of architecture design
alternatives? (please mark all options that apply, and specify on option “other”)
[due to space limitations the bullet options have been removed]
8. Which method do you use to evaluate architecture design alternatives with stakeholders? (please mark all options that apply,
and specify on option “other”)
[due to space limitations the bullet options have been removed]
9. Which challenges do you face during the evaluation of architecture design alternatives? (please mark all options that apply, and
specify on option “other”)
[due to space limitations the bullet options have been removed]
10. Do you face any challenges related to acceptance of the products you deliver after architecture creation?
1. YES 2. NO
11. If YES to question (10) above, which of the following are examples of such challenges? (please mark all options that apply, and
specify on option “other”)
[due to space limitations the bullet options have been removed]
12. From your experience, which of the following do you consider as success factors for architecture creation? (please mark all
options that apply, and specify on option “other”)
[due to space limitations the bullet options have been removed]
13. We are developing a method to manage collaborative tasks in enterprise architecture. We will be conducting another
questionnaire survey with the aim of validating the design of the method. Would you be interested in participating in that
survey?
a. NO b. YES (please give your contact) ………………………………….
14. We will also carry out an experiment on the designed method, would you be interested in participating in the validation
experiment of such a method?
a. NO b. YES (please give your contact) …………………………………
Fig. 1. Exploratory Questionnaire Survey
55