THEZACHMANFRAMEWORK 1

The Zachman Framework

Utrecht University

Faculty of Science

Master’s in Business Informatics

Author: Thomas Jan Dedding Student Number: 5795621

Student Assistant: Dimitra Papachristou

THEZACHMANFRAMEWORK 2

TableofContents

1. INTRODUCTION 3

2. EXAMPLE 4

3. PROCESSDELIVERABLEDIAGRAM 5

4. RELATEDLITERATURE 11

5. BIBLIOGRAPHY 12

THEZACHMANFRAMEWORK 3

1. Introduction Created by John A. Zachman, the Zachman Framework for Enterprise Architecture or just

Zachman Framework (ZF) is an ontology which provides a structured way of viewing and defining an enterprise. It proposes a logical structure for classifying and organizing the descriptive representations of an enterprise in different dimensions, and each dimension can be perceived in different perspectives. It consists of a 6 x 6 matrix, as depicted in Figure 1. It columns contains the primitive interrogatives (what, how, where, who, when and why) and it rows represents the reification transformation, which means, the transformation of an abstract concept into a concrete (more real) concept through different perspectives labeled as Identification, Definition, Representation, Specification, Configuration and Instantiation. The cells formed by the intersection between the two axis are the framework classifications (Lapalme, et al., 2015). The ZF is currently in the 3.0 version and it has been first seen in 1987. John A. Zachman has been focusing in enterprise architecture since 1970 and, as mentioned before, is the originator of the ZF which has received broad acceptance around the world as an integrative framework for descriptive representations for enterprises. (Zachman J. A., n.d.).

Figure 1. Zachman Framework for Enterprise Architecture. This figure illustrates the ZF Matrix and its

deliverables.

The ZF, once filled up, will constitute of the total set of descriptive representations that are relevant and important to describe an enterprise in both the management of the company and the development of its information systems (Barekat, Nejad, & Alavi, 2013). In order to apply this method, six main activities have to be performed regarding the fulfilling of all rows. The purpose of these six activities are: Identification of enterprise objectives, definition of the business functionalities, modeling the business functionalities and information systems, defining and implementing the information

THEZACHMANFRAMEWORK 4

systems, implementation of the system elements and instantiation of the information systems. Inside of each of those activities, six sub-activities (representing the six interrogatives for each different perspective) have to be done regarding the fulfilling of the cells of each row, what results in the ZF deliverables. Those activities and sub-activities, as well as their deliverables are explained in the Process Deliverable Diagram section.

One common misconception of the rows in the ZF is that lower rows are a clarification of upper rows. In ZF each row represents a model of the enterprise in a different perspective, so, all cells are different of each other and contains different information and levels of details (Lapalme, et al., 2015). Although representing different things, those cells are horizontally and vertically integrated, which means that, in order to create models and insert content in a cell, the impact of others cells in the same column and in the same row must be considered (Bahill, Botta, & Daniels, 2006). Although in this paper the examples given about the ZF are only in the enterprise architecture domain, actually it can be adopted to the design and mapping of any complex system as well, for example, a plane or a building (Varga, 2003).

2. Example

In order to explain what content a cell of the ZF should contain and present how the ZF output should looks like, a more detailed explanation of the two axis is necessary. Starting with the columns, it has been already mentioned that them are the the fundamentals of communication. Zachman affirms that those interrogatives should permit an engineer to describe every feature of any engineering object (Lapalme, et al., 2015). In the context of enterprises those interrogatives can be translated as follow:

• the what into inventory. This interrogative is about the set of things that the enterprise must manage or track;

• the how into process flows. This interrogative is about how the work and processes are designed and executed within the enterprise;

• the where into distribution networks. This interrogative is about locations and distances; • the who into responsibility assignments. This interrogative is about roles and

responsibilities; • the when into timing cycles. This interrogative is about changes regarding time.

Traditionally, organizations are established in precise geographic location (regarding the where interrogative) and time zone;

• the why into main reasons and motivation intentions. This interrogative is about motivations that drive organizational behaviors, concerns and decision-making.

To allow a comprehensive description of the enterprise, and to create the framework classifications (cells) the interrogatives are combined with the audience perspectives (rows). The rows represent different perspectives on the enterprise from the viewpoint of different stakeholders. There are also six different perspectives in the ZF which are:

• Planner perspective: for example, the board of the company. This perspective is concerned about the position of the enterprise in its domains;

• Owner perspective: for example, the CEO of the company. This perspective is concerned about the business itself externally and internally;

