G. Feuerlicht and W. Lamersdorf (Eds.): ICSOC 2008, LNCS 5472, pp. 388–399, 2009.
© Springer-Verlag Berlin Heidelberg 2009
A Contingency Approach to Enterprise Architecture
Christian Riege and Stephan Aier
Institute of Information Management, University of St. Gallen,
9000 St. Gallen, Switzerland
Abstract. Enterprise Architecture (EA) and methods for the design and em-
ployment of EA significantly contribute to the transparency, consistency and
eventually to the flexibility of an organization. However, there is hardly any
“one-size-fits-all” EA method that is equally effective for a broad range of
transformation projects or in a large number of different contexts. Based on an
empirical analysis, this paper identifies three relevant EA contingency factors as
well as three dominating EA application scenarios as a basis for a situational
EA method engineering taking these into account.
Keywords: Enterprise Architecture, Method Engineering, Contingency Factors.
Enterprise architecture (EA) describes the fundamental structure of an enterprise [28,
33] and supports transformation by offering a holistic perspective on as-is as well as
to-be structures and processes .
EA is widely accepted as an approach to manage transformations and to foster
IT/business alignment [7, 22, 30]. In order to guide this transformation, EA methods
are needed. While there are a number of EA methods available, e.g. [21, 31], a classi-
fication of methods is needed in order to understand in which situation a certain
method is appropriate, how a method should be adapted to a certain situation, or for
which situations new methods have to be developed. This is based on the assumption
that there is no “one-size-fits-all” method, but that, depending on a certain situation,
different methods—or at least different configurations or adaptations of a method—
are needed. In order to develop an understanding of such situations, relevant contin-
gency factors need to be identified which have an impact on the realization of EA.
As a foundation for situational EA method engineering and to continue the discus-
sion started in  this paper further particularizes current realization approaches of
EA. EA method engineering is an evolving discipline, which additionally requires
outlining typical EA application scenarios. For this purpose our contribution is based
on an exploratory analysis shaping current EA approaches, EA contingency factors as
well as important EA application scenarios.
The remainder of this paper is organized as follows: Section two provides
an overview of the theoretical background and related work. The discussion of the
A Contingency Approach to Enterprise Architecture Method Engineering 389
contingency factors in situational method engineering is reflected, and a short review
on the state-of-the-art of enterprise architecture is given. Section three describes the
details of the explorative empirical analysis aiming at identifying current EA realiza-
tion approaches and section four outlines typical EA application scenarios. The paper
ends with a conclusion and an outlook on future research activities in section five.
2 Theoretical Background and Related Work
Enterprise architecture literature provides a broad range of results that may be
grouped into three categories. Category one comprises enterprise architecture frame-
works. Popular examples are the Zachman Framework  and The Open Group
Enterprise Architecture Framework—TOGAF . Category two is comprised of
publications by scientists as for example [8, 14, 19]. The third category is defined by
practitioner’s publications who predominantly publish for practitioners. Examples are
[24, 29]. However, the boundary between scientific and practitioner approaches (re-
garding authorship as well as readership) is often fluid. Examples are [3, 22, 27].
A fundamental method provided by almost all of the contributions cited above is
comprised of a basic approach for documenting the as-is and/or to-be EA. Some ap-
proaches provide a number of analyses that may be employed in an EA transforma-
tion method [19, 20] or a list of EA application scenarios for which methods may be
developed. However, this list is neither complete nor are its items disjunctive.
Discussion in the field of EA is highly concerned with questions as which artefacts
belong to EA, e.g. [2, 4, 15]. Only recently, it is discussed how to maintain EA mod-
els , how to use EA, or what benefits EA may provide to an organization .
Especially the latter issues require sound methods. Although there are isolated EA
methods taking the situation of application into account, e.g. , there is no overall
landscape of EA methods available.
A method may be defined as a systematic aid that guides the transformation of a
system from an initial state to a target state. It is unlikely that there is an EA method,
which fits to every problem situation in the field. Instead it is advisable to adapt an
existing method or to use dedicated parts, like method components or method frag-
ments. Approaches like this are discussed as situational method engineering [12, 18,
26]. It means that a method can be customized for the needs of a project or an organi-
sation. In order to customize a method for a situation contingency or situational fac-
tors are needed to facilitate the description of such a situation. Existing contingency
approaches are not tailored for EA and their contingency factors often lack empirical
evidence [13, 17, 26]. Therefore the aim of this paper is to identify contingency fac-
tors determining current EA realization approaches by means of empirical analysis.
3 Current Realization Approaches of EA
An exploratory analysis was conducted in order to identify different EA approaches in
practice . The data was collected by means of a questionnaire filled in by partici-
pants of two practitioner conferences in 2007. Both conferences focused on EA in
particular. Attending were IT executives, IT service providers and consultants as well
as EA experts. In advance of the conferences, the questionnaire was subject to a pre-
test carried out by a group of enterprise architects.
390 C. Riege and S. Aier
3.1 Characteristics of the Data Set
A total of 69 questionnaires were returned. If the data set was incomplete regarding
one of the 15 items used in subsequent analysis, the questionnaire was discarded. After
applying this selection criterion, 55 valid questionnaires were analyzed. Although the
sample size is rather small, the data set is considered adequate to provide a basis for an
exploratory analysis.1 The observed organizations mainly represent mid-size and large
companies from the financial services sector as well as software vendors and IT con-
sultants. In addition to demographic characteristics the data set comprises variables
which can be divided into four groups and characterized as follows:
Constitution of EA: Architecture in general includes a set of IT artefacts like hardware
assets, software components, and applications and extends the focus to business re-
lated artefacts. To ensure that business/IT alignment is adequately supported, EA also
spans artefacts like business processes, products, customer segments, etc. Due to the
large number of potential artefacts, EA is requested to represent the essential parts of
the organization . The data set contains information regarding the aforementioned
Application scenarios and analysis techniques of EA: The employment of EA in an
organization often refers to a substantial number of possible applications [19, 20, 32].
Applications however are external to the EA approach. The aim is to integrate EA
into the organization’s initiatives to secure that the organization develops in accor-
dance with the structures defined in EA. For this reason, the EA model is subject to a
range of analysis techniques. Techniques reveal dependencies between different EA
artefacts, identify gaps or redundancies (e.g. application support of certain business
processes), and reveal artefacts that might interfere with a homogeneous EA structure
[19, 20, 32].
Maintenance of EA: This part of the data set contains information to which extent EA
models are part of strategic planning, and to which extent EA models support trans-
formations. Furthermore it covers the approach how EA data is gathered and main-
tained within an organization. A central instance for EA-related information facilitates
a less complex and consistent EA improvement. In this holistic approach, a “leading”
EA model is maintained covering all artefacts used to describe the EA. A federated
approach puts more emphasis on specialized architectures and their models. The EA
model is then supplied with data through periodically performed replications. EA data
which is maintained via local repositories yields more flexibility, but also ensures that
the stored information is up-to-date .
Communication and organizational structure of EA: On the one hand, the data set
contains information on organizational roles which should be established to ensure
EA is adequately represented within the organization—e.g. the role of an expert in EA
modelling. On the other hand, EA offers benefits that take effect across IT and busi-
ness units. It is important to capture how the concept of EA spreads within the organi-
zation. According to the understanding that EA is also involved in management
1 What rule of thumb to use for factor analysis in determining an allowable ratio of cases to
variables is still a matter of research taste . However,  suggests a 4-to-1 rule of thumb
for an allowable ratio of cases to variables.
A Contingency Approach to Enterprise Architecture Method Engineering 391
activities and addresses business related objectives, it is of high importance how EA
is perceived . The information in this part of the questionnaire also covers the
integration of EA processes into the organization’s governance structure. The respon-
dents were asked to assess the current degree of realization of each item in their
organization. Therefore, the questionnaire chooses a five-tiered Likert scale. The
minimum value (1) that was possible to check represents “nonexistent”, whereas the
maximum value (5) indicates an “optimized” realization.
3.2 Identifying Contingency Factors of EA
In order to identify contingency factors of EA, a factor analysis is applied. A factor
analysis involves extracting a small number of latent factors among the variables in
the data set. To form an adequate foundation, the data set has to meet two criteria. The
first criterion is derived from the variables’ anti image covariance. The anti image
covers the part of the variance which cannot be explained by the remaining variables
in the data set. As factor analysis aims at finding latent factors based on the data set, a
data set is suitable for factor analysis if the anti image is rather low. According to ,
the percentage of none diagonal elements of the anti image covariance matrix, which
are non-zero (>0.09), should not exceed 25%. In the case presented here, this parame-
ter is about 17%. The second criterion involves the computation of the Kaiser-Meyer-
Olkin measure of sampling adequacy. In the data set at hand, the measure is 0.798.
According to , it puts a data set with a value of 0.7 or above into “middling”
range, bordering the “meritorious” range. In this case, the results proof that the data
set is generally appropriate for factor analysis. The factor analysis was performed
based on a reduced data set of 15 items. While some items which are excluded from
subsequent analyses relate to company properties such as staff size and industry sec-
tor, others were previously characterized as covering the constitution of EA within an
As extraction method the principal component analysis was applied. Principal
component analysis identifies few independent factors that contain the fundamental
aspects of the data. In order to identify the optimum number of factors, the eigenvalue
was computed which represents the amount of variance accounted for by a factor.
According to the Kaiser criterion a factor’s eigenvalue should exceed a value of one
. As a result, three contingency factors that account for 64% of the total variance
were extracted. In order to better interpret the nature of the factors, the component
matrix was rotated applying the Varimax method with Kaiser normalization. Each of
the three factors consists of five items and can be described as follows.
Table 1. Factor 1—Adoption of advanced architectural design paradigms and modelling
Item 1.1 EA is developed with regard to modularization as an architectural design paradigm.
Item 1.2 The principles of service orientation form a basis on which EA is designed.
Item 1.3 EA models represent the current structure of the organization.
Item 1.4 Documentation of EA models includes target architecture.
Item 1.5 EA models support transforming EA from as-is structure towards to-be structures.
392 C. Riege and S. Aier
The items that load on contingency factor 1 describe valuable ways to adopt the con-
cept of EA. On the one hand, it involves well established architecture design paradigms
which emphasize the layered structure of EA. The findings denote that developing EA
needs a certain degree of decoupling between the different EA layers as indicated by the
principles of service orientation and thus foster re-use of EA artefacts. On the other
hand, factor 1 points out that a further enhancement of EA also depends on the dimen-
sion of the EA documentation. To allow for a continuous development, not only loosely
coupled artefacts, but also an idea of how to approach a future development stage is
decisive. EA then contributes to business/IT alignment by offering simulation capabili-
ties, which presupposes different variants of its to-be structures.
Table 2. Factor 2—Deployment and monitoring of EA data and services
Item 2.1 EA is measured and/or reviewed on a regular basis.
Item 2.2 Processes concerning EA management are subject to regular reviews.
Item 2.3 The role of an EA quality manager is established fostering and communicating EA
Item 2.4 EA is aiming to improve the overall homogeneity of architecture elements by apply-
ing heterogeneity analysis.
Item 2.5 EA is used to perform coverage analysis in order to illustrate redundancies or gaps
regarding EA artefacts.
Factor 2 describes the deployment of EA within the organization. It is required to es-
tablish a consistent monitoring of EA data and services to further enforce the deploy-
ment. This can be assisted by the role of an EA quality manager who is responsible for
observing periodic reviews of EA data and EA processes. A high degree of EA deploy-
ment puts the organization in the position to reduce its costs for maintenance activities,
software and hardware licenses, but also to ensure that similar concerns are treated
equally and according to the parameters of the EA roadmap. A high factor value also
points to the application of sophisticated EA analysis techniques within the organization.
Table 3. Factor 3—Organizational penetration of EA
Item 3.1 EA is perceived as being valuable to the business units.
Item 3.2 IT departments explicitly refer to EA as a helpful instrument.
Item 3.3 IT departments use EA data in broad range of use cases.
Item 3.4 Business units base their work on EA data.
Item 3.5 EA data is part of the decision support for management units.
The third contingency factor accounts for the penetration of EA in the organization.
The findings suggest that the overall level of penetration is influenced by the degree
EA results and EA documentation are used by a broad range of stakeholders. Accord-
ing to this analysis, EA is a suitable tool not only to support IT related work, but also
to serve the business units and to provide reliable information to management units.
The findings suggest that as the level of organizational penetration increases with the
organization’s capability to clearly communicate EA benefits to the potential stake-
holders—regardless if they actually operate on EA results or not. Therefore, the third
factor describes the way EA is perceived and utilized across the organization. A high
A Contingency Approach to Enterprise Architecture Method Engineering 393
level of organizational penetration leads to a higher acceptance, and less misinterpre-
tation of EA within the organization, respectively.
3.3 Clustering EA Realization Approaches
In order to point out how EA is actually realized, the data set was partitioned into dif-
ferent subsets by means of a hierarchical cluster analysis. As input data, the factor
values of the three aforementioned contingency factors were used. Ward’s method has
been used as clustering algorithm. It combines the two clusters which lead to a minimal
increase in the within-cluster sum of squares with respect to all variables across all
clusters. The squared Euclidean distance was selected as distance measure to determine
the similarity of two clusters. Although the application of alternative measures may
lead to different clustering results, the squared Euclidean distance was chosen as it is
the most commonly recognized procedure  and moreover provides a comprehensi-
ble representation with respect to the sample’s data structure. To gain information
about the cohesiveness of clusters, a tree diagram—designated as dendrogram—serves
as visualization and helps to assess the appropriate number of clusters to keep. There is
no standard selection procedure to derive the number of clusters . As the applied
fusion algorithm aims at minimizing the within-cluster sum of squares in each step, it
is appropriate to keep the number of clusters if the subsequent clustering step accounts
for the highest increase of the total sum of squares . In the analysis at hand, this
heuristic suggests to distinguish between three clusters which in turn represent three
different EA approaches. Table 4 exhibits arithmetic means (x ) and sample standard
deviations (s ) of the calculated factor values for each of the three clusters. A high
value implies a high degree of realization among the cluster members regarding the
factor items that load on the respective factor.
Table 4. Arithmetic mean and standard deviation of factor values
Cluster 1 (n =15)
Cluster 2 (n =10)
Cluster 3 (n =30)
Contingency Factor 1
Contingency Factor 2
Contingency Factor 3
Based on the information depicted in Table 4, the three clusters can be visualized
by positioning them in a three dimensional coordinate system (Fig. 1). The horizontal
axis of the coordinate system is represented by the factor adoption of advanced archi-
tectural design paradigms and modelling capabilities, the vertical axis displays factor
3 organizational penetration of EA. The Factor deployment and monitoring of EA
data and services spans the third dimension. The clusters are arranged according to
their arithmetic mean (cf. Table 4). To estimate the mean of the population when the
sample size is small it is suggested to calculate the confidence interval that is derived
from the Student's t-distribution . For this purpose the confidence interval was
calculated for each cluster based on the respective mean factor values (cf. Fig. 1). As
a result the three cuboids visualize that each cluster differs significantly from another
cluster in at least one dimension.
394 C. Riege and S. Aier
1 (;) 1,
Fig. 1. Enterprise architecture realization approaches
Fig. 1 also exhibits the corresponding two-dimensional classification matrix, which
excludes factor 2 as it does not account for significant cluster distinction. The matrix
illustrates the distinct EA realization approaches considering factors 1 and 3. For both
dimensions, high and low level are distinguished, which refer to either high or low
parameter values. The realization approaches of EA can be characterized as follows:
Cluster 1: All 15 organizations which are assigned to this cluster, are characterized by
sophisticated implementation of architectural design paradigms. They understand EA
as instrument to represent a current structure of the organization, but also to deliver a
roadmap for a future structure. It is reasonable to assume that organizational penetra-
tion is rather advanced among the members of the cluster. They are using EA rather
as IT instrument, but also as a means of communication with the business. The or-
ganizations which belong to this cluster constitute an EA approach which may be
designated as “EA Engineers”. EA engineers understand EA as a valuable instrument
to develop and thus transform EA in its holistic understanding. They can also rely on
a progressive perception of EA within the business and management units. EA engi-
neers in its current state have an intermediate maturity regarding the employment and
monitoring of EA data and services (factor 2).
Cluster 2: The second cluster is made up of 10 organizations which have a low level
of both the organizational penetration of EA and the adoption of advanced architec-
tural design paradigms and modelling capabilities. This combination can be character-
ized as observant attitude regarding a holistic EA. In this case, EA focuses primarily
on IT architecture and, therefore, EA data is basically used in traditional IT project
development. The relatively high value regarding the second factor supports this
characteristic as it indicates a high deployment of (IT related) EA data. The EA ap-
proach represented by the organizations which are merged in the second cluster can
be designated as “IT Architects”. They are well anchored in the IT domain. However,
A Contingency Approach to Enterprise Architecture Method Engineering 395
this limited architectural understanding is an obstacle in order to really leverage the
value of available IT understanding, models and methods. Rather advanced architec-
tural design paradigms—e.g. service orientation—are not much developed in this
cluster because they require a certain amount of organizational penetration.
Cluster 3: A total of 30 organizations are grouped into the third cluster. They are
characterized by a high level of organizational penetration of EA—comparable with
cluster 1. It is therefore reasonable to assume that the potential benefits of EA are
recognized among these organizations. EA is understood not only as IT architecture,
but also as an instrument to foster the alignment between IT and business. However,
EA primarily focuses on documentation. Organizations which belong to this cluster
can be designated as “EA Initiators”. EA initiators put emphasis on transparency as
the necessary precondition to realize benefits from EA application. Therefore, it
seems reasonable to conclude that EA initiators in particular are interested in imple-
menting relevant applications to demonstrate these benefits. This also explains the
need for more sophisticated analysis techniques—which EA initiators lack of. This
typically is a hint for a tool driven or model driven EA approach as opposed to an
application driven approach. Such a tool driven approach may be dangerous since it
requires significant efforts to survey and model the architectural data without a clear
idea of future application scenarios.
The size of the clusters (Table 4) leads to the assumption that most organizations
acknowledge the benefits of EA as EA initiators account for more than 50% of the
three EA scenarios. Still a minority of organizations represented by the cluster IT
architects is not able to convince potential stakeholders of EA benefits and thus is not
able to leverage advanced design or modelling capabilities. The EA scenario with the
currently most mature application of EA is represented by EA engineers.
4 EA Applications Scenarios
To adequately support EA method engineering, it is not sufficient to take contingency
factors (c.f. section 3) into account but also to describe future EA application scenar-
ios. In order to identify these scenarios, a second factor analysis has been performed
based on 12 EA applications. The set of EA applications is derived from [20, 32].
Factor analysis serves as a means to reduce the dimensionality of that number of EA
applications to a fewer number of factors. In contrast to the analysis in section 3.1, the
respondents were asked to asses the future importance of each of the 12 suggested EA
applications. As quality measures, the anti image covariance matrix as well as the
Kaiser-Meyer-Olkin criteria were computed. In the data set at hand the percentage of
none diagonal elements of the anti image covariance matrix is about 22%, well in
range with the limit of 25% . The Kaiser-Meyer-Olkin measure of sampling ade-
quacy is about 0.828, putting the data set in the “meritorious” range . The results
assure that the data set is appropriate for subsequent factor analysis. Principal compo-
nent analysis extracts three independent factors, which inherit the aspects of the
12 underlying EA applications. In total the three factors, representing three scenarios
for EA application, account for 67.6% of the variance. Factor 1 consists of 4 items
(Table 5) and can be characterized as follows.
396 C. Riege and S. Aier
Table 5. Factor 1—Support of Business Strategy Development
Factor 1 describes EA applications that affect the strategic development of an or-
ganization. EA supports decisions which e. g. demand reengineering business func-
tions due to a potential shift in market requirements like quality aspects or processing
time. Strategy development involves further analysis like a feasibility analysis to offer
certain product bundles. EA is used to identify market offers/products that will be
affected in case a specific application fails. In terms of business process optimization
EA is a means to discover redundant processes which contribute to the same market
offers/products. As an instrument being supportive for business strategy development,
EA will need to revert to certain artefacts within the organisation. It is therefore nec-
essary to have transparency e. g. regarding market segments, product catalogues, and
business functions of the organisation and their interdependencies.
Corporate Strategy Planning
Business Process Optimization
Quality Management and Improvement
Business Continuity Planning
Table 6. Factor 2—Support of IT Management
Factor 2 comprises of 5 items, (Table 6). Items which load on factor 2 specifically
support IT Management within an organisation. Within this scenario EA is concerned
with e. g. the advancement of the application landscape. EA serves as a means for
analyzing the lifecycle of applications, and for example evaluate alternative replace-
ment decisions. This is particularly important, if COTS is going to replace existing
parts of the application landscape. Furthermore IT Management uses EA as a tool to
consolidate the application landscape e. g. by analyzing whether there are applications
without assigned users. Regarding IT Project Management, EA documents and pro-
vides an overview of compliance concerning technical or platform standards. EA
artefacts, which are necessary to facilitate IT Management include applications, soft-
ware components and hardware assets as well as the project portfolio. In this context
EA is understood as a complementing approach to CMDB or IT Project Management.
Application Portfolio Management
Adoption of COTS
Architecture Compliance Assessment
Table 7. Factor 3—Support of Business Operations
Sourcing and Business Networking
A Contingency Approach to Enterprise Architecture Method Engineering 397
Factor 3 describes EA applications, which support daily business operations
(Table 7). In contrast to factor 1 Support of Business Strategy Development EA is
more concerned with maintaining the conditions and quality attributes the business
requires to carry out its operations and only to a less extent with long term planning.
By e. g. analysing business process roles, their correct embedment within the authori-
zation structure of corresponding applications, EA ensures that the organization’s
identity management is aligned and consistent with business requirements. To support
sourcing decisions and maintain SLA, EA provides transparency regarding process
interfaces. This enables the organization to analyze whether such interfaces are com-
pliant to a service provider. In this scenario required artefacts range from business
processes, interfaces, and SLA to business networking partners.
5 Summary and Future Work
Based on the discussion in situational method engineering and the current EA state-
of-the-art, this paper suggests differentiating contingency factors of EA. The results of
the exploratory analysis confirm the assumption that there is no overall approach to
adapt to EA in practice, but to distinguish between three EA realization approaches.
They represent three different approaches on how to grasp EA in terms of its deter-
mining factors. The exploratory analysis (Fig. 2) shows that adoption of advanced
architectural design paradigms and modelling capabilities, and organizational pene-
tration of EA are significant factors to discriminate between different EA approaches
in practice. The fact that EA (as opposed to IT architecture) is a pretty novel topic is
addressed by an analysis of possible EA applications. The presented contingency
factors, resulting in different realization approaches and application scenarios provide
a basis on which EA methods can be adapted to a specific situation.
A possibility to consolidate and validate the findings of the analysis at hand is to
build EA methods employing these contingency factors, respectively the EA ap-
proaches and application scenarios, and evaluate these methods in real life case stud-
ies. This will help to further enhance the construction of methods for an effective
EA management, where methods specifically fit to the situations in which they are
Although we do not interpret the identified EA realization approaches as levels of
EA maturity, we expect the members of each cluster to further develop their EA. This
is an important starting point for further research activities, where the exploration,
description, and in particular the methodical support of such transformation or devel-
opment paths have to be covered.
1. Aier, S., Riege, C., Winter, R.: Classification of Enterprise Architecture Scenarios – An
Exploratory Analysis. Enterprise Modelling and Information Systems Architectures 3(1),
2. Arbab, F., de Boer, F., Bonsangue, M., Lankhorst, M., Proper, E., van der Torre, L.: Inte-
grating Architectural Models. Symbolic, Semantic and Subjective Models in Enterprise
Architecture. Enterprise Modelling And Information System Architectures 2(1), 40–56
398 C. Riege and S. Aier
3. Bernard, S.A.: An Introduction to Enterprise Architecture, 2nd edn. Authorhouse, Bloom-
4. Buckl, S., Ernst, A.M., Lankes, J., Matthes, F., Schweda, C.M., Wittenburg, A.: Generat-
ing Visualizations of Enterprise Architectures using Model Transformations. Enterprise
Modelling and Information Systems Architectures 2(2), 3–13 (2007)
5. Cattell, R.B.: Factor Analysis: An Introduction and Manual for the Psychologist and Social
Scientist. Harper and Row, New York (1952)
6. Dziuban, C.D., Shirkey, E.C.: When is a correlation matrix appropriate for factor analysis?
Psychological Bulletin 81(6), 358–361 (1974)
7. Fischer, R., Aier, S., Winter, R.: A Federated Approach to Enterprise Architecture Model
Maintenance. Enterprise Modelling and Information Systems Architectures 2(2), 14–22
8. Frank, U.: Multi-Perspective Enterprise Modeling (MEMO) – Conceptual Framework and
Modeling Languages. In: Proceedings of the Hawaii International Conference on System
Sciences (HICSS-35) (2002)
9. Gordon, A.D.: Hierarchical Classification. In: Arabie, P., Hubert, L.J., De Soete, G. (eds.)
Clustering and Classification, pp. 65–121. World Scientific Publishing, River Edge (1996)
10. Hair Jr., J.F., Black, B., Babin, B.: Multivariate Data Analysis, 6th edn. Prentice Hall,
Englewood Cliffs (2006)
11. Härdle, W., Simar, L.: Applied Multivariate Statistical Analysis. Springer, Berlin (2003)
12. Harmsen, A.F., Brinkkemper, S., Oei, H.: Situational Method Engineering for Information
System Project Approaches. In: Proceedings of the IFIP 8.1 Working Conference on Meth-
ods and Associated Tools for the Information Systems Life Cycle, pp. 169–194. North-
Holland, Amsterdam (1994)
13. Huisman, M., Iivari, J.: The individual deployment of systems development methodolo-
gies. In: Pidduck, A.B., Mylopoulos, J., Woo, C.C., Ozsu, M.T. (eds.) CAiSE 2002.
LNCS, vol. 2348, pp. 134–150. Springer, Heidelberg (2002)
14. Johnson, P., Ekstedt, M.: Enterprise Architecture – Models and Analyses for Information
Systems Decision Making. Studentlitteratur, Pozkal (2007)
15. Jonkers, H., Lankhorst, M., van Buuren, R., Hoppenbrouwers, S., Bonsangue, M., van der
Torre, L.: Concepts for Modelling Enterprise Architectures. International Journal of Coop-
erative Information Systems 13(3), 257–287 (2004)
16. Kaiser, H.F., Rice, J.: Little Jiffy, Mark IV. Educational and Psychological Measure-
ment 34(1), 111–117 (1974)
17. Kettinger, W.J., Teng, J.T.C., Guha, S.: Business Process Change: A Study of Methodolo-
gies, Techniques, and Tools. MISQ 21(1), 55–80 (1997)
18. Kumar, K., Welke, R.J.: Methodology Engineering – A Proposal for Situation-specific
Methodology Construction. In: Cotterman, W., Senn, J.A. (eds.) Challenges and Strategies
for Research in Systems Development, pp. 257–269. John Wiley & Sons, New York
19. Lankhorst, M.: Enterprise Architecture at Work: Modelling, Communication and Analysis.
Springer, Berlin (2005)
20. Niemann, K.D.: From Enterprise Architecture to IT Governance. Elements of Effective IT
Management. Vieweg, Wiesbaden (2006)
21. Pereira, C.M., Sousa, P.: A Method to Define an Enterprise Architecture using the Zach-
man Framework. In: Proceedings of the 2004 ACM Symposium On Applied Computing,
pp. 1366–1371. ACM Press, New York (2004)
22. Ross, J.W., Weill, P., Robertson, D.C.: Enterprise Architecture as Strategy. Creating a
Foundation for Business Execution. Harvard Business School Press, Boston (2006)
A Contingency Approach to Enterprise Architecture Method Engineering 399 Download full-text
23. Rummel, R.J.: Applied Factor Analysis. Northwestern University Press, Chicago (1970)
24. Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frameworks:
Creating or Choosing an Enterprise Architecture Framework, 2nd edn. Trafford Publish-
ing, Victoria (2004)
25. Schelp, J., Stutz, M.: A Balanced Scorecard Approach to Measure the Value of Enterprise
Architecture. Journal of Enterprise Architecture 3(4), 8–14 (2007)
26. van Slooten, K., Hodes, B.: Characterizing IS Development Projects. In: Proceedings of
the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, pp. 29–44.
Springer, Berlin (1996)
27. Spewak, S.H., Hill, S.C.: Enterprise Architecture Planning – Developing a Blueprint for
Data, Applications and Technology. John Wiley & Sons, New York (1993)
28. The Open Group, The Open Group Architecture Framework TOGAF – 2007 Edition (In-
corporating 8.1.1). Van Haren, Zaltbommel (2007)
29. Theuerkorn, F.: Lightweight Enterprise Architectures. Auerbach Publishers, Boca Raton
30. Veasey, P.W.: Use of enterprise architectures in managing strategic change. Business
Process Management Journal 7(5), 420–436 (2001)
31. Wegmann, A.: The Systemic Enterprise Architecture Methodology (SEAM) – Business
and IT Alignment for Competiveness, École Poytechnique Fédérale de Lausanne (2002)
32. Winter, R., Bucher, T., Fischer, R., Kurpjuweit, S.: Analysis and Application Scenarios of
Enterprise Architecture – An Exploratory Study. Journal of Enterprise Architecture 3(3),
33. Winter, R., Fischer, R.: Essential Layers, Artifacts, and Dependencies of Enterprise Archi-
tecture. Journal of Enterprise Architecture 3(2), 7–18 (2007)
34. Ylimäki, T., Halttunen, V.: Method engineering in practice: A case of applying the Zach-
man framework in the context of small enterprise architecture oriented projects. Informa-
tion Knowledge Systems Management 5(3), 189–209 (2006)
35. Zachman, J.A.: A Framework for Information Systems Architecture. IBM Systems Jour-
nal 26(3), 276–292 (1987)