# The Zachman Framework for Enterprise Architecture:
An Explanatory IS Theory

Aurona Gerber, Pierre Le Roux, Carike Kearney, Alta van Der Merwe

► To cite this version:

Aurona Gerber, Pierre Le Roux, Carike Kearney, Alta van Der Merwe. The Zachman Framework for Enterprise Architecture: An Explanatory IS Theory. 19th Conference on e-Business, e-Services and e-Society (I3E), Apr 2020, Skukuza, South Africa. pp.383-396, 10.1007/978-3-030-44999-5_32 hal-03222875

HAL Id: hal-03222875

https://inria.hal.science/hal-03222875

Submitted on 10 May 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# The Zachman Framework for Enterprise Architecture: an
Explanatory IS Theory

Aurona Gerber¹,²[0000-0003-1743-8167], Pierre le Roux¹, Carike Kearney¹ and Alta van der Merwe¹[0000-0002-3652-7512]

¹ Department of Informatics, university of Pretoria, Pretoria, South Africa

² CAIR, Pretoria, South Africa

aurona.gerber@up.ac.za, pierre.leroux@moyoAfrica.com

**Abstract.** Enterprise Architecture (EA) has had an interesting and often controver-
sial history since its inception in the late 80's by pioneers such as John Zachman.
Zachman proposed the Zachman Framework for Enterprise Architecture (ZFEA), a
descriptive, holistic representation of an enterprise for the purposes of providing
insights and understanding. Some scholars claim that EA is an imperative to ensure
successful business structures or business-IT alignment, or more recently with En-
terprise Architecture Management (EAM), to manage required organizational trans-
formation. However, EA initiatives within companies are often costly and the ex-
pected return on investment is not realized. In fact, Gartner recently indicated in
their 2018 Enterprise Architecture Hype Cycle that EA is slowly emerging from the
trough of disillusionment after nearly a decade. In this paper we argue that the role
and value of EA is often misunderstood, and that EA, specifically the ZFEA for the
purpose of this paper, could be considered as a theory given the view of theory
within Information Systems (IS). The purpose of IS theories is to analyse, predict,
explain and/or prescribe and it could be argued that EA often conform to these pur-
poses. Using the taxonomy of theories as well as the structural components of the-
ory within IS as proposed by Gregor, we motivate that the ZFEA could be regarded
as an explanatory theory. Positioning ZFEA as IS explanatory theory provides in-
sight into the role and purpose of the ZFEA (and by extension EA), and could assist
researchers and practitioners with mediating the challenges experienced when in-
stituting EA and EAM initiatives within organizations.

**Keywords:** Zachman Framework for Enterprise Architecture, Enterprise Archi-
tecture, IS Theory, Explanatory IS Theory.

# 1 Introduction

The initial idea to describe, understand, represent and design different dimensions of the
enterprise was developed simultaneously within different disciplines in the late eighties.
During this time John Zachman, often hailed as the father of EA, defined EA as a set of
descriptive representations relevant to the enterprise where an enterprise is widely de-
fined as any socio-technical organization [1, 2]. He furthermore proposed the Zachman
Framework for Enterprise Architecture (ZFEA) that he described as a logical, compre-
hensive structure "for classifying and organizing the descriptive representations of an
Enterprise that are significant to the management of the Enterprise as well as to the de-
velopment of the Enterprise’s systems, manual systems as well as automated systems”
[1].

Since this original establishment of EA in the late 80’s, EA has developed as a com-
prehensive discipline receiving interest from researchers and practitioners. Several
frameworks were proposed, refined and implemented in practice [3–9], and scholarly
research investigated the nature and impact of EA [10–16]. Recent developments in the
broad domain of EA include Enterprise Architecture Management (EAM) that elevates
EA as a strategic business function rather than an IT function within organizations, and
recent research indicate that EAM may indeed assist with organizational agility and
transformation [17–21].

EA in strategic context is directed at the current and future purposes of the organiza-
tion as well as to assist in reaching organisational goals and objectives, including ensur-
ing that the business with its technologies and resources are aligned [10, 22]. However,
enterprises often experience challenges with the implementation of EA initiatives and
capabilities [23], resulting in sentiments documented mostly in popular press, for in-
stance stating that *EA is dead* [24, 25]. EA initiatives are often costly and without the
expected return on investment. Recent blog posts, for instance, claim that several EA
frameworks or tools, specifically the ZFEA, are fake tools without any real value [26].
In their recent 2018 Enterprise Architecture Hype Cycle Gartner found that EA is only
now, after more than a decade, emerging from the trough of disillusionment [27].