• Designer perspective: for example, the business architect. This perspective is concerned about translating the business perspective into the enterprise building blocks necessary for it to operates;

THEZACHMANFRAMEWORK 5

• Builder perspective: for example, the enterprise engineers. This perspective is concerned in building or designing the architecture developed in the previous row;

• Sub-contractor perspective: for example, the software developers. This perspective is concerned about developing and implements the constructional designs builder in the previous row;

• Enterprise perspective: it represents the perspective of a running and physically enterprise. Once it explained, a quick example will be given showing how the first line of ZF should be

after being populated. The idea of the first row is to identify the things that are important for the company and as being from the planner perspective, it should care about the company’s domain, business drivers and it should be concerned with representing the business functions. In the first column, which regards the inventory, its content should be a simple list of things; a high level of objects or assets that the company consider important based on the enterprise strategic plan, enterprise goals and enterprise missions. The second column, which regards the process flows, should contain a list of processes or functions that the organization performs. The third column, which regards the distribution networks, should contain the geographic location of the company, considering where is its activities and artifacts. The fourth column, which regards the responsibilities assignments, should contain the person or people who is related with the major artifacts of the company and/or a list of organizations that are important to the business. The fifth column, which regards the timing cycles, should contain how each process evolves related with timeline. The six and last column, which regards the motivation, should contain the goals and objectives of the company (Sousa, Tribolet, & Caetano, 2007). The following table illustrate what the first row should looks like if filled with data of a running shoes producer company for example.

What How Where Who When Why

Scope Running; Sports; Shoes;

Designing; testing;

manufacturing; documenting;

selling; distributing; marketing;

Netherlands; China;

Suppliers; Partners; Resellers;

6 months for each

new product release;

Entertainment; Wellbeing;

Health;

Table 1. Identification Row filled with data of a fake running shoes producer company.

3. Process Deliverable Diagram

The following Process Deliverable Diagram (PDD) makes reference of the Zachman Framework (ZF). It is divided in six main activities representing the ZF’s rows (different perspectives inside the framework) and inside of each main activity there is also six sub-activities representing the ZF’s columns (primitive interrogatives). Each sub-activity has it own deliverable which are the cells of the framework matrix. The sub-activities in the PDD have no order to be performed and are equally important for the abstractions of the enterprise, once that each cell is unique and do not depend of the others to be fulfilled, although it has to be coherent to the other cells in the same row and column (Sowa & Zachman, 1992). Differently from the columns the rows must be fulfilled in a top-bottom approach, that is, from the higher level to the lowest level of abstraction (Pereira & Sousa, 2004). Most of the concepts on the deliverable side of the following PDD (right-hand side) are closed because their sub-concepts are not known or not relevant to expand in this context, since the main objective is to depict an overview of the ZF activities and deliverables.

THEZACHMANFRAMEWORK 6

Figure 2 - PDD of the Zachman Framework. This figure illustrates the process side and the deliverable side of the ZF.

THEZACHMANFRAMEWORK 7

The following tables (activity and concept tables) describes the process and the deliverable side of the PDD above, respectively. The definitions bellow were acquire from the Zachman Institute for Framework Advancement (ZIFA) document (Zachman J. , 2003). ActivityTable:

ACTIVITY SUB-ACTIVITY DESCRIPTION

Identification of Enterprise Objectives

Identify Motivation Identification in common language of the enterprise goals, objectives, strategies and other motivation aspects.

Identify Inventory Identification of the things (objects, assets) that are important to the company and affects it direction and purpose.

Identify Process Identification of the process and functions (in a high level description) that the enterprise performs

Identify Roles Identification of the organizations which the enterprise assign responsibility to work with.

Identify Network Identification of the locations where the organization operates.

Identify Timing Identification of the events to which the enterprise responds.

Definition of the Business

Functionalities

Create Business Plan Creation of a model based on the ENTERPRISE MOTIVATION LIST, with the organization objectives and strategies.

Create Conceptual Model

Creation of a model that describes the things that are important to the enterprise which is listed in the ENTERPRISE INVENTORY LIST. It can be represented in a entity-relationship (ER) model.

Create Business Process Model

Creation of a model of the actual business process that the organization performs almost independent of any implementations and systems consideration and organizational constraints.

Create Organizational Chart Creation of the organizational chart with the allocation of responsibilities and products specifications.

Create Business Logical Network

Creation of a model of the business logical network expressing the communication between all the locations (voice, mail, ship, truck, rail, etc.) and also the type of the enterprise's facilities (warehouse, head-quarters, etc.).

