Zachman framework
Encyclopedia
The Zachman Framework is an Enterprise Architecture framework for enterprise architecture
, which provides a formal and highly structured way of viewing
and defining an enterprise. It consists of a two dimensional classification matrix based on the intersection of six communication questions (What, Where, When, Why, Who and How) with six rows according to reification
transformations.
The Zachman Framework is not a methodology
in that it does not imply any specific method or process for collecting, managing, or using the information that it describes. The Framework is named after its creator John Zachman
, who first developed the concept in the 1980s at IBM
. It has been updated several times since.
The Zachman "Framework" is a schema
for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both whom the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed.
:
In other sources the Zachman Framework is introduced as a framework, originated by and named after John Zachman, represented in numerous ways, see image. This framework is explained as, for example:
Beside the frameworks developed by John Zachman numerous extensions and or applications have been developed, which are also sometimes called Zachman Frameworks.
The Zachman Framework summarizes a collection of perspective
s involved in enterprise architecture. These perspectives are represented in a two-dimensional matrix that defines along the rows the type of stakeholders and with the columns the aspects of the architecture. The framework does not define a methodology for an architecture. Rather, the matrix is a template that must be filled in by the goals/rules, processes, material, roles, locations, and events specifically required by the organization. Further modeling by mapping between columns in the framework identifies gaps in the documented state of the organization.
The framework is a simple and logical structure for classifying and organizing the descriptive representations
of an enterprise. It is significant to both the management
of the enterprise, and the actors involved in the development of enterprise systems. While there is not order of priority for the columns of the Framework, the top-down order of the rows is significant to the alignment of business concepts and the actual physical enterprise. The level of detail in the Framework is a function of each cell (and not the rows). When done by IT the lower level of focus is on information technology
, however it can apply equally to physical material (ball valves, piping, transformers, fuse boxes for example) and the associated physical processes, roles, locations etc. related to those items.
had been involved at IBM in the development of Business System Planning
(BSP), a method for analyzing, defining and designing an information architecture
of organizations. In 1982 Zachman had already concluded that these analyses could reach far beyond automating systems design
and managing data into the realms of strategic business planning and management science in general. It may be employed in the (in that time considered more esoteric) areas of enterprise architecture, data-driven systems design, data classification criteria, and more.
, and a variety of complex engineering projects in industry. He saw a similar approach and concluded that architectures exist on many levels and involves at least three perspectives: raw material or data
, function of processes, and location or networks.
The Information Systems Architecture is designed to be a classification schema for organizing architecture models. It provides a synoptic view of the models needed for enterprise architecture. Information Systems Architecture does not define in detail what the models should contain, it does not enforce the modeling language used for each model, and it does not propose a method for creating these models.
and John Zachman present the framework and its recent extensions and show how it can be formalized in the notation of conceptual graphs. Also in 1992:
Later during the 1990s
In 2008 Zachman Enterprise introduced the Zachman Framework: The Official Concise Definition as a new Zachman Framework standard.
It allows different people to look at the same thing from different perspectives. This creates a holistic view of the environment, an important capability illustrated in the figure.
Each perspective must take into account the requirements of the other perspectives and the restraint those perspectives impose. The constraints of each perspective are additive. For example, the constraints of higher rows affect the rows below. The constraints of lower rows can, but do not necessarily affect the higher rows. Understanding the requirements and constraints necessitates communication of knowledge and understanding from perspective to perspective. The Framework points the vertical direction for that communication between perspectives.
In the 1997 Zachman Framework the rows are described as follows:
In Zachman’s opinion, the single factor that makes his framework unique is that each element on either axis of the matrix is explicitly distinguishable from all the other elements on that axis. The representations in each cell of the matrix are not merely successive levels of increasing detail, but actually are different representations — different in context, meaning, motivation, and use. Because each of the elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell.
The cell descriptions in the table itself uses general language for a specific set of targets. Below the focus of each cell in this particular Zachman Framework is explained
:
Contextual
Conceptual
Logical
Physical
Detailed Representation
Eventually the cells with the detailed representation give Rules detail for (Why); Process detail for (How); Data detail for (What); Role detail for (Who); Location detail for (Where); and Event detail for (When).
There is a sixth row in the current Zachman framework, but it is not used for enterprise architecture — while the enterprise is described by rows one to six, enterprise architecture uses only rows one to five, thus only five rows are shown here.
Since the product development (i.e., architectural artifact) in each cell or the problem solution embodied by the cell is the answer to a question from a perspective, typically, the models or descriptions are higher-level depictions or the surface answers of the cell. The refined models or designs supporting that answer are the detailed descriptions within the cell. Decomposition (i.e., drill down to greater levels of detail) takes place within each cell. If a cell is not made explicit (defined), it is implicit (undefined). If it is implicit, the risk of making assumptions about these cells exists. If the assumptions are valid, then time and money are saved. If, however, the assumptions are invalid, it is likely to increase costs and exceed the schedule for implementation.
The framework is generic in that it can be used to classify the descriptive representations of any physical object as well as conceptual objects such as enterprises. It is also recursive in that it can be used to analyze the architectural composition of itself. Although the framework will carry the relation from one column to the other, it is still a fundamentally structural representation of the enterprise and not a flow representation.
that can be addressed by enterprise architecture. Some feel that following this model completely can lead to too much emphasis on documentation, as artifacts would be needed for every one of the thirty cells in the framework.
John Zachman clearly states in his documentation, presentations, and seminars that, as framework, there is flexibility in what depth and breadth of detail is required for each cell of the matrix based upon the importance to a given organization. An automaker, whose business goals may necessitate an inventory and process-driven focus, could find it beneficial to focus their documentation efforts on What and How columns. Whereas a travel agent company, whose business is more concerned with people and event-timing, could find it beneficial to focus their documentation efforts on Who and When columns. However, there is no escaping the Why column's importance as it provides the business drivers for all the other columns.
-style enterprise modeling. The Zachman Framework can be applied both in commercial companies and in government agencies. Within a government organization the framework can be applied to an entire agency at an abstract level, or it can be applied to various departments, offices, programs, subunits and even to basic operational entities.
Other sources:
Other examples:
, the C4ISR
AE, the DOE AE, and the DoDAF:
(VA) to develop and maintain its One-VA Enterprise Architecture in 2001. This methodology required them to define all aspects of the VA enterprise from a business process, data, technical, location, personnel, and requirements perspective. The next step in implementing the Zachman methodology has been to define all functions related to each business process and identify associated data elements. Once identified, duplication of function and inconsistency in data definition can be identified. The hard job then followed to de-conflict the data definitions and resolve duplicative implementations of the same business function.
The Department of Veterans Affairs at the beginning of the 21st century planned to implement an enterprise architecture fully based on the Zachman Framework.
Eventually an enterprise architecture repository was created at the macro level by the Zachman framework and at a cell level by the meta-model outlined below.
This diagram has been incorporated within the VA-EA to provide a symbolic representation of the metamodel that VA used, to describe the One-VA Enterprise Architecture and to build an EA Repository without the use of Commercial EA Repository Software. The One-VA EA repository was developed using an object oriented database within the Caliber-RM Software Product. Caliber-RM is intended to be used as a software configuration management
tool; not as an EA repository.
However this tool permitted defining entities and relationships and for defining properties upon both entities and relationships, which made it sufficient for building an EA repository, considering the technology that was available in early 2003. The personal motivation in selecting this tool was two-fold:
This diagram emphasizes several important interpretations of the Zachman Framework and its adaptation to information technology investment management
.
Row-six provides measured Return on Investment
for Individual Projects and, potentially, for the entire investment portfolio. Without row-six the Zachman Framework only identifies sunk-cost – the row-six ROI permits the framework to measure benefits and to be used in a continuous improvement process, capturing best practices and applying them back through row-two.
Enterprise architecture
An enterprise architecture is a rigorous description of the structure of an enterprise, which comprises enterprise components , the externally visible properties of those components, and the relationships between them...
, which provides a formal and highly structured way of viewing
View model
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation...
and defining an enterprise. It consists of a two dimensional classification matrix based on the intersection of six communication questions (What, Where, When, Why, Who and How) with six rows according to reification
Reification (computer science)
Reification is the process by which an abstract idea about a computer program is turned into an explicit data model or other object created in a programming language. A computable/addressable object — a resource — is created in a system as a proxy for a non computable/addressable object...
transformations.
The Zachman Framework is not a methodology
Methodology
Methodology is generally a guideline for solving a problem, with specificcomponents such as phases, tasks, methods, techniques and tools . It can be defined also as follows:...
in that it does not imply any specific method or process for collecting, managing, or using the information that it describes. The Framework is named after its creator John Zachman
John Zachman
John A. Zachman is an American business and IT consultant, early pioneer of enterprise architecture, Chief Executive Officer of Zachman International, and originator of the Zachman Framework.- Biography :...
, who first developed the concept in the 1980s at IBM
IBM
International Business Machines Corporation or IBM is an American multinational technology and consulting corporation headquartered in Armonk, New York, United States. IBM manufactures and sells computer hardware and software, and it offers infrastructure, hosting and consulting services in areas...
. It has been updated several times since.
The Zachman "Framework" is a schema
Schema
The word schema comes from the Greek word "σχήμα" , which means shape, or more generally, plan. The plural is "σχήματα"...
for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both whom the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed.
Overview
The term "Zachman Framework" has multiple meanings. It can refer to any of the frameworks proposed by John ZachmanJohn Zachman
John A. Zachman is an American business and IT consultant, early pioneer of enterprise architecture, Chief Executive Officer of Zachman International, and originator of the Zachman Framework.- Biography :...
:
- The initial framework, named A Framework for Information Systems Architecture, by John Zachman published in an 1987 article in the IBM Systems journal.
- The Zachman Framework for Enterprise Architecture, an update of the 1987 original in the 1990s extended and renamed .
- One of the later versions of the Zachman Framework, offered by Zachman International as industry standard.
In other sources the Zachman Framework is introduced as a framework, originated by and named after John Zachman, represented in numerous ways, see image. This framework is explained as, for example:
- a frameworkSoftware frameworkIn computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software...
to organize and analyze dataDataThe term data refers to qualitative or quantitative attributes of a variable or set of variables. Data are typically the results of measurements and can be the basis of graphs, images, or observations of a set of variables. Data are often viewed as the lowest level of abstraction from which...
, - a framework for enterprise architecture.
- a classification system, or classification scheme
- a matrix, often in a 6x6 matrix format
- a two-dimensional modelScientific modellingScientific modelling is the process of generating abstract, conceptual, graphical and/or mathematical models. Science offers a growing collection of methods, techniques and theory about all kinds of specialized scientific modelling...
or an analytic model. - a two-dimensional schema, used to organize the detailed representations of the enterprise.
Beside the frameworks developed by John Zachman numerous extensions and or applications have been developed, which are also sometimes called Zachman Frameworks.
The Zachman Framework summarizes a collection of perspective
Perspective (cognitive)
Perspective in theory of cognition is the choice of a context or a reference from which to sense, categorize, measure or codify experience, cohesively forming a coherent belief, typically for comparing with another...
s involved in enterprise architecture. These perspectives are represented in a two-dimensional matrix that defines along the rows the type of stakeholders and with the columns the aspects of the architecture. The framework does not define a methodology for an architecture. Rather, the matrix is a template that must be filled in by the goals/rules, processes, material, roles, locations, and events specifically required by the organization. Further modeling by mapping between columns in the framework identifies gaps in the documented state of the organization.
The framework is a simple and logical structure for classifying and organizing the descriptive representations
Representations
Representations is an interdisciplinary journal in the humanities published quarterly by the University of California Press. The journals was established in 1983 and is the founding publication of the New Historicism movement of the 1980s. It covers topics including literary, historical, and...
of an enterprise. It is significant to both the management
Management
Management in all business and organizational activities is the act of getting people together to accomplish desired goals and objectives using available resources efficiently and effectively...
of the enterprise, and the actors involved in the development of enterprise systems. While there is not order of priority for the columns of the Framework, the top-down order of the rows is significant to the alignment of business concepts and the actual physical enterprise. The level of detail in the Framework is a function of each cell (and not the rows). When done by IT the lower level of focus is on information technology
Information technology
Information technology is the acquisition, processing, storage and dissemination of vocal, pictorial, textual and numerical information by a microelectronics-based combination of computing and telecommunications...
, however it can apply equally to physical material (ball valves, piping, transformers, fuse boxes for example) and the associated physical processes, roles, locations etc. related to those items.
History
In the 1980s John ZachmanJohn Zachman
John A. Zachman is an American business and IT consultant, early pioneer of enterprise architecture, Chief Executive Officer of Zachman International, and originator of the Zachman Framework.- Biography :...
had been involved at IBM in the development of Business System Planning
Business System Planning
Business System Planning is a method for analyzing, defining and designing an information architecture of organizations. It was first issued by IBM in 1981, though the initial work on BSP began in the early 1970s. At first, it was for IBM internal use only. Later it was made available to customers...
(BSP), a method for analyzing, defining and designing an information architecture
Information Architecture
Information architecture is the art of expressing a model or concept of information used in activities that require explicit details of complex systems. Among these activities are library systems, Content Management Systems, web development, user interactions, database development, programming,...
of organizations. In 1982 Zachman had already concluded that these analyses could reach far beyond automating systems design
Systems design
Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. One could see it as the application of systems theory to product development...
and managing data into the realms of strategic business planning and management science in general. It may be employed in the (in that time considered more esoteric) areas of enterprise architecture, data-driven systems design, data classification criteria, and more.
Information Systems Architecture Framework
In the 1987 article "A Framework for Information Systems Architecture" Zachman noted that the term "architecture" was used loosely by information systems professionals, and meant different things to planners, designers, programmers, communication specialists, and others. In searching for an objective, independent basis upon which to develop a framework for information systems architecture, Zachman looked at the field of classical architectureArchitecture
Architecture is both the process and product of planning, designing and construction. Architectural works, in the material form of buildings, are often perceived as cultural and political symbols and as works of art...
, and a variety of complex engineering projects in industry. He saw a similar approach and concluded that architectures exist on many levels and involves at least three perspectives: raw material or data
Data
The term data refers to qualitative or quantitative attributes of a variable or set of variables. Data are typically the results of measurements and can be the basis of graphs, images, or observations of a set of variables. Data are often viewed as the lowest level of abstraction from which...
, function of processes, and location or networks.
The Information Systems Architecture is designed to be a classification schema for organizing architecture models. It provides a synoptic view of the models needed for enterprise architecture. Information Systems Architecture does not define in detail what the models should contain, it does not enforce the modeling language used for each model, and it does not propose a method for creating these models.
Extension and formalization
In the 1992 article "Extending and Formalizing the Framework for Information Systems Architecture" John F. SowaJohn F. Sowa
John Florian Sowa is the computer scientist who invented conceptual graphs, a graphic notation for logic and natural language, based on the structures in semantic networks and on the existential graphs of Charles S. Peirce. He is currently developing high-level "ontologies" for artificial...
and John Zachman present the framework and its recent extensions and show how it can be formalized in the notation of conceptual graphs. Also in 1992:
Later during the 1990s
- Methodologists like Clive FinkelsteinClive FinkelsteinClive Finkelstein lives in Australia and is the "Father" of Information Engineering , having developed its concepts from 1976 - 1980 based on original work carried out by him to bridge from strategic business planning to information systems...
refocused on the top two framework rows which he labeled Enterprise EngineeringEnterprise engineeringEnterprise engineering is a subdiscipline of systems engineering, which applies the knowledge and methods of systems engineering to the design of businesses. The discipline examines each aspect of the enterprise, including business processes, information flows, and organizational structure...
and has one of the most successful methods for converging the business needs with information engineering implementation, and determining a logical build sequence of the pieces.
Framework for enterprise architecture
In the 1997 paper "Concepts of the Framework for Enterprise Architecture" Zachman explained that the framework should be referred to as a "Framework for Enterprise Architecture", and should have from the beginning. In the early 1980s however, according to Zachman, there was "little interest in the idea of Enterprise Reengineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community".In 2008 Zachman Enterprise introduced the Zachman Framework: The Official Concise Definition as a new Zachman Framework standard.
Extended and modified frameworks
Since the 1990s several extended frameworks have been proposed, such as:- Matthew & McGee (1990) extended the three initial perspectives "what", "how" and "where", to event (the "when"), reason (the "why") and organization (the "who").
- Evernden (1996) presented an alternative Information FrameWorkInformation FrameworkThe Information FrameWork is a Enterprise Architecture framework, originally conceived by Roger Evernden in 1996. The Information FrameWork is a family of data, process and object models to help financial institutions transform cross-enterprise architectures...
. - The Integrated Architecture FrameworkIntegrated Architecture FrameworkIntegrated Architecture Framework is an enterprise architecture framework that covers business, information, information system and technology infrastructure....
developed by CapgeminiCapgeminiCapgemini is a French global IT services company, one of the world's largest management consulting, outsourcing and professional services companies with a staff of 114,274 operating in 40 countries. It is headquartered in Paris and was founded in 1967 by Serge Kampf, the current chairman, in...
since 1996. - Vladan Jovanovic et all (2006) presents a Zachman Cube, an extended of the Zachman Framework into a multidimensional Zachman’s Cube.
Concept
The basic idea behind the Zachman Framework is that the same complex thing or item can be described for different purposes in different ways using different types of descriptions (e.g., textual, graphical). The Zachman Framework provides the thirty-six necessary categories for completely describing anything; especially complex things like manufactured goods (e.g., appliances), constructed structures (e.g., buildings), and enterprises (e.g., the organization and all of its goals, people, and technologies). The framework provides six different transformations of an abstract idea (not increasing in detail, but transforming) from six different perspectives.It allows different people to look at the same thing from different perspectives. This creates a holistic view of the environment, an important capability illustrated in the figure.
Views of Rows
Each row represents a total view of the solution from a particular perspective. An upper row or perspective does not necessarily have a more comprehensive understanding of the whole than a lower perspective. Each row represents a distinct, unique perspective; however, the deliverables from each perspective must provide sufficient detail to define the solution at the level of perspective and must translate to the next lower row explicitly.Each perspective must take into account the requirements of the other perspectives and the restraint those perspectives impose. The constraints of each perspective are additive. For example, the constraints of higher rows affect the rows below. The constraints of lower rows can, but do not necessarily affect the higher rows. Understanding the requirements and constraints necessitates communication of knowledge and understanding from perspective to perspective. The Framework points the vertical direction for that communication between perspectives.
- Planner's View (Scope) - The first architectural sketch is a "bubble chartBubble chartA bubble chart is a type of chart where each plotted entity is defined in terms of three distinct numeric parameters. Bubble charts can facilitate the understanding of the social, economical, medical, and other scientific relationships.- Overview :...
" or Venn diagramVenn diagramVenn diagrams or set diagrams are diagrams that show all possible logical relations between a finite collection of sets . Venn diagrams were conceived around 1880 by John Venn...
, which depicts in gross terms the size, shape, partial relationships, and basic purpose of the final structure. It corresponds to an executive summary for a planner or investor who wants an overview or estimate of the scope of the system, what it would cost, and how it would relate to the general environment in which it will operate. - Owner's View (Enterprise or Business ModelBusiness modelA business model describes the rationale of how an organization creates, delivers, and captures value...
) - Next are the architect's drawings that depict the final building from the perspective of the owner, who will have to live with it in the daily routines of business. They correspond to the enterprise (business) models, which constitute the designs of the business and show the business entities and processes and how they relate. - Designer's View (Information Systems Model) - The architect's plans are the translation of the drawings into detail requirements representations from the designer's perspective. They correspond to the system model designed by a systems analyst who must determine the data elements, logical process flows, and functions that represent business entities and processes.
- Builder's View (Technology Model) - The contractor must redraw the architect's plans to represent the builder's perspective, with sufficient detail to understand the constraints of tools, technology, and materials. The builder's plans correspond to the technology models, which must adapt the information systems model to the details of the programming languages, input/output (I/O) devices, or other required supporting technology.
- Subcontractor View (Detailed Specifications) - Subcontractors work from shop plans that specify the details of parts or subsections. These correspond to the detailed specifications that are given to programmers who code individual modules without being concerned with the overall context or structure of the system. Alternatively, they could represent the detailed requirements for various commercial-off-the-shelf (COTS)Commercial off-the-shelfIn the United States, Commercially available Off-The-Shelf is a Federal Acquisition Regulation term defining a nondevelopmental item of supply that is both commercial and sold in substantial quantities in the commercial marketplace, and that can be procured or utilized under government contract...
, government off-the-shelf (GOTS)Government off-the-shelfGovernment off-the-shelf is a term for software and hardware Government products that are ready-to-use. They were created and are owned by the Government. Typically GOTS are developed by the technical staff of the government agency for which it is created. It is sometimes developed by an...
, or components of modular systems software being procured and implemented rather than built. - Actual System View or The Functioning Enterprise
Focus of Columns
In summary, each perspective focuses attention on the same fundamental questions, then answers those questions from that viewpoint, creating different descriptive representations (i.e., models), which translate from higher to lower perspectives. The basic model for the focus (or product abstraction) remains constant. The basic model of each column is uniquely defined, yet related across and down the matrix. In addition, the six categories of enterprise architecture components, and the underlying interrogatives that they answer, form the columns of the Zachman Framework and these are:- The data description — What
- The function description — How
- The Network description — Where
- The people description — Who
- The time description — When
- The motivation description — Why
In Zachman’s opinion, the single factor that makes his framework unique is that each element on either axis of the matrix is explicitly distinguishable from all the other elements on that axis. The representations in each cell of the matrix are not merely successive levels of increasing detail, but actually are different representations — different in context, meaning, motivation, and use. Because each of the elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell.
Models of Cells
The kinds of models or architectural descriptive representations are made explicit at the intersections of the rows and columns. An intersection is referred to as a cell. Because a cell is created by the intersection of a perspective and a focus, each is distinctive and unique. Since each cell is distinctive and unique, the contents of the cell are normalized and explicit per the perspective’s focus.The cell descriptions in the table itself uses general language for a specific set of targets. Below the focus of each cell in this particular Zachman Framework is explained
Explanation
An explanation is a set of statements constructed to describe a set of facts which clarifies the causes, context, and consequencesof those facts....
:
Contextual
- (Why) Goal List – primary high level organization goals
- (How) Process List – list of all known processes
- (What) Material List – list of all known organizational entities
- (Who) Organizational Unit & Role List – list of all organization units, sub-units, and identified roles
- (Where) Geographical Locations List – locations important to organization; can be large and small
- (When) Event List – list of triggers and cycles important to organization
Conceptual
- (Why) Goal Relationship Model – identifies hierarchy of goals that support primary goals
- (How) Process Model – provides process descriptions, input processes, output processes
- (What) Entity Relationship ModelEntity-relationship modelIn software engineering, an entity-relationship model is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements...
– identifies and describes the organizational materials and their relationships - (Who) Organizational Unit & Role Relationship Model – identifies enterprise roles and units and the relationships between them
- (Where) Locations Model – identifies enterprise locations and the relationships between them
- (When) Event Model – identifies and describes events and cycles related by time
Logical
- (Why) Rules Diagram – identifies and describes rules that apply constraints to processes and entities without regard to physical or technical implementation
- (How) Process Diagram – identifies and describes process transitions expressed as verb-noun phrases without regard to physical or technical implementation
- (What) Data Model DiagramData modelA data model in software engineering is an abstract model, that documents and organizes the business data for communication between team members and is used as a plan for developing applications, specifically how data is stored and accessed....
– identifies and describes entities and their relationships without regard to physical or technical implementation - (Who) Role Relationship Diagram – identifies and describes roles and their relations to other roles by types of deliverables without regard to physical or technical implementation
- (Where) Locations Diagram – identifies and describes locations used to access, manipulate, and transfer entities and processes without regard to physical or technical implementation
- (When) Event Diagram – identifies and describes events related to each other in sequence, cycles occur within and between events, without regard to physical or technical implementation
Physical
- (Why) Rules Specification – expressed in a formal language; consists of rule name and structured logic to specify and test rule state
- (How) Process Function Specification – expressed in a technology specific language, hierarchical process elements are related by process calls
- (What) Data Entity Specification – expressed in a technology specific format; each entity is defined by name, description, and attributes; shows relationships
- (Who) Role Specification – expresses roles performing work and workflow components at the work product detailed specification level
- (Where) Location Specification – expresses the physical infrastructure components and their connections
- (When) Event Specification – expresses transformations of event states of interest to the enterprise
Detailed Representation
Eventually the cells with the detailed representation give Rules detail for (Why); Process detail for (How); Data detail for (What); Role detail for (Who); Location detail for (Where); and Event detail for (When).
There is a sixth row in the current Zachman framework, but it is not used for enterprise architecture — while the enterprise is described by rows one to six, enterprise architecture uses only rows one to five, thus only five rows are shown here.
Since the product development (i.e., architectural artifact) in each cell or the problem solution embodied by the cell is the answer to a question from a perspective, typically, the models or descriptions are higher-level depictions or the surface answers of the cell. The refined models or designs supporting that answer are the detailed descriptions within the cell. Decomposition (i.e., drill down to greater levels of detail) takes place within each cell. If a cell is not made explicit (defined), it is implicit (undefined). If it is implicit, the risk of making assumptions about these cells exists. If the assumptions are valid, then time and money are saved. If, however, the assumptions are invalid, it is likely to increase costs and exceed the schedule for implementation.
Framework set of rules
The framework comes with a set of rules:- Rule 1 The columns have no order : The columns are interchangeable but cannot be reduced or created
- Rule 2 Each column has a simple generic model : Every column can have its own meta-model
- Rule 3 The basic model of each column must be unique : The basic model of each column, the relationship objects and the structure of it is unique. Each relationship object is interdependent but the representation objective is unique.
- Rule 4 Each row describes a distinct, unique perspective : Each row describes the view of a particular business group and is unique to it. All rows are usually present in most hierarchical organizations.
- Rule 5 Each cell is unique : The combination of 2,3 & 4 must produce unique cells where each cell represents a particular case. Example: A2 represents business outputs as they represent what are to be eventually constructed.
- Rule 6 The composite or integration of all cell models in one row constitutes a complete model from the perspective of that row : For the same reason as for not adding rows and columns, changing the names may change the fundamental logical structure of the Framework.
- Rule 7 The logic is recursive : The logic is relational between two instances of the same entity.
The framework is generic in that it can be used to classify the descriptive representations of any physical object as well as conceptual objects such as enterprises. It is also recursive in that it can be used to analyze the architectural composition of itself. Although the framework will carry the relation from one column to the other, it is still a fundamentally structural representation of the enterprise and not a flow representation.
Flexibility in level of detail
One of the strengths of the Zachman Framework is that it explicitly shows a comprehensive set of viewsView model
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation...
that can be addressed by enterprise architecture. Some feel that following this model completely can lead to too much emphasis on documentation, as artifacts would be needed for every one of the thirty cells in the framework.
John Zachman clearly states in his documentation, presentations, and seminars that, as framework, there is flexibility in what depth and breadth of detail is required for each cell of the matrix based upon the importance to a given organization. An automaker, whose business goals may necessitate an inventory and process-driven focus, could find it beneficial to focus their documentation efforts on What and How columns. Whereas a travel agent company, whose business is more concerned with people and event-timing, could find it beneficial to focus their documentation efforts on Who and When columns. However, there is no escaping the Why column's importance as it provides the business drivers for all the other columns.
Applications and influences
Since the 1990s the Zachman Framework has been widely used as a means of providing structure for Information EngineeringInformation engineering
Information engineering or information engineering methodology in software engineering is an approach to designing and developing information systems.-Overview:...
-style enterprise modeling. The Zachman Framework can be applied both in commercial companies and in government agencies. Within a government organization the framework can be applied to an entire agency at an abstract level, or it can be applied to various departments, offices, programs, subunits and even to basic operational entities.
Customization
Zachman Framework is applied in customized frameworks such as the TEAF, built around the similar frameworks, the TEAF matrix.Other sources:
- The TEAF matrix is called a customization sample, see here, p. 22
Standards based on the Zachman Framework
Zachman Framework is also used as a framework to describe standards, for example standards for healthcare and healthcare information system. Each cell of the framework contains such a series of standards for healthcare and healthcare information system.Mapping other frameworks
Another application of the Zachman Framework is as reference model for other enterprise architectures, see for example these four:Other examples:
- Analysis of the Rational Unified ProcessRational Unified ProcessThe Rational Unified Process is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003...
as a Process, - How the Model-driven architectureModel-driven architectureModel-driven architecture is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of...
(MDA) models used in software development map to the Zachman Framework. - Mapping the IEC 62264 models onto the Zachman framework for analysing products information traceability.
- Mapping the TOGAFTOGAFThe Open Group Architecture Framework is a framework for enterprise architecture which provides a comprehensive approach for designing, planning, implementation, and governance of an enterprise information architecture...
Architecture Development Method (e.g. the methodology) to the Zachman Framework.
Base for other enterprise architecture frameworks
Less obvious are the ways the original Zachman framework has stimulated the development of other enterprise architecture frameworks, such as in the NIST Enterprise Architecture ModelNIST Enterprise Architecture Model
NIST Enterprise Architecture Model is a reference model for Enterprise Architecture, that illustrates the interrelationship of enterprise business, information, and technology environments....
, the C4ISR
C4ISR
C4ISR may refer to:* the C4ISR concept of Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance, the U.S. term for C4ISTAR* C4ISR Journal, a journal published by the Defense News Media Group...
AE, the DOE AE, and the DoDAF:
- The Federal Enterprise Architecture Framework (FEAF) is based on the Zachman Framework but only addresses the first three columns of Zachman, using slightly different names, and focuses in the top of the three rows. (see here)
Example: One-VA Enterprise Architecture
The Zachman Framework methodology has for example been used by the United States Department of Veterans AffairsUnited States Department of Veterans Affairs
The United States Department of Veterans Affairs is a government-run military veteran benefit system with Cabinet-level status. It is the United States government’s second largest department, after the United States Department of Defense...
(VA) to develop and maintain its One-VA Enterprise Architecture in 2001. This methodology required them to define all aspects of the VA enterprise from a business process, data, technical, location, personnel, and requirements perspective. The next step in implementing the Zachman methodology has been to define all functions related to each business process and identify associated data elements. Once identified, duplication of function and inconsistency in data definition can be identified. The hard job then followed to de-conflict the data definitions and resolve duplicative implementations of the same business function.
The Department of Veterans Affairs at the beginning of the 21st century planned to implement an enterprise architecture fully based on the Zachman Framework.
- The Zachman Framework was used as a reference model to initiate enterprise architecture planning in 2001.
- Somewhere in between the VA Zachman Framework Portal was constructed.
- This VA Zachman Framework Portal is still in use as a reference model for example in the determination of EA information collected from various business and project source documents.
- Now somewhere in the past this "A Tutorial on the Zachman Architecture Framework".
Eventually an enterprise architecture repository was created at the macro level by the Zachman framework and at a cell level by the meta-model outlined below.
This diagram has been incorporated within the VA-EA to provide a symbolic representation of the metamodel that VA used, to describe the One-VA Enterprise Architecture and to build an EA Repository without the use of Commercial EA Repository Software. The One-VA EA repository was developed using an object oriented database within the Caliber-RM Software Product. Caliber-RM is intended to be used as a software configuration management
Software configuration management
In software engineering, software configuration management is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines....
tool; not as an EA repository.
However this tool permitted defining entities and relationships and for defining properties upon both entities and relationships, which made it sufficient for building an EA repository, considering the technology that was available in early 2003. The personal motivation in selecting this tool was two-fold:
- none of the commercial repository tools that were available at that time provided a true Zachman Framework representation of models and relationships; and
- the available commercial tools were highly proprietary and made it difficult to incorporate best-of-breed tools and representations from other vendors or form open sources.
This diagram emphasizes several important interpretations of the Zachman Framework and its adaptation to information technology investment management
Investment management
Investment management is the professional management of various securities and assets in order to meet specified investment goals for the benefit of the investors...
.
- Progressing through the rows from top to bottom, one can trace-out the Systems Development Life CycleSystems Development Life CycleThe systems development life cycle , or software development life cycle in systems engineering, information systems and software engineering, is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems.In software engineering...
(SDLC) which is a de facto standard across the Information Industry; - The diagram emphasizes the importance of the often-neglected Zachman Row-Six (the Integrated, Operational Enterprise View). Representations in Mr. Zuech’s interpretation of Zachman row-six consist, largely, of measurable service improvements and cost savings/avoidance that result from the business process and technology innovations that were developed across rows two through five.
Row-six provides measured Return on Investment
Return on investment
Return on investment is one way of considering profits in relation to capital invested. Return on assets , return on net assets , return on capital and return on invested capital are similar measures with variations on how “investment” is defined.Marketing not only influences net profits but also...
for Individual Projects and, potentially, for the entire investment portfolio. Without row-six the Zachman Framework only identifies sunk-cost – the row-six ROI permits the framework to measure benefits and to be used in a continuous improvement process, capturing best practices and applying them back through row-two.
See also
- Data modelData modelA data model in software engineering is an abstract model, that documents and organizes the business data for communication between team members and is used as a plan for developing applications, specifically how data is stored and accessed....
- Enterprise Architecture framework
- Enterprise Architecture PlanningEnterprise Architecture PlanningEnterprise Architecture Planning in Enterprise Architecture is the planning process of defining architectures for the use of information in support of the business and the plan for implementing those architectures.- Overview :...
- FDIC Enterprise Architecture FrameworkFDIC Enterprise Architecture FrameworkFDIC Enterprise Architecture Framework is the Enterprise Architecture framework of the United States Federal Deposit Insurance Corporation...
- View modelView modelA view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation...
External links
- The Zachman Framework: The Official Concise Definition by John A. Zachman at Zachman International, 2009.
- The Zachman Framework Evolution: overview of the evolution of the Zachman Framework by John P. Zachman at Zachman International, April 2009.
- UML, RUP, and the Zachman Framework: Better together, by Vitalie Temnenco, IBM, 15 Nov 2006.