The authors acknowledge the criticisms, but in this paper we argue that the role and
value of EA is often misunderstood, and for the purposes of this paper, we argue that
EA, specifically the ZFEA, should be considered as a theory given the perspectives on
theory adopted within Information Systems (IS). EA is relevant for the IS domain as IS
is the discipline concerned with studying socio-technical systems, and the view of theory
within IS is therefore applicable to EA. Some of the views on IS theory include “theory
as statements that say how something should be done in practice” or “theory as state-
ments providing a lens for viewing or explaining the world”. The purpose of IS theories
is to analyse, predict, explain and/or prescribe and it could be argued that the intent of
EA often conforms to these purposes.

For this paper we focus on the ZFEA primarily and we support this selection by ana-
lysing the foundational aspects of EA. We subsequently adopt the fundamental view
about the nature of theories within IS by Gregor. We adopted the taxonomy of theories
as well as the structural components of theory within IS as proposed by Gregor [28] to
analyse the ZFEA. The main research question answered by this study can be stated as
follows: *Given the nature and structure of theories within IS, could the ZFEA be consid-
ered as a theory?* Similar to the method used by Gregor to evaluate five types of theory
in IS, we evaluate the ZFEA [28]. By establishing whether ZFEA, and by extension, EA
in general, could be regarded as IS theories, we believe that insight on what function EA
should fulfil, as well as the use and position of EA and its frameworks and tools, specif-
ically given the strategic developments such as EAM, could be enhanced.

The remainder of this paper is structured as follows. In the next sections on related
work we provide overviews on EA, the ZFEA and IS theories. We then analyse the foun-
dations of EA and motivate the choice of ZFEA for the purpose of this paper. We subsequently analyse the ZFEA given the nature of IS theories (taxonomy and structure) by Gregor, and we finally conclude.

## 2 Background

Within this background section we provide a short introduction to EA as well as the ZFEA, followed by the background necessary for IS theory as is relevant for this paper.

### 2.1 Enterprise Architecture

EA originally developed from the need to align the business and information technology aspects of the organisation with one another [12], but has since advanced to be viewed from more than one perspective and for more than one application [10]. EA developed from more than one discipline with differing terminology, seeking mostly similar goals such as organisational alignment, integration, and ability to understand and manage complexity and change [16, 29]. Several definitions for EA exist, such as that EA is the continuous practice of describing the essential elements of a socio-technical organisation, their relationships to each other and to the environment, in order to understand complexity and manage change [30]. Urbaczewski and Mrdalj defined EA as a description or blueprint that defines the day-to-day operation and structure of an organization[3], and Zachman himself defined EA as a set of descriptive representations relevant to the enterprise [31]. EA is directed at ensuring that the business with its technologies and resources, as well as the current and future purposes of the organization are aligned. Since its inception, several different EA frameworks were developed from different perspectives and disciplines. Due to space limitations, we will mostly focus on the ZFEA, however, several works on the history, evolution, purpose of, and recent developments within EA are included as references [3, 12, 13, 16, 17, 32–38]. In Section 4 we analyse the grounding of the EA discipline to motivate the choice of the ZFEA for this paper, and in the next section a short overview of ZFEA is provided.

### 2.2 The Zachman Framework for Enterprise Architecture (ZFEA)

John Zachman is widely acknowledged as the father of EA [16, 39]. Borrowing from the field of engineering, Zachman described how insight into different disciplines and the manufacturing process contributed to the ZFEA [1, 40]. Zachman describes the breakthrough that led to his now well-known ZFEA as the realisation of the existence of different perspectives relevant to a product, which he then applied to an enterprise [39]. The ZFEA was designed after observing that various engineered objects such as computers, buildings and airplanes (the designed artefacts) can be classified according to the fundamental abstractions or interrogatives namely *What? How? Where? Who? When? Why?*, in columns (Table 1), as well as specific audience perspectives and transformations in rows (Table 2) [1]. The ZFEA (Figure 1), is therefore a 6x6 two-dimensional classification schema for designing descriptive representations of the enterprise. The ZFEA is also described as an enterprise ontology with no process or tooling implications [41], or a
meta-model of an enterprise represented in a matrix comprised of columns and rows. Each intersection of a column and row provides a unique representation or view of the enterprise [1].

<figure><img src="image_2.png" /><figcaption>Figure 1: The Zachman Framework for Enterprise Architecture (ZFEA) (reproduced from [1])</figcaption></figure>