Create Master Schedule Creation of a model of the business events cycles that contains an initial event and the elapsed time.

Model of the Business

Functionalities and Information

System

Model Business Rules This activity is about creating a logical model of the business rules and constraints regarding the BUSINESS PLAN objectives and strategies.

Model Logical Data

This activity is about identifying and describing the entities and their relationships regarding the CONCEPTUAL MODEL without paying attention to physical and/or technical implementations

Model Application Architecture

Creation of a model of the logical systems implementation (technology free). It should contain the inputs and outputs, the control mechanisms, human and machine boundaries, manual and automated tasks, etc.

Model Human Interface Architecture

Creation of a logical model of the roles of the parties like management, administration, engineering, marketing, etc. and also of the logical specification of the work products like graphics, video, voice, etc. Also is depicted the potential interaction between people and technology

Model Distributed System Architecture

Creation of a logical distribution system architecture of the BUSINESS LOGICAL NETWORK depicting what information is created in the different locations and facilities and where and when it will be used.

Model Process Structure Creation of a logical systems specification model of system events and processing cycles.

Design Business Rules Model This activity is about creating a physical model of the business rules converted into the elements of the software program design

THEZACHMANFRAMEWORK 8

Define and Implement Information

System

Design Data Architecture

Designing a physical and technical representation of the ENTERPRISE INVENTORY LIST. This activity is also concerned with the technology that will be used for the implementation, so the style of the model depends on the definition of this technology.

Design System Designing the implementation of the logical systems or application architecture solution. Pseudo-code is produced here.

Design Security Architecture

Designing the physical model of the ORGANIZATIONAL CHART regarding the interface of every individual and the technology and the presentation format of the working product

Design Technology Architecture This activity is about physically depicting the technology environment of the organization showing the actual hardware and system software

Design Control Structure Designing the physical model of the system events and physically processing cycles.

Implement System

Elements

Implement Rules Design This activity is about specifying the business rules in order to prepare it to be enforced in the enterprise

Implement Data Design Definition of all data objects described in the DATA ARCHITECTURE and the data definition language required for implementation

Implement Programs

Implementation of programs modules (application components), based on the design and pseudo-code from SYSTEM DESIGN, that can be used in more than one application.

Implement Security Architecture Defining for each individual in the ORGANIZATIONAL CHART the system access permissions and the specification of the job that they are authorized to perform

Implement Network Architecture This activity is about defining the address and communications protocols of the TECHNOLOGY ARCHITECTURE

Implement Schedule Definition Defining the machine cycles and interrupts

Instantiate Information

System Implementation

Instantiate Rules This activity is about enforcing the business rules into the enterprise, supporting and maintain it

Instantiate Data Implementation of the database, inclusion of initial data and maintenance and support in the database management system.

Instantiate Programs This activity is about linking and converting the program modules into real and executable applications.

Instantiate Security Architecture Implementation, support and maintenance of the SECURITY ARCHITECTURE

Instantiate Network Architecture This activity is about the implementation and maintenance of the communication facilities

Instantiate Business Schedule This activity is about Instantiating the actual business schedule

Table 1 - Activity table related to the PDD of the Zachman Framework

ConceptTable:CONCEPT DESCRIPTION

ENTERPRISE MOTIVATION LIST

A simple list containing a common language description all the goals, objectives, strategies and other motivation aspects of the enterprise. Some of the possible modelling languages are: RP (Rich Pictures – The use of symbols to describe concepts in a non formal way) and English (Noran, 2003)

ENTERPRISE INVENTORY LIST

A simple list of things (objects, assets) that are important for the company and affects it actions. The content of the list is described in a high-level way of communication. Some of the possible modelling languages are: RP and English (Noran, 2003)

ENTERPRISE PROCESS LIST A simple list of functions and process, in a high-level description, that the enterprise performs. Some of the possible modelling languages are: RP and English (Noran, 2003)

ENTERPRISE ROLES LIST A simple list of organizations that the enterprise assign responsibility to work with. Some of the possible modelling languages are: RP and English (Noran, 2003)

THEZACHMANFRAMEWORK 9

ENTERPRISE NETWORK LIST A simple list containing the locations where the enterprise will operate. Some of the possible modelling languages are: RP and Map (Noran, 2003)

ENTERPRISE EVENTS LIST A simple list containing the overall business events to which the enterprise responds. Some of the possible modelling languages are: RP and English (Noran, 2003)

