Understanding Enterprise Architecture Zachman Framework

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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