<table><caption>Table 1: Summary of the ZFEA interrogatives (abstractions) [1].</caption><thead><tr><td>Interrogative (Columns)</td><td>Description</td></tr></thead><tbody><tr><td>What (Data)</td><td>What information, business data and objects are involved?</td></tr><tr><td>How (Function)</td><td>How does it work? (process flows)</td></tr><tr><td>Where (Network)</td><td>Where are the components located? (network models/distribution networks)</td></tr><tr><td>Who (People)</td><td>Who are involved? ( workflow models or responsibility assignments)</td></tr><tr><td>When (Time)</td><td>When do things happen? (timing cycles)</td></tr><tr><td>Why (Motivation)</td><td>What is the motivation? (business drivers, motivation intensions)</td></tr></tbody></table>

<table><caption>Table 2: Summary of the ZFEA perspectives [1].</caption><thead><tr><td>Perspective (Rows)</td><td>Description</td></tr></thead><tbody><tr><td>Executive (Planner)</td><td>Contextual View. Defines the limits for all remaining perspectives</td></tr><tr><td>Business Manager or CEO (Owner)</td><td>Conceptual View. This perspective is concerned with the business itself</td></tr><tr><td>Architect (Designer)</td><td>Physical View. The architect or person responsible for narrowing the gap between what is required versus what is physically and technically possible</td></tr><tr><td>Engineer (Builder)</td><td>Represents the perspective of the enterprise engineers interested in 'building' or designing the building blocks identified by the architecture.</td></tr><tr><td>Technician</td><td>Represents the perspective of the business technicians such as the database implementers and the workflow system implementers.</td></tr><tr><td>User (Enterprise)</td><td>Represents the perspective of the running / functioning enterprise</td></tr></tbody></table>
## 2.3 Information Systems Theory

In a seminal work on IS theory, Gregor investigated the nature of theory in Information Systems both with regards to theory types and theory components [28]. Gregor emphasized the importance of developing good theory and highlighted the limited discussions regarding the nature of theory as well as the structural components of different types of theories in IS. Theory allows for different perspectives and aims to enhance our understanding of the world by providing explanations, descriptions, predictions and actionable guidance [28]. Gregor's work is foundational for almost all discussions about theory in IS [42–46].

Gregor identified some core aspects for developing and classifying IS theories [28]:

*   Causality (cause and effect): Certain circumstances or events will have certain outcomes. It might be required in some instances to determine the cause of an event to provide an explanation. The same is true for predictions, insights into the cause influences the prediction.

*   Generalization: An aspect or characteristic can be applied across a range of specific scenarios, places, people, etc. The degree of generalization determines different viewpoints. Generalization applied to a focused area is required for prediction, as without generalizations about the past or the present, a prediction about the future state is difficult to make. Gregor did not use generalization for classifying theory types.

*   Prediction: Future occurrences are dependent on preconditions to realise.

*   Explanation: Theory aimed at providing understanding on the how, why and when of an occurrence relating to human reasoning and argumentation.

Gregor furthermore proposed a classification scheme or taxonomy of IS theory types. The primary goal of a theory is directly related to a question or a problem that need to be solved. Theories are developed for the purposes of *analysis and description*, *prediction*, *explanation* and *prescription*, and these goals were used to produce a taxonomy of theory types in IS (Table 3) as well as the components of a IS theory (Table 4) [28]. Gregor furthermore classified five different IS theories according to the taxonomy and structural components [28], and for this paper, we adopt the method used by Gregor to evaluate the ZFEA as will be discussed in Section 4.