BUSINESS PLAN

A model of the business plan that contains the business operations objectives and strategies regarding the ENTERPRISE MOTIVATION LIST. A possible modelling language to describe this, according to (Noran, 2003) is Structured English.

CONCEPTUAL MODEL A model of the things that are important to the enterprise listed in the ENTERPRISE INVENTORY LIST. A possible modelling language to perform this model is the E/R diagram (Sowa & Zachman, 1992)

BUSINESS PROCESS MODEL A model of the business process and functions regarding the ENTERPRISE PROCESS LIST. A possible modelling language for the development of this model is UML Activity Diagram (Noran, 2003)

ORGANIZATIONAL CHART A model of the organizational chart with the responsibilities allocation with the product specification. A possible modelling language for this deliverable is UML Use Case (Noran, 2003)

BUSINESS LOGICAL NETWORK

A model of the enterprise logical network with the description of their connections (voice, email, ship, rail, etc.) and also with the type of the enterprise's facilities. For this deliverable (Noran, 2003) says that a possible modelling language is a simple graph.

MASTER SCHEDULE A model of the business cycles with an initial event and the elapsed time. This can be produced as a Gantt Chart (Noran, 2003)

BUSINESS RULES MODEL

Business Model that contains the logical rules specifications in terms of their intent and constraints regarding the objectives and strategies identified and described in the BUSINESS PLAN. This can be described as structured English (Noran, 2003)

LOGICAL DATA MODEL Logical model (technical free description) regarding the CONCEPTUAL MODEL, containing the entities and relationships between them. This can be modelled as a E/R Diagram or UML Class Diagram (Noran, 2003)

APPLICATION ARCHITECTURE Logical system model (technical free description) regarding the BUSINESS PROCESS MODEL. This deliverable can be modelled as a Data Flow Diagram (Sowa & Zachman, 1992)

HUMAN INTERFACE ARCHITECTURE

Logical model of the roles and products specifications and the interaction between people and technology. This can be modelled as a UML Use Case (Noran, 2003)

DISTRIBUTED SYSTEM ARCHITECTURE

Logical model of the system network distribution depicting what kind of information is created (in which location) and it shows where and when this information will/should be used. This deliverable can be modelled as a UML Component Diagram (Noran, 2003)

PROCESS STRUCTURE

Logical model containing the systems specification of system events and processing cycles. This model should contain the the system events that cause specific data transformation and trigger the transition from one valid state to another. This deliverable can be modelled as Data Flow Diagram (Noran, 2003)

BUSINESS RULES DESIGN Physical model of the BUSINESS RULES MODEL converted into elements of software program design. This can be represented as Structured English (Noran, 2003)

DATA ARCHITECTURE

Physical and technical description of the LOGICAL DATA MODEL. It contains a technical approach on the entities and relationships described previously. This deliverable can be modelled as a UML Class Diagram (Noran, 2003)

SYSTEM DESIGN

Design of the system implementation solution where in a high level abstraction it will be a structure chart and in a lower level of abstraction it will be described as activity diagrams. This can me modelled as a Structured Chart (Sowa & Zachman, 1992)

SECURITY DESIGN

Physical model of the ORGANIZATIONAL CHART with a higher level of details regarding the interface between the individuals and the technology and also the presentation format of the working product. This deliverable can be represented as a UML Use Case (Noran, 2003)

TECHNOLOGY ARCHITECTURE Physical model of the enterprise's technology environment depicting the actual hardware and software needed in the different facilities and locations. This deliverable can me modelled as a UML Deliverable Diagram (Noran, 2003)

THEZACHMANFRAMEWORK 10

CONTROL STRUCTURE Physical model of the system events and physically processing cycles by means of control structure which pass the control from one module to another. It can be modelled as a UML Sequence Diagram (Noran, 2003)

RULES DEFINITION A detailed description and specification of the business rules regarding the BUSINESS RULES DESIGN. The rules specifications can be represented in a specific programming language (Noran, 2003)

DATA DESIGN Data design containing the definition of all data objects identified in the DATA ARCHITECTURE and also the data definition language. Is represented as a Data Base Schema (Noran, 2003)

PROGRAM Implemented and full working program component. It is represented by a specific programming language (Noran, 2003)

SECURITY ARCHITECTURE

Security architecture with, for every individual of the ORGANIZATIONAL CHART, the respectively system permissions and the specification of the job that he/she is allowed to perform. It is represented by a UI Programming Language (Noran, 2003)

