=Paper=
{{Paper
|id=Vol-1497/sp3
|storemode=property
|title=Insights from a Study on Decision Making in Enterprise Architecture
|pdfUrl=https://ceur-ws.org/Vol-1497/PoEM2015_ShortPaper3.pdf
|volume=Vol-1497
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/LindenZ15
}}
==Insights from a Study on Decision Making in Enterprise Architecture==
https://ceur-ws.org/Vol-1497/PoEM2015_ShortPaper3.pdf
Insights from a Study on Decision Making in
Enterprise Architecture
Dirk van der Linden1 and Marc van Zee2
1
University of Haifa, Israel
2
University of Luxembourg, Luxembourg
{djt.vanderlinden,marc.vanzee}@gmail.com
Abstract. Although there are many frameworks for Enterprise Archi-
tecture (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 offering insight into decision making in practice
might be the cause of this. To address this knowledge gap we report on
some first insights from an empirical study on how the practice of deci-
sion 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 findings for further research and work centered around EA.
Keywords: Enterprise Architecture, professional practice, empirical study,
practitioner perception, qualitative study
1 Introduction
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
reflected in The Open Group’s description of EA in TOGAF [15], where a two-
fold definition is given being: (1) “a formal description of a system, or a detailed
plan of the system at the component level, to guide its implementation”, and
(2) “The structure of components, their inter-relationships, and the principles
and guidelines governing their design and evolution over time”. This second part
describing normative principles and guidelines to affect an enterprise’s design is
where much of the architecting actually happens, as is reflected in the plethora
of other EA definitions focused on it, such as Hoogervorst’s view [5] of EA be-
ing “a consistent set of design principles and standards that guide design”, and
Lankhorst’s view [8] describing it as the “realization of an enterprise’s organiza-
tional structure, business processes, information systems, and infrastructure”.
What is it like to actually work on decision making in EA? How do these high-
level definitions 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
S. España J. Ralyté, P. Soffer, J. Zdravkovic and Ó. Pastor (Eds.):
PoEM 2015 Short and Doctoral Consortium Papers, pp. 21-30, 2015.
22 D. van der Linden and M. van Zee
work (cf. [13,4]). As such, while prescribing skills and characteristics architects
ought to have, they offer little empirical insight into what architects currently do,
especially in regards to decision making. Other studies do attempt to investigate
how EA (or parts of it) is done, but are limited to understandings of the authors
themselves from prior or concurrent industrial roles (cf. [7], or anecdotal evidence
gathered in industrial cases (cf. [3]). Some studies are limited to specific literature
(cf. [2]). Some studies investigate actual companies, but usually in limited scope,
for example a single aspect of Federal Government [14], Czech companies [10].
Comparing the findings of such studies in order to gain a general understanding
of the EA practice brings additional issues of interpretation along. Attempts
at understanding how EA is perceived by those practicing it are for example
Dankova [1] and Mentz et al. [9]. However, Dankova’s work is limited in this
regard by being essentially a corpus analysis of existing definitions. Mentz et al.’s
more ambitious attempt incorporating hermeneutic phenomenology to compare
understandings of EA between practitioners and researchers also only focuses
on existing definitions and frameworks and does not actively investigate the
views these people have themselves. Thus, investigating the perception of the
EA decision making in practice remains an open topic.
1.1 The Use of Understanding Practitioner’s Perceptions
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 under-
standing 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 theory-
backed efforts 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 pro-
cess, we can have a more empirically grounded list of focal points for research
(and practical) efforts to address.
3) Understanding what their experience is similar to. Finally, by understand-
ing practitioners’ perceptions, we can also investigate how similar and different
they perceive decision making in other related fields to be, like for example soft-
ware or information architecture. For example, some decision capturing frame-
work for EA bases themselves on theory and foundations from software archi-
tecture without rationalizing why they are applicable to EA. Other researchers
continue to build in such frameworks (cf. [6,20]), without questioning that, lead-
ing to a continued lack of proper grounding (and potentially validity) of the
design artifacts offered to practitioners. Insight into what software architects do,
and feel they should do [12,11] can be used to compare how similar these fields
are experienced to be.
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.
Insights from a Study on Decision Making in Enterprise Architecture 23
2 Method
2.1 Participants
We specifically 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 specifically
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 fill out the questionnaire online, and were offered no reward except
a copy of the research results, when available.
2.2 Procedure
The study consisted of a questionnaire with three main parts, building a profes-
sional profile of the participant, understanding the difficulties they face in EA
decision making, and testing how they feel about certain aspects of the deci-
sion making process. The profile 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 fields such as software or in-
formation architecture? If so, to what degree do you find the decison making
process to be different than in Enterprise Architecture?
These are followed by more specific open questions about the difficulties 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 deci-
sions?
– What makes an EA design decision difficult 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 difference between who makes (i.e.,
prepares) the decisions and who takes (i.e., is responsible for) them?
24 D. van der Linden and M. van Zee
– Collaboration in decision making: is the decision making process a collabo-
rative effort or not, and to what degree so?
– Decision refinement: are decisions iterated upon and refined 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 first place?
Table 1: Used Likert Scale Statements.
# Group decision-making, Decision refinement Supporting data
Decision authory
1 I take a decision by myself Time constraints do not al- I prefer numerical data to
low me to consider all deci- base my decisions on
sion alternatives
2 I take decisions after con- I take a decision without I prefer discussions with
sulting others knowing exactly what the people to base my decisions
outcome will be on
3 Decisions are taken by a Decisions often have to be It is easier to make de-
committee reconsidered, which also af- cisions that are based on
fects other decisions hard data
4 Decisions are taken by a Decisions are often refined In general there is sufficient
group of architects numerical data available to
make decisions
5 The final decision comes When I make a decision, it Discussions with stakehold-
down to a single person is final ers offer more insight than
numerical data
2.3 Analysis
The results from all open questions were gathered and classified per question.
We then used progressive coding to identify common threads between partici-
pants, both on single word and phrase basis (e.g., multiple occurrences of the
term ‘time constraints’ for the question what makes EA design decisions diffi-
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 find answers that
specifically conflicted 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 ma-
jority of participants had a polarized (i.e., strong agreement or disagreement) or
neutral attitude towards them.
3 Results
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 compa-
nies they provided EA services for, 15 being internal, and the remaining 3 gave
Insights from a Study on Decision Making in Enterprise Architecture 25
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 finally 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 findings, but as verification for the
analysis of the qualitative data, and to ensure they both corroborate each other.
Table 2: Strongly polarized (≥ 4 and ≤ 2, pos and neg) Likert Scale Items. Statements
in emphasis had particularly low variation and were thus most strongly (dis)agreed on.
Statement Polarity
I take a decision by myself
When I make a decision, it is final Negative
In general there is sufficient numerical data available to make decisions
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 refined Positive
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 offer more insight than numerical data
4 A First Outline of Contemporary EA
In this section we give an outline of contemporary Enterprise Architecture as
perceived by practitioners, describing the dominant views held by participants
for the different aspects we studied. We will try as much as possible to let the
participants speak for themselves, showing their actual responses.
4.1 Main Activities as an Enterprise Architect
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 definitions 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 effort 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:
26 D. van der Linden and M. van Zee
“. . . 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 par-
ticipants 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 stakehold-
ers 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 specific solution”; “Creating support within the enterprise for
a specific solution or specific solution paradigm so that the decision-
makers are confronted with this paradigm”
Already in describing their main activities it becomes clear that while En-
terprise Architects work on the future state of an enterprise, there is a clear
difference between those who propose (designs, decisions, strategies for) the fu-
ture 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 de-
cisions need to be the ones who actually make it.” (emphasis added)
4.2 Used Modeling Languages and Techniques
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 audi-
ence.”; “In dialogue with management I do not use modeling languages
or techniques.”
Insights from a Study on Decision Making in Enterprise Architecture 27
4.3 Data to be Used
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 disci-
plined process for capturing both types of input to align them for one
decision and support dependent decisions in other areas.”
4.4 Perceived Differences to Other Architecture Fields
Many participants had experience working in other digital architecture fields
(e.g, software, information, data architecture). One participant argued that the
primary difference between these fields arose simply from the professional cul-
ture of their domain. Going into detail on the differences between EA and those
fields considered more technical like Software Architecture, participants gener-
ally found EA to have a broader focus and depth, with the scope and impact
of design decisions potentially far greater in EA. These differences were often
explained by EA having a much stronger business focus than comparable fields,
from which also a higher abstraction level followed. While some participants
state that software architecture is not fundamentally different from EA (at least
in regards to the decision making process), they do showcase the different na-
ture 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. influ-
ences. Demands more communication and soft-skills. Software architec-
ture decision making is (much) more straightforward fact based.”
4.5 Involvement in the Decision Making Process
In the previous aspects we have already seen hints that while Enterprise Ar-
chitects 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 cooper-
ation 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 recom-
mendations not decisions to the Board. The Board owns the account-
ability for decisions.”
28 D. van der Linden and M. van Zee
4.6 What makes EA Design Decisions Difficult?
As participants stated already in other aspects, EA design decisions are not sim-
ple to make, especially when compared to fields 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, difficulty communicating
between people with different backgrounds, and dealing with conflicting goals
and lack of information. However, besides all these aspects, a difficulty seem-
ingly more specific to EA is shared by many participants, the politics involved
in finding support for moving an enterprise to a particular future state:
“The politics. Making a design decision based on principles and best
practices is not difficult. Making it such that my stakeholders see the
value in where I’m going, and see the benefit of going there with me, is
much more difficult and interesting.”
4.7 Most Critical Aspect(s) of EA Design Decisions
After understanding what aspects are most difficult 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 finding 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 Reflection
5.1 Implications for Research
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 deci-
sion making process. This supports the idea that dialogical skills are important
for enterprise architects, so that they can “interact with those who are differ-
ent, antagonistic, or even aggressive towards them”. [4]. This is an important
aspect that seems to set the decisions making process in EA apart from deci-
sion making in other domains such as SA. Recent EA decision rationalisation
frameworks (e.g., [20,18], both theoretical frameworks based on formal logic) di-
rectly use insights from related domains such as SA (see more on this in point
Insights from a Study on Decision Making in Enterprise Architecture 29
3). Therefore, the discussions between stakeholders are not part of these frame-
work. Given our results, we believe that in order to truthfully model the EA
decision process, these framework would benefit from an extension such that the
discussions between stakeholders are part of the rationalization of decisions as
well. We report initial finding of applying argumentation to parts of enterprise
architecture elsewhere [19], and we aim to further extend it in future work.
In a different direction, the finding that many EA practitioners make a dis-
tinction between capturing and documenting knowledge in models and commu-
nicating 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 communi-
cated the knowledge that architects captured in such models by different means
such as Powerpoint slides, and informal drawings.
Dealing with the issues they have in decision making. Ensuring that all stake-
holders have the same understandings, and keeping the ‘buy-in’ of stakeholders
on those understandings is one of the critical aspects pointed out by our partic-
ipants. On the one hand this offers support for such efforts 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 different conceptual understandings that peo-
ple have and how to best deal with and accommodate them [16,17]. Furthermore,
as the most mentioned issue of day to day practice is the politics of dealing with
all involved stakeholders, our study points out the need for more research into
understanding the political processes involved in the EA process.
Realizing EA is not interchangeable with all other ‘A’. How the decision mak-
ing process differs from e.g., software architecture presents a number of implica-
tions for research, especially of a design nature, whether recommender systems,
ontologies, or information capturing schemes. Given the perceived differences
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 Conclusion & Outlook
We have given an outline of the practice of design and decision making in contem-
porary 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 fields, and
a highly politicized working context.
Acknowledgements. Marc van zee is supported by the National Research
Fund, Luxembourg (Rational Architecture project).
30 D. van der Linden and M. van Zee
References
1. Dankova, P.: Main aspects of enterprise architecture concept. Economic Alterna-
tives Journal (1), 102–114 (2009)
2. Du Preez, J., van der Merwe, A., Matthee, M.: Enterprise architecture schools of
thought: An exploratory study. In: EDOCW 2014. pp. 3–12. IEEE (2014)
3. van Gils, B., van Dijk, S.: The practice of enterprise architecture: experiences,
techniques, and best practices. BiZZdesign Academy (2014)
4. Gotze, J.: The changing role of the enterprise architect. In: EDOCW 2013. pp.
319–326. IEEE (2013)
5. Hoogervorst, J.: Enterprise architecture: Enabling integration, agility and change.
International Journal of Cooperative Information Systems 13(03), 213–233 (2004)
6. Jugel, D., Schweda, C.M., Zimmermann, A.: Modeling decisions for collaborative
enterprise architecture engineering. In: Advanced Information Systems Engineering
Workshops. pp. 351–362. Springer (2015)
7. Kaisler, S.H., Armour, F., Valivullah, M.: Enterprise architecting: Critical prob-
lems. In: System Sciences, 2005. HICSS’05. Proceedings of the 38th Annual Hawaii
International Conference on. pp. 224b–224b. IEEE (2005)
8. Lankhorst, M.: Communication of enterprise architectures. In: Enterprise Archi-
tecture at Work, pp. 69–84. Springer (2009)
9. Mentz, J., Kotzé, P., van der Merwe, A.: A comparison of practitioner and re-
searcher definitions of enterprise architecture using an interpretation method. Ad-
vances in Enterprise Information Systems II pp. 11–26 (2012)
10. Nedomová, L., Maryska, M., Doucek, P.: The enterprise architect role–and its
mission in corporate information and communication technology–a czech study.
Journal of Applied Economic Sciences pp. 88–100 (2014)
11. Sherman, S., Hadar, I.: Toward defining the role of the software architect: An
examination of the soft aspects of this role. In: 8th International Workshop on
Cooperative and Human Aspects of Software Engineering (CHASE 2015) (2015)
12. Sherman, S., Unkelos-Shpigel, N.: What do software architects think they (should)
do? In: Iliadis, L., Papazoglou, M., Pohl, K. (eds.) Advanced Information Systems
Engineering Workshops, vol. 178, pp. 219–225. Springer (2014)
13. Steghuis, C., Proper, E.: Competencies and responsibilities of enterprise architects.
In: Dietz, J., Albani, A., Barjis, J. (eds.) Advances in Enterprise Engineering I,
vol. 10, pp. 93–107. Springer (2008)
14. Strano, C., Rehmani, Q.: The role of the enterprise architect. Information Systems
and e-Business Management 5(4), 379–396 (2007)
15. The Open Group: TOGAF Version 9.1. Van Haren Publishing, 10th edn. (2011)
16. van der Linden, D., Hoppenbrouwers, S.: Challenges of identifying communities
with shared semantics in enterprise modeling. In: Sandkuhl, K., Seigerroth, U.,
Stirna, J. (eds.) The Practice of Enterprise Modeling, Lecture Notes in Business
Information Processing, vol. 134, pp. 160–171. Springer, Berlin, Germany (2012)
17. van der Linden, D., Proper, H.A.: On the accommodation of conceptual distinctions
in conceptual modeling languages. In: Fill, H.G., Karagiannis, D., Reimer, U. (eds.)
Modellierung 2014. pp. 17–32. Lecture Notes in Informatics, GI (2014)
18. van Zee, M.: Rational Architecture = Architecture from a Recommender Perspec-
tive. In: Proceedings of the International Joint Conference on Artificial Intelligence
(Doctoral Consortium) (2015)
19. van Zee, M., Ghanavati, S.: Capturing Evidence and Rationales with Requirements
Engineering and Argumentation-Based Techniques. In: Proceedings of the 26th
Benelux Conference on Artificial Intelligence (2014)
20. van Zee, M., Plataniotis, G., van der Linden, D., Marosin, D.: Formalizing enter-
prise architecture decision models using integrity constraints. In: CBI 2014. vol. 1,
pp. 143–150. IEEE (2014)