The Zachman Framework for Enterprise Architecture: An Overview
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The Zachman Framework for Enterprise Architecture: An Overview

on

  • 766 views

 

Statistics

Views

Total Views
766
Views on SlideShare
766
Embed Views
0

Actions

Likes
0
Downloads
29
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Zachman Framework for Enterprise Architecture: An Overview Document Transcript

  • 1. The Zachman Framework for Enterprise Architecture: An Overview by Thomas A. Hokel Framework Software, Inc.’s Structure® Suite provides the organization, classification and access tools for implementing the Zachman Framework for Enterprise Architecture. This Framework was initially “created” by John A. Zachman and published in 1987. The Framework organizes and categorizes architectural representations in a way that provides a context for understanding the relationship between and among separate sets of architectures. These architectures are the “glue” that holds together the design artifacts (business strategy models, organization charts, data models, process models, network models, work flow models, business rules, application structure charts, program/module specifications, etc.) of the enterprise or any other complex product that can be engineered. The Framework organizes the architectures of these descriptive representations to provide understanding of their relationship to each other. This is important in order to create, develop, maintain and change the enterprise. The Zachman Framework for Enterprise Architecture The Framework serves as an analytical, organization and classification tool by providing specific, normalized reference points (cells) that are be used to “hold” the architecture products Different Perspectives (i.e., primitive models) and, in the case of Structure, may When an individual (owner) wants to build a building, he hires an also be used to hold a myriad of other relevant artifacts (i.e., architect. The owner provides the architect with a conceptual composites, standards, roles, methods, techniques, tools, training, understanding of his requirements; for example, his motivation for glossaries, and references) of development efforts. needing it, the functions the building would serve, where the building would be located, who would occupy and utilize it, and perhaps material preferences and operating schedules. The Zachman Framework for Enterprise Architecture architect prepares drawings of the building with those The concepts incorporated in the Zachman Framework for requirements and constraints in mind. These drawings enable the Enterprise Architecture supported by Structure were derived owner and the architect to reach a common ground of from classical architecture and aircraft manufacturing analogs, understanding and a level of confidence in each other. both of which have a proven track record of producing complex constructs requiring an engineered approach to development and Once the drawings have been approved they can be used by the modification. John A. Zachman initially formalized these concepts designer to prepare the architect’s plans. When the design is in his landmark, and now legendary, article “A Framework for complete and has been approved, the owner hires a builder. The Information Systems Architecture” that appeared in the 1987 IBM builder is constrained by the laws of physics and available Systems Journal, Volume 26, Number 3. technology. Working from the architect’s plans, the builder prepares detailed construction plans for the building, hires Developing, changing and maintaining the enterprise requires subcontractors and constructs the building. The owner receives a different kinds of architectural representations or descriptions, for certificate of occupancy, moves in, and should be quite pleased example, contextual models, conceptual models, logical design with the end results. models, physical technology models, detailed component specifications, et cetera, that are defined and used by different The concepts of owner, designer, and builder also apply to participants for different purposes and, hence, have different manufacturing products. The Work Breakdown Structure is points of view and different constraints. These architectural analogous to the Architect’s Drawings, the Engineering Design is representations, although they are integrated, are inherently analogous to the Architect’s Plans, and the Manufacturer’s delineated by six perspectives (views) normally defined as: Scope, Engineering Design is analogous to the Contractor’s Plans. Business Model, System Model, Technology Model, Components, These proven architecture and manufacturing concepts used to and Functioning Enterprise. These perspectives are reflected in the engineer complex structures and products can be applied to Framework as rows. Each perspective is then further classified engineering the enterprise itself. The primary perspectives and into six focuses (abstractions or topics) normally defined by the their fundamental (primitive) models relative to each discipline are following interrogatives: What, How, Where, Who, When, and shown in the following table. Why. These focuses are reflected in the Framework as columns. The thirty-six (6 X 6) frames at the core of the integrated Framework are referred to as cells. Copyright 1993-2008 Framework Software, Inc. Page 1
  • 2. The Framework for a Product Architecture Manufacturing Enterprise Architecture A representation of the Framework can be formed by treating the perspectives as rows and the focuses as columns. Each perspective OWNER Architect’s Work Break- Business defines, completely and holistically, the product from that point of Drawings down Structure Model view. Within a perspective, it is also convenient and natural to focus or concentrate on a selected aspect or topic of the product. DESIGNER Architect’s Engineering System By integrating the perspectives with the closed set of Plans Design Model interrogatives, a framework can be formed. BUILDER Contractor’s Manufacturer’s Technology The Framework provides a classification schema or “periodic” Plans Engineering Model table of elements. As Zachman observes, “All formal disciplines Design have some means by which to organize and classify its discoveries Different Perspectives and products, whether the field of knowledge is chemistry, biology, mathematics, physics, or information.” Each perspective (Owner, Designer, Builder) must take into account the requirements and constraints of the other perspectives. The Framework helps facilitate the communication of ideas during For example, the architect must design a building for the purpose the development of complex products, whether they are buildings, that the owner intends for the building. Moreover, the architect aircraft or enterprises. Literally, it provides a “frame of reference.” must design the building given the owner’s conceptual constraints, Although the Framework describes the same thing, it is convenient but not distort it so that it is not recognizable by the owner. And and natural to view the product from the perspectives of the the builder must construct the physical building given the different disciplines involved in its development. designer’s logical constraints, but not distort it so that it is not As a communications device and facilitator of change, the recognizable by the designer. It is this engineering approach that Framework provides an elegant tool of cognition. It is a natural, results in producing a product that is desirable. simple, straight-forward, and powerful approach to addressing Understanding the requirements and constraints necessitates complex ideas, complex systems and complex products. communication from perspective to perspective so that the The complete, extended Framework for a product is depicted in transformation from concept to reality can take place. The the following matrix schema. The Planner perspective channels the Framework points the vertical direction for understanding and ensuing development activities by defining what is in and what is communication between perspectives. out of scope of the product. It defines the context of the bounds of the Framework for planning purposes and represents the planner’s perspective. The Subcontractor perspective contains the detailed Different Focuses Inherent in each perspective are six focuses or abstractions. Each representations and represents the out-of-context or components focus addresses a fundamental question: What is it made of? How perspective. The last perspective, or target, is not a descriptive does it function? Where are things located? Who is involved? representation – it is the realized product itself. When do events happen? Why are things done? The manner in which the answers to these questions are described, of course, What How Where Who When Why depend upon the perspective (i.e., discipline) answering these questions. Planner To quote John A. Zachman, “By abstracting out one of these six Owner variables and holding the other five constant, but not losing sight of them, attention can be intently focused on only one variable.” Designer For example, the What variable or focus for Classical Architecture Builder concerns itself with Material; for Manufacturing, a Bill of Materials; and for Enterprise Architecture, Data Models. The Sub- contractor following chart roughly depicts the analogous concepts of the What, How and Where variables. Product The Framework for a Product What How Where The perspectives relate the cells horizontally. The focuses relate the cells vertically. Therefore, all of the cells formed by the matrix Classical Material Function Location schema are related horizontally and vertically. They are integrated Architecture because they describe the same, whole thing. As a classification schema, the Framework is generic and can be used for describing almost anything! One of the attractions to the Framework is its Manufacturing Bill of Functional Drawings simplicity as a tool of cognition. The Framework has a Materials Specs “wholeness” and a “rightness” to it. Enterprise Data Function Network Architecture Models Models Models Different Focuses Copyright 1993-2008 Framework Software, Inc. Page 2
  • 3. The Framework for Enterprise Architecture Architectures The concepts of enterprise architecture mirror the concepts of the By providing a formal means for understanding a complex older, successful disciplines found in classical architecture and product, any complex product including enterprises, the manufacturing. The owner’s perspective corresponds to the Framework enables communication, understanding and integration conceptual business requirements of the enterprise. The designer’s among the various participants involved in developing or changing perspective corresponds to the logical system design models. The the product. Architecture is the “glue” that holds the product builder’s perspective corresponds to the physically constrained together. The Framework defines sets of architectures that contain technology models – whether they are automated or manual. the architectural representations of the product. Architectures depict the product’s contextual, conceptual, logical, physical and out-of-context fundamental (primitive) elements. This What How Where Who When Why depiction promotes integration of the relationships within, between Scope and among the sets of architectures. If a piece of the architectural set is not made explicit, it is implicit and subject to erroneous Business assumptions, which introduce risk into all aspects of development, Model maintenance and change. System Model There is no single architecture, no one way of depicting a perspective. Since there are multiple perspectives, there are Technology Model multiple architectures. Additionally, because each discipline describes the product from each of the focal topics, there are Components multiple and varied architectures. Functioning Architectures are also additive and complementary. Each Enterprise architecture for a given perspective carries the constraints and The Zachman Framework for Enterprise Architecture requirements of the architectures above it. At the same time, the architectures below it complement the architectures above it by Each column focuses on one aspect of the architectural depicting information not found in the above architectures. representation for each of the perspectives. The answer to What always relates to some type of entity but each perspective will The Framework is comprised of many different sets of describe the answer to that question differently. An entity might be architectures. It neither prescribes nor proscribes particular a person, place, thing, or event. Depending on the perspective, it architectures. Nor does the Framework prescribe or proscribe might be a business entity, a logical entity or a physical entity. different approaches, standards, methods, tools or techniques used by the disciplines defining those architectures. It is neutral, and For the Scope perspective, an entity would be something in the says nothing, with respect to development methodologies since it natural, physical world, and expressed in a bounding list of does not specify tasks, dependencies, resources, controls, “things” (business entities). For example, “Customers” would be a deliverables, et cetera. Of course, the Framework can help you high level aggregation of some things of interest and potential evaluate and define your chosen standards, methodologies and inclusion in the ensuing modeling activities. tools. Since the Business Model row represents conceptual models, entity would be thought of in terms of the actual things in the business world and the thought expressed and/or modeled in a Descriptive and Architectural Representations natural semantic language. For the System Model perspective, The cells constitute the core matrix of the Framework. While the “Customers” would be viewed in logical design terms as a perspectives differ from row to row, each column manifests a “Customer” data entity and be expressed in logical data model single abstraction, expressed as a fundamental interrogative. form. For the Technology Model perspective, “Customer” would Additionally, architectural representations of the content of the be considered in technical terms and modeled as a physical data cells adhere to a simple generic meta-model. For example, the entity, for example, a database table. For the Components meta-model of the cells formed by the What column involves perspective, “Customer” would be a detailed specification of a entities and their relationships between one another. The storage entity, a data file, a record or set of records called entity/relationship (thing-to-thing) meta-model characterizes each “Customer.” Finally, for the Functioning Enterprise perspective, of the What cells. See the Zachman Framework at the end of this which is the actual enterprise not a representation, data would be overview for the other generic column meta-models. stored in an actual structured database table called “Customer.” Each cell is different from the others. Each requires or implies To answer the question How, one must describe business functions certain content in the others. And each constrains the content of and processes within the natural world in natural language for the the others. Of course, there is a cost for spending time providing Scope and Business Model perspectives; logical system processes the detail of the contents of each cell, for establishing architectures for the System Model perspective; technical application processes – for making cells explicit. On the other hand, there are risks for the Technology Model perspective; and program/module involved for not providing details of the contents of each cell – for processes for the Components perspective. not establishing architectures – for leaving cells implicit or at insufficient levels of detail. These risks can also be measured in Each of the other columns operates similarly as each provides part time and/or dollars, for example, when project work has to be of the complete description. See the Framework at the end of this redone or scrapped because wrong assumptions were made, overview for examples of the primitive models in other cells. resulting in poor decisions, resulting in unproductive work. Copyright 1993-2008 Framework Software, Inc. Page 3
  • 4. Framework Values with another, but also serves as a conduit through which disparate Architecture is an asset-based long-term strategy – not an expense. disciplines can begin to understand and reuse the approaches, “Enterprise Architecture is an investment you make to enable you standards, roles, methods, techniques and tools of other disciplines to do the things you are otherwise unable to do,” John A. – bringing new ways to handle new implementations. Zachman. Furthermore, the value of the Framework expands exponentially A value that the Framework provides is a more orderly and when one considers change to an enterprise. “The end state coordinated approach to all aspects of development and safely vision,” submits John A. Zachman, “should be the accumulation of changing products that maintain their relevance in a dynamic all models such that every cell is explicitly defined, enterprise- marketplace. The Framework partitions any complex thing into wide, horizontally and vertically integrated, at an excruciating focuses which provide formalisms for each discipline’s level of detail in order to approach change in a surgical fashion.” perspective. Negotiation and compromise are not eliminated, but Most enterprises are in critical condition and struggling for their they are usually minimized to adjacent perspectives. Additionally, lives in the age of the concepts revolution. If they cannot tap the the results of one successful development effort, even if it is for talent and resources within themselves and leverage the talent and just one cell, can be leveraged and serve as the basis for other resources outside themselves, they will never survive long enough development efforts, thereby shortening the lead time required for to reach the end state vision. The Framework provides the producing new implementations (i.e., reduced cycle times). architectural concepts for tapping that talent and those resources. The Framework encompasses the perspectives of all disciplines, business problem approaches, enterprise engineering development methodologies, quality manufacturing approaches, architectural The Structure Suite provides the document and model thinking, construction processes, et cetera. The Framework not management organization, classification and access tools for only betters the understanding of one discipline or perspective reviving the enterprise. WHAT HOW WHERE WHO WHEN WHY ZACHMAN Entity/ Process/ Node/ Agent Event/ End/ FRAMEWORK Relationship Input-Output Line /Work Cycle Means CONTEXTUAL List List List List List List Scope of of of of of of (Planner) Things Processes Locations Organizations Events Objectives CONCEPTUAL Business Business Business Business Business Business Business Entity Process Network Work Flow Event Strategy Model Model Model Model Model Model Model (Owner) LOGICAL Logical System System Human System Business System Data Process Network Interface Event Rule Model Model Model Model Architecture Diagram Model (Designer) PHYSICAL Physical Application Technology Technology Rule Technology Presentation Data Structure Network Event Design Model Architecture Model Chart Model Diagram Model (Builder) OUT-OF- Data Program Network Interface Event Rule CONTEXT Component Component Component Component Component Component Components Specifications Specifications Specifications Specifications Specifications Specifications (Subcontractor) PRODUCT Functioning Data Function Network People Time Motivation Enterprise The Zachman Framework for Enterprise Architecture Framework Software, Inc. • Web site: www.tefg.com/FSI The Enterprise Framework Group • Web site: www.tefg.com Email: tefg-contact@tefg.com • Offices and Sales: 1-970-453-7293 Copyright 1993-2008 Framework Software, Inc. Page 4