<table><caption>Table 3. A Taxonomy of Theory Types in Information Systems Research (reproduced from [28])</caption><thead><tr><td>Theory Type</td><td>Distinguishing Attributes</td></tr></thead><tbody><tr><td>I. Analysis</td><td>Says what is: Focuses on analysis and description only. An analysis theory does not include predictions, or indication of causal relationships among occurrences/events/objects.</td></tr><tr><td>II. Explanation</td><td>Says what is, how, why, when and where: The main aim is one of explanation and to provide understanding. The theory provides explanations but does not aim to predict with any precision. The theory is not testable.</td></tr><tr><td>III. Prediction</td><td>Says what is and what will be: The theory provides predictions and has testable propositions but does not have well-developed justificatory causal explanations.</td></tr><tr><td>IV. Explanation and Prediction (EP)</td><td>Says what is, how, why, when, where and what will be: Provides predictions and has both testable propositions and causal explanations.</td></tr><tr><td>V. Design and action</td><td>Says how to do something: The theory gives explicit prescriptions (e.g. methods, techniques, principles of form and function) for constructing an artefact or complex object.</td></tr></tbody></table>
<table><caption>Table 4. Structural Components of Theory (reproduced from [28])</caption><thead><tr><th>Theory Components (Common to all theory)</th><th>Definition</th></tr></thead><tbody><tr><td>Means of representation</td><td>A physical representation of theory. This might include mathematical terms, symbolic logic, tables, diagrams, graphs, illustrations, models, prototypes.</td></tr><tr><td>Constructs</td><td>The focus point or object of the theory. All primary constructs in the theory should be well defined. Many different types of constructs are possible e.g. observational (real) terms, theoretical (nominal) terms and collective terms.</td></tr><tr><td>Statements of relationship</td><td>The nature of the relationship among the constructs depends on the purpose of the theory. Types of relationships: associative, conditional, compositional, uni-directional, bidirectional or causal.</td></tr><tr><td>Scope</td><td>The scope is specified by the degree of generality of the statements of relationships and statements of boundaries showing the limits of generalization.</td></tr><tr><th>Theory Components (Contingent on Theory Type)</th><th>Definition</th></tr><tr><td>Causal explanations</td><td>The theory gives statements of relationships among occurrences/events/objects that show causal reasoning (not covering law or probabilistic reasoning alone).</td></tr><tr><td>Testable propositions (hypotheses)</td><td>Relationships between objects/events (constructs) can be tested by means of observation or experience.</td></tr><tr><td>Prescriptive statements</td><td>The theory provides a method or guidance on how to accomplish something in practice e.g. construct a complex object or develop a strategy.</td></tr></tbody></table>

## 3 Motivation for using the ZFEA

In this section we motivate the selection to use the ZFEA in this paper as representative of EA in general. An understanding of the origins and the thinking underpinning EA has relevance for this paper as it provides the foundation for EA concepts and frameworks, and provides the motivation for using the ZFEA as representative of the structural and ontological aspects of EA in general. Le Roux [47] adopted the approach of Baskerville and Dulipovici [48] to investigate the theoretical grounding of EA, and indicated that the theoretical base for EA emerged from more than one field. The results of this analysis are summarised in Table 5. These results support the legitimacy of the discipline and support the use of EA as a theoretical base. If the ZFEA is a representative of this theoretical underpinning, we could motivate the use of the ZFEA for this paper.

<table><caption>Table 5. Summary of works relating to EA origins and their basis of argument</caption><thead><tr><th>Author</th><th>Basis from which the underlying business problems of alignment, control, efficiency and management of change are addressed</th></tr></thead><tbody><tr><td>Taylor (1911) [49]</td><td>The business system would have to be placed before the individual, and that scientific management was needed to ensure this is possible. Efficiency through interaction of individuals. Organisation as a holistic entity. Holistic system before the individual.</td></tr><tr><td>Shewhart (1931) [50]</td><td>From industrial engineering emphasized organizational control to enable adaption. Past experience and process.</td></tr><tr><td>Forrester (1961) [51]</td><td>Motivate an underlying base to understand the business system as a whole for organizational management. Discuss the elements of the organisation and interactions between elements.</td></tr><tr><td>Drucker (1968) [52]</td><td>Business management motivation that argue for system as a whole broken into elements, as well as the interactions between elements.</td></tr><tr><td>Blumenthal (1969) [53]</td><td>Holistic systems planning to adapt to change, focus on IT systems within organisations. Underlying elements and interaction between elements is an enablement factor. Proposed a framework for planning.</td></tr></tbody></table>
<table><tr><td>Helfert (1972) [54]</td><td>Financial management perspective emphasizes resource flows with a holistic platform / system from which to understand flows. The organisation is the complete set of individual resource flows.</td></tr><tr><td>Anthony (1979) [55]</td><td>A business system consists of diverse individual parts that all contribute to or serve a specific purpose. Framework to understand organisational concepts and their contribution</td></tr><tr><td>Senge (1990) [56]</td><td>Emphasizes the system as a whole, with 5 elements of technology that are interdependent, and the interrelationships of system elements. Acknowledged by Zachman.</td></tr></table>

As indicated in Table 5, systems theory and systems thinking underpin much of the theoretical base of EA. Systems thinking supports a way of thinking about the organisation as a whole while also considering system parts with their interactions [56, 57]. Systems theory provides a theoretical base from which to model the complete organisation as well as elements and interrelationships between elements [16]. The underpinning of systems thinking is furthermore distinguishable in EA in general as published by Lapalme [10], Simon et al. [16] and others [3, 38, 39].

As stated, the ZFEA is one of the original EA frameworks developed by Zachman in the late 80's [2] with origins in engineering, specifically systems thinking and systems theory [10, 16]. Given the theoretical groundings of EA, specifically the adoption of systems theory and systems thinking as established by le Roux [47] in Table 5, we could motivate that the ZFEA, which is fundamentally based on systems thinking, is in general representative of EA for the purpose of the investigation reported on in this paper.