NETWORK ARCHITECTURE Network architecture containing the specific definition of the addresses and communication protocols of the TECHNOLOGY ARCHITECTURE. It is represented by internet protocols like TCP/IP (Noran, 2003)

SCHEDULE DEFINITION Document with the definition of machine cycles and interrupts. It can be described in Structured English (Noran, 2003)

RULES The business rules and information technology are imposed to the business. This is the scenario from the perspective of the user (Zachman & Sowa, 1992).

DATA This is the final product from the perspective of the user (Zachman & Sowa, 1992), so it should be a real database application up and running.

EXECUTABLE APPLICATION Executable program originated from the linking and/or adaptation of the PROGRAM components. This is what the users of the enterprise or service experience physically (Ertaul & Sudarsanam, 2005).

SECURITY Security system up and running with trained people using it. As being part of the functioning enterprise perspective, this should be considered the final product from the perspective of the user (Zachman & Sowa, 1992).

NETWORK Up and running communications facilities This is what the users of the enterprise or service experience physically (Ertaul & Sudarsanam, 2005).

SCHEDULE Business Schedule is being used and answered by the enterprise's staff using the information system. This is the final product from the perspective of the user and staff (Zachman & Sowa, 1992).

ENTERPRISE OBJECTIVE

This is the contextual view of the enterprise, describing the purpose, strategy, etc. of the organization (Villiers, 2001). It has the following sub-concepts aggregated to it: ENTERPRISE MOTIVATION LIST, ENTERPRISE INVENTORY LIST, ENTERPRISE PROCESS LIST, ENTERPRISE ROLES LIST, ENTERPRISE NETWORK LIST and ENTERPRISE EVENTS LIST

BUSINESS FUNCTIONALITY

This is the conceptual view of the organization and it describes the enterprise and how it information systems should work (Villiers, 2001). It has the following sub-concepts aggregated to it: BUSINESS PLAN, CONCEPTUAL MODEL, BUSINESS PROCESS MODEL, ORGANIZATION CHART, BUSINESS LOGICAL NETWORK, MASTER SCHEDULE

INFORMATION SYSTEM DESIGN

This is the logical view of the information system of the enterprise and depicts how the organization's system will satisfy the enterprise needs (Villiers, 2001). It has the following sub-concepts aggregated to it: BUSINESS RULES MODEL, LOGICAL DATA MODEL, APPLICATION ARCHITECTURE, HUMAN INTERFACE ARCHITECTURE, DISTRIBUTED SYSTEM ARCHITECTURE and PROCESS STRUCTURE

INFORMATION SYSTEM

This is the physical view of the organization and it describes of how the information systems will be implement (Villiers, 2001). It has the following sub-concepts aggregated to it: BUSINESS RULES DESIGN, DATA ARCHITECTURE, SYSTEM DESIGN, SECURITY DESIGN, TECHNOLOGY ARCHITECTURE and CONTROL STRUCTURE

INFORMATION SYSTEM ELEMENT

This is the components view of the organization and it describes the specific implementation details of the system elements (Villiers, 2001). This view is less architectural than the rest and it is more about implementing the information generated so far. It has the following sub-concepts aggregated to it: RULES DEFINITION, DATA DESIGN, PROGRAM, SECURITY ARCHITECTURE, NETWORK ARCHITECTURE, SCHEDULE DEFINITION

RUNNING ENTEPRISE This is the 'up and running' view of the organization and it describes the operational environment and the functioning integrated systems (Villiers,

THEZACHMANFRAMEWORK 11

2001). It has the following sub-concepts aggregated to it: RULES, DATA, EXECUTABLE APPLICATION, SECURITY, NETWORK, SCHEDULE

Table 2 - Concept table related to the PDD of the Zachman Framework

4. Related Literature

Back in 1987 when Zachman published the journal with the first version of the ZF, in that time known as the ‘Framework for Information Systems Architecture’, he was focused in creating a framework to help to build an architecture for defining and controlling the interfaces and the integration of all of the components of a complex system (Zachman J. A., 1987). He also explains the origin of his inspiration saying that the ZF represents the intersection between two historical classifications that have been in use for thousands of years, which are the transformations and the interrogatives (Zachman J. A., 2008). The ZF has received a considerable amount of updates since it first appearing and in 2011, Zachman presented the 3.0 version, which is the most updated version of his framework (Zachman J. P., 2011). John A. Zachman was born in 1934 and worked for IBM for 26 years, where he wrote the first version of the ZF. He is being focusing in Enterprise Architecture since 1970 and he is also the founder and chairman of his own consulting and education business called Zachman International® (Zachman J. A., 2008).

