Challenges of Involving Stakeholders When Creating Enterprise Architecture

Abstract

Although researchers report challenges that occur during enterprise architecture development (in general), there is lack of an elaborate description of those that occur during enterprise architecture creation - particularly if organizational stakeholders are to be deeply involved. Yet understanding challenges of involving organizational stakeholders when creating enterprise architecture is a prerequisite for devising 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 enterprise architecture creation, although 96% of architects closely collaborate with organizational stakeholders during enterprise architecture creation.

Introduction

Since architecture “is the normative restriction of design freedom”[ 2 ], enterprise architecture can be conceived as a normative instrument (in the form of principles, 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 impact; 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 ]. However, 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).

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 organization’s business goals [ 13 ], investigations of these challenges were limited to creating 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 architects; 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 architecture products; and key determinants for successful enterprise architecture creation. A sample of 70 enterprise architects participated in this survey.

This paper discusses findings from this survey. The findings generally indicate 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 conducted 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 architecture 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 interpreted 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)

Subjects (i.e. those involved in carrying out the activity) 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 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.

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.

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. 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 enterprise architects and organizational stakeholders. Moreover, several researchers and practitioners (e.g. [ 3,6,13,19,18,15,16 ]) have advocated for the need for collaboration 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 stakeholders and enterprise architects during architecture creation. Therefore, there was need to undertake an exploratory survey so as to investigate the collaborative 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 organizational stakeholders in the enterprise architecture creation process. The target respondents in this survey were enterprise architects. Self administered questionnaires 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 occurs 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: s = z2(p(1 − p))

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 administered 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) sampling. 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 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 architecture 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 behaviors (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 because architects mainly talk about abstract concepts and are unable to explain 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 architecture on the organization’s sub levels. This is because some people find it difficult to imagine a new situation (47%). 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 architecture, stakeholders’ perception about architecture (e.g. architecture is perceived to be about only technology), and the gap between (business) operations 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 stakeholders, 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 fashioned 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 architect (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 address 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 collaborate 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. Therefore, 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 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, General 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 organization’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 engagement 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 potential conflicts and then develop a common (or shared and supported) view. (3) They enable stakeholders to undergo the collaboration experience, where there is intensive communication and mutual understanding, and this builds stakeholders’ 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 architect 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 stakeholders. (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.

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 architecture design alternatives i.e. alternative ways in which stakeholders’ concerns can be addressed in the architecture [ 10 ]. Survey findings show that 96% of enterprise 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%). Biased 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 difficult 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 architecture, 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 stakeholders, 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 understanding (among stakeholders) of the problem and solution aspects of the organization (as discussed in section 4.1). 4.5

Acceptance–Related Challenges Faced by Architects

Successful architecture creation is perceived as designing an architecture, gaining 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 delivering products of enterprise architecture creation. From the survey, architects reported the following as the challenges they face when delivering the architectural 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 applause 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 organizations 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 architecture (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 architecture 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 requirements management phase of TOGAF ADM [ 19 ]. In our view, other challenges listed above are byproducts of the quality of, and the preparations for, stakeholders’ involvement (i.e. collaboration between enterprise architects and organizational 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 research, it was vital to find out practitioners’ views on its determinants. At least 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 problems 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 architecture 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 architecture 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. Therefore, 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.

Appendix

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.

References

1. Holland ASE Team. The power of group dialog: Accelerated Solutions Environment . Utrecht, The Netherlands. ( 2005 )

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 Interaction . 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 Architecture - 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 Enterprise 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

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 ) …………………………………