## 4 The ZFEA as IS Theory

For the purposes of this paper, the ZFEA is mapped to Gregor's theory taxonomy as well as the structural components of theory to determine if the framework can serve as an IS theory. The first step is to classify the ZFEA as one of the theory types in the theory taxonomy of Table 3. According to Gregor it is required to look at the primary goals of the theory in order to classify it [28]. The ZFEA is a structural representation or an ontology of an organization and all its elements with their relationships that is descriptive in nature. The ZFEA is directed at providing understanding and insight [58] with no process or tooling specifications [41]. It is depicted as a 6x6 two dimensional schema.

In the descriptions of Gregor's theory types taxonomy the last theory type (Type V Theory (design and action)) say 'how to do something' and the one thing the ZFEA does not do, is to specify a process and modelling approach clearly. This is one of the biggest criticisms against the ZFEA, and the ZFEA is therefore not a Type V Theory.

The descriptions of Gregor's first four theory types all specify that the theory specify 'What is' so in order to be one of the first four theory types, the ZFEA need to conform to this characteristic [28]. Zachman claimed the ZFEA is 'The Enterprise Ontology' or 'a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, a department, a value chain, a "sliver," a solution, a project, an airplane, a building, a product, a profession or whatever or whatever)'. According to Zachman, the architecture built using the ZFEA schema would necessarily constitute the total set of descriptive representations that are relevant for describing the enterprise [1, 31]. From these descriptions it can be argued
that the ZFEA's intent is clearly one of describing ‘What is’, so it is one of the first four theory types. We now need to determine which one.

The ZFEA does extend beyond ‘analysis and description’ (Type I Theory) by providing explanations (i.e. ‘say what is, how, why when and where’), but the ZFEA does not aim to predict with precision, which is typical of a Type II Theory. The ZFEA furthermore does not say ‘what is and what will be’ and neither does the ZFEA have testable propositions (characteristics of a Type III Theory). The ZFEA aims to support causal explanation but does not pose direct quantitative causal explanations (the nature of Type IV Theories). From the above we could therefore argue that the ZFEA’s goal and intent matches that of a Type II or Explanatory Theory that ‘says what is, how, why, when and where’. A Type II Theory furthermore ‘provides explanation, but does not aim to predict with any precision. There are no testable propositions’.

According to Gregor’s taxonomy descriptions, the ZFEA can be regarded as an explanatory theory since the primary goals of the ZFEA conforms to those of an explanatory theory as discussed above. The next step is to analyse whether it is possible to identify the theory components of an IS theory depicted in Table 4 as is done by Gregor for the classification of theory types [28]. We followed the exact method of Gregor and this analysis is presented in Table 6.

<table><caption>Table 6: ZFEA and the theory components of Gregor [28].</caption><thead><tr><th>Theory Component</th><th>Instantiation: ZFEA</th></tr></thead><tbody><tr><td>Means of representation</td><td>Conforms: Words, tables, diagrams, the ZFEA is a 6x6 matrix consisting of a diagram and tables with accompanying descriptions.</td></tr><tr><td>Primary Constructs</td><td>Conforms: The complex object is the enterprise with its strategy, technology, processes, people, roles, etc. A holistic view is displayed. Objects are viewed from different perspectives and interrogative abstractions.</td></tr><tr><td>Statements of relationship</td><td>Conforms: Relationships between the audience perspectives and interrogative abstractions are specified as transformations, and within each cell primitives have predefined relationships. Relationships in the ZFEA (and EA in general) are very comprehensive i.e. dependent, associated, linked, bi-directional or multi-directional, etc.</td></tr><tr><td>Scope</td><td>Conforms: The scope is specified by the degree of generality of the statements of relationships. The ZFEA is a general schema that aims to provide a holistic view of any enterprise or engineered (complex) object and a very high level of generality is proposed. Generalization was part of the ZFEA development as the schema is derived from observing many different objects and industries.</td></tr><tr><td>Causal explanations</td><td>Conforms: The ZFEA attempts to give statements of relationships among phenomena (represented by the rows and columns in the matrix). The ZFEA aims to support causal explanations.</td></tr><tr><td>Testable propositions (hypotheses)</td><td>Does not conform: Statements of relationships between constructs that are stated in such a form that they can be tested empirically are not present. Zachman states that the model should not be applied deterministically but that it is an ontology that is repeatable and testable (such as the periodic table), however, there is not yet evidence of the ZFEA being implemented in such a way. An explanatory theory typically does not conform to this component.</td></tr><tr><td>Prescriptive statements</td><td>Does not conform: Statements in the theory specify how people can accomplish something in practice (e.g., construct an artefact or develop a strategy). This is somewhat supported by the ZFEA as the purpose of the ZFEA is to model an enterprise by using</td></tr></tbody></table>
<table><tr><td></td><td>the interrogatives and perspectives, however, detailed process or method is not supported. An explanatory theory typically do not conform to this component.</td></tr></table>

