Although there are many frameworks for Enterprise Architecture (EA), they focus mainly on the holistic structure of an enterprise and rarely take decision making into account. This is surprising, given the large role that (design) decision making seems to play in EA. A lack of empirical work o ering insight into decision making in practice might be the cause of this. To address this knowledge gap we report on some rst insights from an empirical study on how the practice of decision making in EA is perceived by professional enterprise architects. We sketch an outline of designing and decision making in contemporary EA, including a high level of politicization, emotional decision making, and subordination to business management. We discuss the implications of these ndings for further research and work centered around EA.
Enterprise Architecture (EA) is not just about modeling static descriptions of
an enterprise, but also about steering it towards a desired future state. This is
re ected in The Open Group's description of EA in TOGAF [
What is it like to actually work on decision making in EA? How do these
highlevel de nitions translate to the actual decision making practice? There is work
that focuses on what makes an architect a good architect { but those studies often
still leave in the middle just what the investigated people do in a regular day's
work (cf. [
Gaining a deeper insight on how EA practitioners are involved in decision making contributes to several aspects, both practice and research oriented: 1) Understanding the way they make decisions. First, an increased understanding of how practitioners make decisions and what they consider to be and not be part of their tasks can serve as an empirical grounding for other theorybacked e orts to improve the decision making process.
2) Understanding the issues they have in decision making. Second, both by explicitly asking what aspects practitioners perceive to be most critical during their decision making process and investigating the characteristics of that process, we can have a more empirically grounded list of focal points for research (and practical) e orts to address.
3) Understanding what their experience is similar to. Finally, by
understanding practitioners' perceptions, we can also investigate how similar and di erent
they perceive decision making in other related elds to be, like for example
software or information architecture. For example, some decision capturing
framework for EA bases themselves on theory and foundations from software
architecture without rationalizing why they are applicable to EA. Other researchers
continue to build in such frameworks (cf. [
Our research objective is to study these aspects and in doing so elicit data that gives insights into the general practice of EA as well. We will do so by performing qualitative work with a diverse amount of participants active as enterprise architects. 2.1
We speci cally targeted EA practitioners by posting an invitation to the study on several LinkedIn groups centered around (the use of) Enterprise Architecture, EA methods, or tools (e.g., groups such as Enterprise Architecture, EA Forum, EA Group, The EA Network, ArchiMate, TOGAF). Doing so we speci cally attempted to target a diverse number of participants, from both geographical as professional background, attempting to prevent the limited professional context of earlier studies focusing on single companies or geographical areas. Participants were asked to ll out the questionnaire online, and were o ered no reward except a copy of the research results, when available. 2.2
The study consisted of a questionnaire with three main parts, building a professional pro le of the participant, understanding the di culties they face in EA decision making, and testing how they feel about certain aspects of the decision making process. The pro le of the participants was built based upon the following questions.
{ What are your main activities as an Enterprise Architect during the decision making process? { What modeling languages and techniques do you use? { Are you internal or external to the company you perform EA activities for? { Do you have experience with other architecture elds such as software or information architecture? If so, to what degree do you nd the decison making process to be di erent than in Enterprise Architecture?
These are followed by more speci c open questions about the di culties they face in their role as an architect, their involvement and views on design decisions, and what kind of data they use.
{ To what degree are you involved in the process of making EA design decisions? { What makes an EA design decision di cult for you? { Related to the last question, what are the most important (or critical) aspects of an EA design decision for you? { What kinds of input do you use for EA design decisions, and of those, do you favor qualitative or quantitative data to base your decisions on? Finally, we asked participants to judge to what extent they agreed with a number of statements on a 5 point Likert scale (ranging from `strongly disagree' to `strongly agree'). These were created to give insight into how participants feel about the decision making aspects detailed below.
{ Where the authority resides: is there a di erence between who makes (i.e., prepares) the decisions and who takes (i.e., is responsible for) them? { Collaboration in decision making: is the decision making process a collaborative e ort or not, and to what degree so? { Decision re nement: are decisions iterated upon and re ned before they are decided upon, and can they be reconsidered and revised afterwards? { Data used to support decisions: is there a preference for particular types of data, and is the desired data available in the rst place? The results from all open questions were gathered and classi ed per question. We then used progressive coding to identify common threads between participants, both on single word and phrase basis (e.g., multiple occurrences of the term `time constraints' for the question what makes EA design decisions di cult). This coding was used to build an overview of the general trend for the answers. After doing so we went through the answers again to nd answers that speci cally con icted with this trend, and use them to discuss the attitudes of the participants towards the questionnaire. To estimate the general tendency for each answer in the Likert scale we calculated the median of each question's answers (given the ordinal nature), which we used to determine whether the majority of participants had a polarized (i.e., strong agreement or disagreement) or neutral attitude towards them. 3
We received 35 full responses to the questionnaire, with many more partial or empty responses discarded. The textual answers were analyzed and coded, and will be discussed in more detail in Sec. 4. There was no strong bias towards external or internal employees, with 17 indicating being external to the companies they provided EA services for, 15 being internal, and the remaining 3 gave no answer. The location of the participants was diverse, with many countries represented. A total of 18 participants were from (> 5) European countries, 9 from North America, 3 from South America, 2 from Australia, 1 from Africa, 1 from Middle East, and nally 1 from an unknown origin.
For the Likert scale, we selected the statements with strong responses (either positive and negative), and emphasized those with a low response variation in their responses (indicating consensus among the participants). These statements are not used as statistically generalizable ndings, but as veri cation for the analysis of the qualitative data, and to ensure they both corroborate each other. I take decisions after consulting others Decisions are taken by a committee Time constraints do not allow me to consider all decision alternatives Decisions are often re ned I prefer discussions with people to base my decisions on It is easier to make decisions that are based on hard data Discussions with stakeholders o er more insight than numerical data In this section we give an outline of contemporary Enterprise Architecture as perceived by practitioners, describing the dominant views held by participants for the di erent aspects we studied. We will try as much as possible to let the participants speak for themselves, showing their actual responses. Most participants indicate that the majority of their time is spent on working towards future states of the enterprise, less so on the current state (e.g., modeling it, analyzing it). This is in some contrast to the TOGAF de nitions which give a clear two-fold interpretation of EA and imply equal importance of those parts. As stated, they spend a lot of time and e ort to:
\Seek the strategy, the strategic goals (qualitative) and objectives (quantitative) and then derive the information required to achieve them." To make it clear that the future is of particular importance, many other participants stated similar foci:
\. . . and then use those as inputs to model a set of potential courses of action."; \. . . providing a recommended course of action if possible"; \Helping investment decision makers consider alternative future change to their business, and monitoring the impact of the change as its being created and implemented."
This focus on future states can be explained by the answers of some participants where it is clear that models and data already exist, and need to be integrated and used towards the future state. The point of these artifacts needing to be harmonized into a form consumable for strategically responsible stakeholders brings forth the other main activity that architects seem to actually do while working on this future state: creating support and convincing management of the use of the design direction to go in.
\Creating awareness and commitment at management (decision-makers level for a speci c solution"; \Creating support within the enterprise for a speci c solution or speci c solution paradigm so that the decisionmakers are confronted with this paradigm"
Already in describing their main activities it becomes clear that while Enterprise Architects work on the future state of an enterprise, there is a clear di erence between those who propose (designs, decisions, strategies for) the future of the enterprise, and those who have the power to actually take it there, an aspect that will be explored more in Sec 4.5. See, for example: \Often I frame the decisions to be made and then propose various options with supporting data. Usually the option that I feel is the best is clear through that data. However, the senior leaders who own the decisions need to be the ones who actually make it." (emphasis added) 4.2
When asked about the modeling languages and techniques participants used in their daily work, the whole gamut of languages came by. The usual suspects such as UML, BPMN, ArchiMate (for Western European EAs, at least) were represented, as well as long existing techniques like Zachman, Flowcharts, IDEF languages, and so on, but just as well less known languages such as IBM and Oracle suites, ScIAM, SAINT, DNDAF, SCOR, RDF, Rummler-Brache, and so on. Multiple participants make a distinction between the audience of models and information, and that a distinct purpose followed from that: modeling to capture knowledge, and modeling to communicate knowledge. Practically speaking, very little formal or complicated modeling languages and techniques were actually shown to the business stakeholders when communicating with them: \Primary tool for communicating is PowerPoint."; \. . . but really powerpoint, excel and visio are more suitable for a non-technical audience."; \In dialogue with management I do not use modeling languages or techniques." 4.3
Designing the future state of an Enterprise is considered a systematic activity by many, and as such useful data to base those designs on is needed. To do so, however, data is needed to base all those designs (and design decisions) on. This ranges from quantitative data about the operation of the enterprise, to qualitative data involving the actual people making up the enterprise. Both kinds of data are needed:
\You need both sets of data. The challenge is introducing a disciplined process for capturing both types of input to align them for one decision and support dependent decisions in other areas." 4.4
Many participants had experience working in other digital architecture elds (e.g, software, information, data architecture). One participant argued that the primary di erence between these elds arose simply from the professional culture of their domain. Going into detail on the di erences between EA and those elds considered more technical like Software Architecture, participants generally found EA to have a broader focus and depth, with the scope and impact of design decisions potentially far greater in EA. These di erences were often explained by EA having a much stronger business focus than comparable elds, from which also a higher abstraction level followed. While some participants state that software architecture is not fundamentally di erent from EA (at least in regards to the decision making process), they do showcase the di erent nature of achieving support for a future state or design, corroborating points made earlier by other participants that EA has many more human and `soft' aspects that need to be dealt with:
\EA decision making process has more political, personal etc. in uences. Demands more communication and soft-skills. Software architecture decision making is (much) more straightforward fact based." 4.5
In the previous aspects we have already seen hints that while Enterprise Architects are consistently involved in designing and proposing future states of an enterprise, they are not necessarily the ones to take an enterprise there. Most architects seem to choose for future designs or (viable) future states in cooperation with business stakeholders, and then communicate those to management stakeholders who have the actual decision taking power:
\An architect (EA or otherwise) is responsible for providing recommendations not decisions to the Board. The Board owns the accountability for decisions." 4.6
As participants stated already in other aspects, EA design decisions are not simple to make, especially when compared to elds they perceive as more technical and rational like software architecture. The reasons for this are diverse, ranging from the involvement of a large number of stakeholders, di culty communicating between people with di erent backgrounds, and dealing with con icting goals and lack of information. However, besides all these aspects, a di culty seemingly more speci c to EA is shared by many participants, the politics involved in nding support for moving an enterprise to a particular future state: \The politics. Making a design decision based on principles and best practices is not di cult. Making it such that my stakeholders see the value in where I'm going, and see the bene t of going there with me, is much more di cult and interesting." 4.7
After understanding what aspects are most di cult about design decisions in EA, we also explicitly asked participants what aspects they found most critical to making decisions. The main response here is in line with the view of EA being highly politicized, as the most critical aspect to most EA design decisions, and thus to reaching a proposed future state of an enterprise were nding the right arguments to convince the right people at the right time, and keeping them convinced:
\The most critical aspects of an EA design decision: having the right rational arguments for which conservative IT operators and managers are sensitive for, having the right emotional and business image/impact for the business, getting the right position in project planning" 5 5.1
From the outline that we have sketched, we see several things that research in EA can focus on to provide more support for the decision making process in EA:
Supporting the way they make decisions. Our results indicate that discussions
between architects and business stakeholders play a large role in the EA
decision making process. This supports the idea that dialogical skills are important
for enterprise architects, so that they can \interact with those who are di
erent, antagonistic, or even aggressive towards them". [
In a di erent direction, the nding that many EA practitioners make a distinction between capturing and documenting knowledge in models and communicating it to business stakeholders means that we can be clearer about the presumed users of modeling languages: they might be only used by experts. This has implications for the design of such languages, how complex they can be, how intuitive their interfaces should be, as novice users or non-IT literature users are, at least in an EA context, likely not active users. Instead, they are communicated the knowledge that architects captured in such models by di erent means such as Powerpoint slides, and informal drawings.
Dealing with the issues they have in decision making. Ensuring that all
stakeholders have the same understandings, and keeping the `buy-in' of stakeholders
on those understandings is one of the critical aspects pointed out by our
participants. On the one hand this o ers support for such e orts like ArchiMate and
other providers of complete and coherent EA approaches. On the other hand
given the plethora of used modeling languages and techniques, it stresses the
need of research investigating the di erent conceptual understandings that
people have and how to best deal with and accommodate them [
Realizing EA is not interchangeable with all other `A'. How the decision making process di ers from e.g., software architecture presents a number of implications for research, especially of a design nature, whether recommender systems, ontologies, or information capturing schemes. Given the perceived di erences between EA and SA practice, frameworks created by researchers should not just assume the two are the same and use SA foundations to build EA frameworks. Such frameworks need to at least account for the perceived extra dimensions of political motivations in decisions, emotions that need to be addressed and the large part that discussions play in the decision making process. 6
We have given an outline of the practice of design and decision making in contemporary EA based on an in-depth qualitative study of how enterprise architects perceive their professional work. This has led to a number of insights, namely that the practice of EA is fundamentally perceived as a consultancy service to business, with less rational decision making than other architecture elds, and a highly politicized working context.
Acknowledgements. Marc van zee is supported by the National Research Fund, Luxembourg (Rational Architecture project).