Understanding Enterprise Architecture Zachman Framework Introduction A few

  • Slides: 17
Download presentation
Understanding Enterprise Architecture Zachman Framework

Understanding Enterprise Architecture Zachman Framework

Introduction A few hundred years ago, a business represented one person’s small town shop

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.

Introduction The computer age, specifically the advent of distributed systems, created even more complexity

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

Terminology Before moving further, the following terms should be defined: Enterprise Architecture Framework Reification Artifacts

Zachman Framework According to John A. Zachman, his framework is NOT a/an: l Architecture

Zachman Framework According to John A. Zachman, his framework is NOT a/an: l Architecture l Process l Methodology The Zachman Framework IS a/an: l Schema l Ontology l Metamodel l Foundation for defining Enterprise Architecture

Zachman Framework What Identification Definition Representation Specification Configuration Instantiation How Where Who When Why

Zachman Framework What Identification Definition Representation Specification Configuration Instantiation How Where Who When Why

Reification Transformation Each row represents a distinct and unique perspective from which an enterprise

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: l Executive (Planner/Scope) Business Mgmt. (Owner/Enterprise Model) Architect (Designer/System Model) Engineer (Builder/Technology Model) Technician (Implementer/As Built) l Enterprise (Users/Functionality) l l

Communication Interrogatives Each column represents a fundamental question which must be asked answered by

Communication Interrogatives Each column represents a fundamental question which must be asked 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: l l l What – Data How – Function Where – Network Who – People When – Time Why – Motivation

Intersections Each cell of the Zachman Framework is an intersection of a single row

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.

Contextual Models These models are derived by asking the fundamental questions from the executive

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: l l l Inventory (What) Processes (How) Locations (Where) Organizational Units and Roles (Who) Event Triggers and Cycles (When) Goals (Why)

Conceptual Models These models are derived by asking the fundamental questions from the business

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 the artifacts listed in the previous perspective interrelate. The conceptual models are: l l l 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)

Logical Models These models are derived by asking the fundamental questions from the architect

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: l l l Data Model (What) Process Reference Model (How) Global or Site Map (Where) Role Relationships (Who) Event Impact (When) Policies, Regulations, and Standards (Why)

Physical Models These models are derived by asking the fundamental questions from the engineer

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: l l l Data Entity (What) Process Functionality (How) Physical Infrastructure (Where) Responsibilities and Skills (Who) Event States (When) Rules (Why)

Detailed Representations These models are derived by asking the fundamental questions from the technician

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.

Making the Zachman Framework Work Not all rows and columns may be relevant to

Making the Zachman Framework Work Not all rows and columns may be relevant to the organization. For example: l l 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.

The Toolkit To support the efforts of adopting enterprise architecture at this point, the

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

Moving Forward Use the aids and templates to create an effective conversation for enterprise

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’.