According to Lankhorst (Lankhorst, 2013, p. 3), enterprise architecture is “a coherent whole of principles, methods and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure” and this whole view of the enterprise is that ZF and a few more frameworks for enterprise architecture modelling, like The Open Group Architecture Framework (TOGAF), helps to achieve. TOGAF is also (as mentioned before) an enterprise architecture framework. It was first developed in 1995 and it provides a comprehensive guidance about IT resources, decision making and architecture principles, but it does not provide much details regarding the maintenance and planning aspects, when in comparison with ZF. (Urbaczewski & Stevan Mrdalj, 2006).

As mentioned before, the Zachman Framework can be used for mapping and designing any complex system and it application can be extended for a lot of different subjects. For example, Ertaul and Sudarsanam (Ertaul & Sudarsanam, 2005) gives an overview of how ZF helps to define and create tools for securing an enterprise regarding hackers attack and corporate information leaking. In another example, the proposed framework usage is regarding standards and regulations about sustainability and how the ZF could help in developing implementation strategies for sustainability standards (Rachuri, Sarkar, Narayanan, Lee, & Witherell, 2011).

Summarizing, the Zachman Framework, if applied with knowledge will provide great benefits for viewing, defining and treating the complexities of an organization, as well as to control it in a changing world.

THEZACHMANFRAMEWORK 12

5. Bibliography

Bahill, T., Botta, R., & Daniels, J. (2006). The Zachman Framework Populated with Baseball Models. Journal of Enterprise Architecture, 50-68.

Barekat, V., Nejad, E. B., & Alavi, S. E. (2013). Definition of zachman framework cells based on service oriented architecture. International Journal of Scientific and Research Publications, 670-677.

Ertaul, L., & Sudarsanam, R. (2005). Security Planning Using Zachman Framework for Enterprises. Proceedings of EURO mGOV, (pp. 153-162).

Lankhorst, M. (2013). Enterprise Architecture at Work. In M. Lankhorst, LinkEnterprise Architecture at Work: Modelling, Communication and Analysis (pp. 1-10). Springer Science & Business Media, 2012.

Lapalme, J., Gerber, A., Merwe, A. V., Zachman, J., Vries, M. D., & Hinkelmann, K. (2015). Exploring the future of enterprise architecture: A Zachman perspective.

Noran, O. (2003). An analysis of the Zachman framework for enterprise architecture from the GERAM perspective. ANNUAL REVIEWS IN CONTROL, 27(2), pp. 163-183.

Pereira, C. M., & Sousa, P. (2004). A method to define an Enterprise Architecture using the Zachman Framework. Proceedings of the 2004 ACM Symposium on Applied Computing (SAC) (pp. 1366-1371). NY: ACM New York, NY, USA.

Rachuri, S., Sarkar, P., Narayanan, A., Lee, J. H., & Witherell, P. (2011). Towards a Methodology for Analyzing Sustainability Standards using the Zachman Framework. 18th CIRP International Conference on Life Cycle Engineering.

Sousa, P., Tribolet, J., & Caetano, A. (2007). Applying the Zachman Framework Dimensions to Support Business Process Modeling. In Digital Enterprise Technology (pp. 359-366). Springer US.

Sowa, J. F., & Zachman, J. A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 590-616.

Urbaczewski, L., & Stevan Mrdalj, E. M. (2006). A Comparison of Enterprise Architecture Frameworks. Issues in Information Systems, 18-23.

Varga, M. (2003). Zachman framework in teaching information systems. Information Technology Interfaces, 25th International Conference on Information Technology Interfaces, (pp. 161-166).

Villiers, D. d. (2001). Using the Zachman Framework to Assess the Rational Unified Process. Retrieved from IBM Developer Works: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/mar01/UsingtheZachmanFrameworktoAssesstheRUPMar01.pdf

Zachman, J. (2003). The Framework for Enterprise Architecture - Cell Definitions. Zachman Institute for Framework Advancement.

Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26, 276-292.

Zachman, J. A. (2008). About the Zachman Framework. Retrieved from Zachman International: https://www.zachman.com/about-the-zachman-framework

Zachman, J. A. (n.d.). About John A. Zachman. Retrieved from Zachman International: https://www.zachman.com/about-us/about-john-a-zachman

Zachman, J. P. (2011). The Zachman Framework Evolution by: John P. Zachman. Retrieved from Zachman International: https://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution