1. Understanding Enterprise Architecture
Zachman Framework

2. Introduction
A few hundred years ago, a business represented one person’s small town shop used to display and sell his products, often those made by his own hands. The growth of the business was typically demonstrated by the inclusion of apprentices and even workers.
The advent of mass-production expanded the size and scope of business even further, creating a business that was no longer constricted to geography. Systems started to be refined and improved.

3. ENTERPRISE ARCHITECTURE
Introduction
The computer age, specifically the advent of distributed systems, created even more complexity in the business model and a new paradigm was needed.
That paradigm is:
ENTERPRISE ARCHITECTURE
A means of perceiving the business logically and managing its strategies and investments to ensure that the organization is capable of meeting its business objectives

4. Terminology
Before moving further, the following terms should be defined:
Enterprise
Architecture
Framework
Reification
Artifacts
These are the definitions for these terms (sources are in parenthesis):
Enterprise has two appropriate definitions:
A project or undertaking that is especially difficult, complicated, or risky (Merriam-Webster Online Dictionary)
A collection of organizations that has a common set of goals (TOGAF 9.1)
Architecture is the formation or construction resulting from a conscious act, such as the manner in which the components of a computer or computer system are organized and integrated. (Merriam-Webster Online Dictionary)
Framework is a skeletal, openwork, or structural system that gives shape or strength. (Merriam-Webster Online Dictionary)
Reification is the process of turning an abstract idea into some tangible, such as computer programming.
Artifacts are objects used independently or as building blocks to large objects.
Copyright: The Art of Service 2008

5. Zachman Framework
According to John A. Zachman, his framework is NOT a/an:
Architecture
Process
Methodology
The Zachman Framework IS a/an:
Schema
Ontology
Metamodel
Foundation for defining Enterprise Architecture
These distinctions were made in an article by Zachman, called The Zachman Framework: The Official Concise Definition. In this article, Zachman defines the framework as:
Schema – An intersection between the Communication Interrogatives and Reification Transformations
Ontology – A theory of a structured set of essential components
Metamodel – A comprehensive collection of ‘architecture’ building blocks
Copyright: The Art of Service 2008

6. Zachman Framework What How Where Who When Why Identification
Definition
Representation
Specification
Configuration
Instantiation
The basic Zachman Framework is usually represented by a 6x6 grid. The columns are the communication interrogatives (What, How, Where, Who, When, and Why), and the rows are the reification transformations (identification, definition, representation, specification, configuration, and instantiation). The purpose of the framework is to classify and organize the enterprise artifacts easily. In essence, anything relevant to the enterprise can fall into and be described using one of the 36 categories based on the intersection of columns and rows within the framework.
A more detailed Zachman Framework is available in the toolkit or through the Zachman International.
Copyright: The Art of Service 2008

7. Reification Transformation
Each row represents a distinct and unique perspective from which an enterprise solution is viewed.
Rows are often hierarchical—that is, the deliverables from each perspective must define the solution completely and translate to the next row.
The rows represent the following
perspectives:
Executive (Planner/Scope)
Business Mgmt. (Owner/Enterprise Model)
Architect (Designer/System Model)
Engineer (Builder/Technology Model)
Technician (Implementer/As Built)
Enterprise (Users/Functionality)
Often, the last row is not represented in enterprise architectures because this row actually represents the enterprise itself, with the previous five (5) rows defining what the architecture of the enterprise is. Sometimes, the first five rows will be represented in terms of contextual, conceptual, logical, physical, and detailed aspects.
Copyright: The Art of Service 2008

8. Communication Interrogatives
Each column represents a fundamental question which must be asked and answered by each of the perspectives.
There is no specific order to the columns, but each column must create a unique metamodel comprising an enterprise architecture component.
The columns and their corresponding components are:
What – Data
How – Function
Where – Network
Who – People
When – Time
Why – Motivation
In essence, what each column represents is a comprehensive architecture for six major components of the enterprise, with requirements fulfilled at each level of the enterprise.
Copyright: The Art of Service 2008

9. Intersections
Each cell of the Zachman Framework is an intersection of a single row and a single column.
Each intersection creates a distinct and unique model within the enterprise.
The following five slides will describe the models created by the intersections.
Copyright: The Art of Service 2008

10. Contextual Models
These models are derived by asking the fundamental questions from the executive perspective.
The deliverables to the architecture are essentially lists of critical artifacts to the enterprise.
The contextual models are:
Inventory (What)
Processes (How)
Locations (Where)
Organizational Units and Roles (Who)
Event Triggers and Cycles (When)
Goals (Why)
Copyright: The Art of Service 2008

11. Conceptual Models
These models are derived by asking the fundamental questions from the business management perspective.
The deliverables to the architecture are relational models. They show how the artifacts listed in the previous perspective interrelate.
The conceptual models are:
Business Entities (What)
Process Relationships: Inputs and Outputs (How)
Organizational Relationships (Where)
Hierarchies, Roles, and Work Products (Who)
Schedules (When)
Objectives and Business Alignment (Why)
Copyright: The Art of Service 2008

12. Logical Models
These models are derived by asking the fundamental questions from the architect perspective.
The deliverables to the architecture create the system logic (diagrams) for the enterprise without regard to a specific implementation in the physical and technical realm.
The logical models are:
Data Model (What)
Process Reference Model (How)
Global or Site Map (Where)
Role Relationships (Who)
Event Impact (When)
Policies, Regulations, and Standards (Why)
Copyright: The Art of Service 2008

13. Physical Models
These models are derived by asking the fundamental questions from the engineer perspective.
The deliverables to the architecture are typically dependent on the technology used to support the enterprise and found in the form of specifications.
The physical models are:
Data Entity (What)
Process Functionality (How)
Physical Infrastructure (Where)
Responsibilities and Skills (Who)
Event States (When)
Rules (Why)
Copyright: The Art of Service 2008

14. Detailed Representations
These models are derived by asking the fundamental questions from the technician perspective.
The deliverables to the architecture are detailed descriptions of the entities identified in the previous perspective(s).
The goal of these cells is to create an framework with little to no ambiguity or assumptions, to create explicitly represented artifacts in the enterprise architecture.
Copyright: The Art of Service 2008

15. Making the Zachman Framework Work
Not all rows and columns may be relevant to the organization.
For example:
Companies driven by inventory may focus on the What column.
Companies driven by process may focus on the How Column.
Companies driven by customers may focus on the Who column.
Companies driven by time may focus on the When column.
Copyright: The Art of Service 2008

16. The Toolkit
To support the efforts of adopting enterprise architecture at this point, the Toolkit provides the following aids and templates:
Zachman Framework Reference Page
Glossary of Terms
Roles and Responsibilities specific to EA
List of Deliverables
Initial Self Assessment
Business Justification
Copyright: The Art of Service 2008

17. Moving Forward
Use the aids and templates to create an effective conversation for enterprise architecture in your organization.
The document, Business Justification, is intended to be used to formalize that conversation and obtain approval to implement EA in part or in its entirety.
Once the concepts of enterprise architecture are understood and your organization has agreed to move forward, the next presentation to view is ‘Developing Enterprise Architecture’.
Copyright: The Art of Service 2008