Given the results of the analyses, the conclusion can be made that the ZFEA could be regarded as an explanatory theory. An explanatory theory aims to provide an understanding on how, when and why an occurrence took place based on causality and argumentation. The ZFEA is aligned as its intent is to provide insights into the how, when and why of an enterprise. The ZFEA is represented in the form of a framework in order to provide a holistic view, but at the same time provides insights given specific perspectives. Each row, column and cell in the architecture is impacted by another e.g. the technology supports the business processes, the business processes the applications and the applications the strategy. Changes in any model will have an effect on the other models. Changes in strategy (cause) for example, will have an impact (effect) on the rest of the enterprise. All components form part of the whole to provide context. The scope is defined by the subset or component being designed. The ZFEA is described as an ontology and a structural schema that aims to be a repeatable and testable description of an enterprise. It can be argued that the main goals of the ZFEA is aligned to the goals of an explanatory theory since both aim to provide insight, understanding and causal explanations, as well as indicate relationships among components.

# 5 Conclusion

In this paper we motivate that the ZFEA could be regarded as an explanatory IS theory given the nature of theory in IS as proposed by Gregor [28]. The paper firstly discussed the need for EA and how the need for a descriptive representation of an enterprise stems from multiple disciplines. Based on the origins of EA, it is clear that EA was initially developed for the purpose of fulfilling the strategic need for a holistic representation of an enterprise that can be used as a common guideline to understand and compare organizations. The paper addressed certain criticisms pertaining to the origins, purpose and functionality of EA. EA, specifically the ZFEA, is often misunderstood, as it is not a methodology and does not provide steps on the implementation of an architecture.

Many different Enterprise Architecture Frameworks (EAF) addressing different business needs are available for use today, but for the purposes of this paper the framework of choice was the ZFEA. The ZFEA is an ontology and a two-dimensional schema aimed at providing a descriptive representation of a complex object [31]. As mentioned, the ZFEA's primary purpose is to provide a holistic understanding, thus supporting the argument of ZFEA serving as an explanatory IS theory.

ZFEA as explanatory theory provides a fresh perspective on how EA can be viewed, not as a methodology, but as a theory providing a lens for viewing or explaining an enterprise. As stated by Gregor, 'theory allows for different perspectives and aims to enhance our understanding of the world by providing explanations, descriptions, predictions and actionable guidance'. Positioning the ZFEA as IS theory provides insight into the role and purpose of EA and could assist researchers and practitioners with addressing challenges experienced when instituting EA and EAM initiatives within organizations. EA as an explanatory IS theory for organisations also present a new platform, context and therefore perspective, for focussed strategic organisational research. Further research
would extend the analysis of EA as IS theory to other frameworks, as well as explore the implications when using EA as theory. We furthermore want to investigate whether the ZFEA as meta-ontology for enterprises, may be considered as a meta-theory for organisational research.

## References

1. Zachman, J.A.: The Framework for Enterprise Architecture: Background, Description and Utility by: John A. Zachman, https://www.zachman.com/resources/ea-articles-reference/327-the-framework-for-enterprise-architecture-background-description-and-utility-by-john-a-zachman, (2016).

2. Zachman, J.: A framework for information systems architecture. IBM Systems Journal. 26, 276–292 (1987).

3. Urbaczewski, L., Mrdalj, S.: A comparison of Enterprise Architecture Frameworks. Issue in Information Systems. 07, (2006).

4. The Open Group: TOGAF®, an Open Group standard, http://www.opengroup.org/subjec-tareas/enterprise/togaf, last accessed 2018/01/05.

5. Adenuga, O.A., Kekwaletswe, R.M.: Towards a Framework for a Unified Enterprise Architecture. ISSN. 03, (2012).

6. OMG: ArchiMate® 3.0.1 Specification. The Open Group: http://pubs.opengroup.org/architecture/archimate3-doc/ (2016).

7. IFIP-IFAC Task Force: GERAM: Generalised Enterprise Reference Architecture and Methodology, Version 1.6.3. Integration, IFIP-IFAC Task Force on Architectures for Enterprise (1999).

8. Federal Enterprise Architecture Framework, https://web.ar-chive.org/web/20141030032759/http://www.whitehouse.gov/sites/default/files/omb/as-sets/egov_docs/fea_v2.pdf, last accessed 2019/10/30.

9. DODAF - DOD Architecture Framework Version 2.02 - DOD Deputy Chief Information Officer, https://dodcio.defense.gov/library/dod-architecture-framework/, last accessed 2019/10/30.

10. Lapalme, J.: Three Schools of Thought on Enterprise Architecture. IT Professional. 14, 37–43 (2012). https://doi.org/10.1109/MITP.2011.109.

11. Lapalme, J., de Guerre, D.: An Open Socio-Technical Systems Approach to Enterprise Architecture. In: Gøtze, J. and Jensen-Waud, A. (eds.) Beyond Alignment: Applying Systems Thinking to Architecting Enterprises. College Publications, London (2013).

12. Lapalme, J., Gerber, A., Merwe, A. van der, Vries, M. de, Hinkelmann, K.: Exploring the future of enterprise architecture: A Zachman perspective. Computers in Industry. 79, 103–113 (2016).

13. de Vries, M., Gerber, A., der Merwe, A.V.: The Nature of the Enterprise Engineering Discipline. Lecture Notes in Business Information Processing - Proceedings of EEWC 2014 - the 4th Enterprise Engineering Working Conference. 174, 1–15 (2014).

14. Rouhani, B.D., Mahrin, M.N., Nikpay, F., Ahmad, R.B., Nikfard, P.: A systematic literature review on Enterprise Architecture Implementation Methodologies. Information and Software Technology. 62, 1–20 (2015). https://doi.org/10.1016/j.infsof.2015.01.012.
15. Lankhorst, M. ed: Enterprise architecture at work: modelling, communication, and analysis. Springer, Berlin; New York (2005).

16. Simon, D., Fischbach, K.: An Exploration of Enterprise Architecture Research. CAIS - Communication of the AIS. 32, (2013).

17. Aier, S., Gleichauf, B., Winter, R.: Understanding Enterprise Architecture Management Design ± An Empirical Analysis. 10.

18. Fatemeh Rahimi, John Gotze, Charles Moller: Enterprise Architecture Management: Toward a Taxonomy of Applications. Communications of the Association for Information Systems. 40, 120–166 (2017).

19. Ernst, A.M.: Enterprise architecture management patterns. Presented at the (2008). https://doi.org/10.1145/1753196.1753205.

20. Wißotzki, M., Koç, H., Weichert, T., Sandkuhl, K.: Development of an Enterprise Architecture Management Capability Catalog. In: Kobyliński, A. and Sobczak, A. (eds.) Perspectives in Business Informatics Research. pp. 112–126. Springer Berlin Heidelberg, Berlin, Heidelberg (2013). https://doi.org/10.1007/978-3-642-40823-6_10.

21. Matthes, F., Buckl, S., Leitel, J., Schweda, C.M.: Enterprise architecture management tool survey 2008. (2008).

22. Hinkelmann, K., Gerber, A., Karagiannis, D., Thoenssen, B., van der Merwe, A., Woitsch, R.: A new paradigm for the continuous alignment of business and IT: Combining enterprise architecture modelling and enterprise ontology. Computers in Industry. 79, 77–86 (2016). https://doi.org/10.1016/j.compind.2015.07.009.

23. Lange, M., Mendling, J., Recker, J.: An empirical analysis of the factors and measures of Enterprise Architecture Management success. European Journal of Information Systems. 26, 411 (2016). https://doi.org/10.1057/s41303-016-0001-6.

24. McLeod, J.: Enterprise Architecture Is Dead., https://medium.com/@JonMcLeodEA/enterprise-architecture-is-dead-33dd0e63cbbf, last accessed 2019/10/30.

25. Bloomberg, J.: Is Enterprise Architecture Completely Broken?, https://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/, last accessed 2019/10/30.

26. Kotusev, S.: Fake and real tools for enterprise architecture, https://www.iqpc.com/events-enterprisearchitecture/blog/fake-and-real-tools-for-enterprise-architecture, last accessed 2019/10/30.

27. Santos, J., Allega, P.: Hype Cycle for Enterprise Architecture, 2018. Gartner (2018).

28. Gregor, S.: The Nature of Theory in Information Systems. MIS Quarterly. 30, 611–642 (2006). https://doi.org/10.2307/25148742.

29. Bernus, P., Nemes, L., Schmidt, G.: Handbook on enterprise architecture. Springer Berlin / Heidelberg (2003).

30. Merwe, A. van der, Gerber, A., Kotze, P., Merwe, P. van der, Mentz, J.: EARF - EA Definition, http://earf.meraka.org.za/earfhome/our-projects-1/completed-projects.

31. Zachman, J.A.: The Concise Definition of The Zachman Framework by: John A. Zachman (2008), https://www.zachman.com/about-the-zachman-framework.

32. Niemi, E., Pekkola, S.: The Benefits of Enterprise Architecture in Organizational Transformation. Business & Information Systems Engineering. (2019). https://doi.org/10.1007/s12599-019-00605-3.
33. Tamm, T., Seddon, P.B., Shanks, G., Reynolds, P.: How Does Enterprise Architecture Add Value to Organisations? Communications of the Association for Information Systems. 28, (2011). https://doi.org/10.17705/ICAIS.02810.

34. Hafsi, M., Assar, S.: What Enterprise Architecture Can Bring for Digital Transformation. IEEE. (2016).

35. Winter, R., Fischer, R.: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. In: 2006 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW’06). pp. 30–30. IEEE, Hong Kong, China (2006). https://doi.org/10.1109/EDOCW.2006.33.

36. Rogers, C.: Proposed Enterprise Architecture solutions for Industry 4.0 Manufacturing simulation information assets based on TOGAF. University of Denver University College (2016).

37. Buckl, S., Ernst, A.M., Matthes, F., Ramacher, R., Schweda, C.M.: Using Enterprise Architecture Management Patterns to Complement TOGAF. Presented at the September (2009). https://doi.org/10.1109/EDOCW.2009.30.

38. Aier, S., Kurpjuweit, S., Saat, J., Winter, R.: Enterprise Architecture Design as an Engineering Discipline. 1, 8 (2009).

39. Lin, F., Dyck, H.: The value of implementing enterprise architecture in organizations. Journal of International Technology and Information Management. 19, (2010).

40. John A. Zachman: Enterprise Architecture: Notes on The Zachman Framework, www.zachman.com, (2012).

41. Kappelman, L.A., Zachman, J.A.: The Enterprise and Its Architecture: Ontology and Challenges. Journal of Computer Information Systems. 1–16 (2012).

42. Gregor, S.: Theory – still king but needing a revolution! Journal of Information Technology. 29, 337–340 (2014). https://doi.org/10.1057/jit.2014.22.

43. Urquhart, C., Lehmann, H., Myers, M.D.: Putting the ‘theory’ back into grounded theory: guidelines for grounded theory studies in information systems: Guidelines for grounded theory studies in information systems. Information Systems Journal. 20, 357–381 (2009). https://doi.org/10.1111/j.1365-2575.2009.00328.x.

44. Iivari, J.: Information Systems as a Design Science. In: Vasilecas, O., Wojtkowski, W., Zupančič, J., Caplinskas, A., Wojtkowski, W.G., and Wrycza, S. (eds.) Information Systems Development. pp. 15–27. Springer US, Boston, MA (2005). https://doi.org/10.1007/0-387-28809-0_2.

45. Andrade, A.D.: Interpretive Research Aiming at Theory Building: Adopting and Adapting the Case Study Design. 21.

46. Dennis, A.: An Unhealthy Obsession with Theory. Journal of the Association for Information Systems. 6 (2019).

47. Pierre le Roux: Enterprise Architecture as Conceptual Support Framework for Small to Medium Enterprise Growth: A South African Study, (2019).

48. Baskerville, R., Dulipovici, A.: The theoretical foundations of knowledge management. Knowledge Management Research & Practice. 4, 83–105 (2006). https://doi.org/10.1057/palgrave.kmrp.8500090.

49. Taylor, F.W.: The principles of scientific management. Harper, New York (1911).

50. Shewhart, W.A.: Economic control of quality of manufactured product. Van Nostrand, New York (1931).

51. Forrester, J.W.: Industrial Dynamics. MIT Press, Cambridge (1961).
52. Drucker, P.F.: The practice of management. Pan, London (1968).

53. Blumenthal, S.C.: Management information systems: A framework for planning and development. NJ: Prentice-Hall, Englewood Cliffs (1969).

54. Helfert, E.A.: Techniques of financial analysis. Ontario: Irwin-Dorsey, Georgetown (1972).

55. Anthony, R.N.: Planning and control systems: A framework for analysis. Harvard University Press, Boston (1979).

56. Senge, P.M.: The fifth discipline: The art and practice of the learning organisation. Random House, London (1990).

57. Checkland, P.: Systems thinking, systems practice. J. Wiley (1981).

58. John Zachman: Enterprise Architecture The Issue of the Century, (1996).