Zachman Framework

The Zachman Framework is an enterprise ontology and is a fundamental structure for Enterprise Architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: Identification, Definition, Representation, Specification, Configuration and Instantiation.[1]

The Origins and Purpose of the Zachman Enterprise Framework[2]
The Zachman enterprise framework was invented by John Zachman in 1980 for IBM, and is now in the public domain. The framework borrows from business design principles in architecture and manufacturing and provides a way of viewing an enterprise and its information systems from different perspectives, and showing how the components of the enterprise are related. In today’s complex business environments, many large organisations have great difficulty responding to change. Part of this difficulty is due to a lack of internal understanding of the complex structure and components in different areas of the organisation, where legacy information about the business is locked away in the minds of specific employees or business units, without being made explicit. The Zachman framework provides a means of classifying an organisation’s architecture. It is a proactive business tool, which can be used to model an organisation’s existing functions, elements and processes - and help manage business change. The framework draws on Zachman’s experience of how change is managed in complex products such as aeroplanes and buildings. Although the framework can be used for information systems architecture (ISA) and is widely adopted by systems analysts and database designers, John Zachman has stressed that it extends to the entire enterprise architecture, and is not restricted to simply information architecture. The Zachman enterprise framework is represented and promoted by the ZIFA (Zachman Institute for Framework Advancement) organisation. It is not a standard and there are similar enterprise frameworks that have been derived from it, such as the Federal Enterprise Architecture Framework (FEAF), The Open Group Architecture Framework (TOGAF), and the Department of Defense Architecture Framework (DoDAF).

Understanding the Zachman Framework™[3]

  • The Zachman Framework™ is an ontology - a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, a department, a value chain, a “sliver,” a solution, a project, an airplane, a building, a product, a profession or whatever or whatever).
  • The Zachman Framework™ IS NOT a methodology for creating the implementation (an instantiation) of the object. The Framework IS the ontology for describing the Enterprise. The Framework (ontology) is a STRUCTURE whereas a methodology is a PROCESS. A Structure is NOT a Process. A Structure establishes definition whereas a Process provides Transformation. Processes based on ontological structure will be predictable and produce repeatable results (for example, Chemistry, based on the Periodic Table). Conversely, Processes without ontological structures are ad hoc, fixed and dependent on practitioner skills (for example, Alchemy, based on trial and error).
  • The Zachman Framework™ is a metamodel and unlike a methodology, does not imply anything about:
    • Whether you do Architecture or whether you simply build implementations that is, whether you build Primitive Models, the ontological, single-variable intersections between the Interrogatives and the Transformations or whether you simply build ad hoc, multi-variable, composite models made up of components of several Primitive Models.
    • How you do Architecture: top-down, bottom-up, left to right, right to left, where to start, etc., etc.
    • The long-term/short-term trade-off relative to instantiating the expression of the components of the object that is, what is formalized in the short-term for implementation purposes versus what is engineered for long-term reuse.
    • How much flexibility you want for producing composite models (Enterprise implementations) from your Enterprise Architecture (primitive models), that is, how constrained (little flexibility) or unconstrained (much flexibility) you make the horizontal, integrative relationships between the Cell components across the Rows and the vertical, transformational relationships of the Cell components down the Columns.
    • Although these are significant, identifiable, methodological choices, they are not prescriptions of the Framework structure.
  • The Zachman Framework™ is the basis for Architecture - We know what architecture is for industrial products (buildings, airplanes, locomotives, computers, etc., etc.) because in the Industrial Age, it was the industrial products that were increasing in complexity and the industrial products that were changing. If we had not gotten extremely sophisticated relative to architecture for industrial products, we would not likely be able to create and change complex industrial products and we would likely still be in the Industrial Age learning about Product Architecture. Now that we are in the Information Age, it is the Enterprise that is increasing in complexity and the Enterprise that is changing.

The Zachman Framework for Enterprise Architecture

Structure of Zachman Framework[4]
Zachman Framework is a two dimensional classification scheme for descriptive representations of an Enterprise that is structured as a matrix containing 36 cells, each of them focusing on one dimension or perspective of the enterprise. Rows are often presented as different viewpoints involved in the systems development process, while columns represent different perspectives of the stakeholders involved in the organization. The rows of Zachman Framework focuses on describing the enterprise from six viewpoint perspectives of the stakeholders. These six perspectives are based on English language interrogatives 'what', 'where', 'who', 'when', 'why', and 'how' (known as W5H). The columns of the framework consist of a set of artifacts which are description of the enterprise from specific viewpoint of a group of stakeholders. The stakeholders are generally grouped as planners, owners, designers (architects), implementers, sub-constructors, users, or sometimes represented as viewpoints: scope context, business concepts, system logic, technology, physics, component assembles and operations classes. The framework enables complex subjects to be distilled into systematic categories in the column headers, using these six basic questions (known as 5WH). The answers to these questions will differ, depending on the perspective or audience (represented in the rows). Each view is a description from a particular perspective and has a representation (a model or functioning system), as indicated in the Table above. Here is a brief description of each view and model/functioning system:

  • Columns of Zachman Framework: The columns represent the interrogatives or questions that are asked of the enterprise. These are:
    • What (data) - what is the business data, information or objects?
    • How (function) - how does the business work, i.e., what are the business' processes?
    • Where (network) - where are the businesses operations?
    • Who (people) - who are the people that run the business, what are the business units and their hierarchy?
    • When (time) - when are the business processes performed, i.e., what are the business schedules and workflows?
    • Why (motivation) - why is the solution the one chosen? How was that derived from? What motivates the performance of certain activities?
  • Rows of Zachman Framework: Each row represents a distinct view of the organisation, from the perspective of different stakeholders. These are ordered in a desired priority sequence. A row is allocated to each of the following stakeholders:
    • Planner's View (Scope Contexts) - This view describes the business purpose and strategy, which defines the playing field for the other views. It serves as the context within which the other views will be derived and managed.
    • Owner's View (Business Concepts) - This is a description of the organization within which the information system must function. Analyzing this view reveals which parts of the enterprise can be automated.
    • Designer's View (System Logic) - This view outlines how the system will satisfy the organization's information needs. The representation is free from solution specific aspects or production specific constraints.
    • Implementer's View (Technology Physics) - This is a representation of how the system will be implemented. It makes specific solutions and technologies apparent and addresses production constraints.
    • Sub-Constructor's View (Component Assembles) - These representations illustrate the implementation-specific details of certain system elements: parts that need further clarification before production can begin. This view is less architecturally significant than the others because it is more concerned with a part of the system than with the whole.
    • User's View (Operations Classes) - This is a view of the functioning system in its operational environment.

Rules of Zachman Framework[5]
The Zachman framework defines some rules to alleviate effectiveness of the framework. Following is the list of rules with a brief description.

  • Do Not Add Rows or Columns to the Framework: Who, What, When, Where, Why and How are the six primitive interrogatives. According to linguistics, answers to these questions could provide a comprehensive understanding about a subject or an object. Hence all of them are required.
  • Each Column Has a Simple Generic Model: Each column describes a single and independent aspect of the Enterprise. Therefore the basic model for any of the columns is simple and generic.
  • Each Cell Model Specializes Its Column’s Generic Model" As each of the columns has a simple and generic model, each cell tends to provide information or perspective that is specific to the row. Therefore each cell model specifies the generic model for each column.
  • No Meta Concept Can Be Classified Into More than One Cell: In the Zachman framework, each row is unique and so is each column. Therefore each cell is unique. Each meta-concept will be specific to the cell; therefore it is logical that none of the meta-concepts can be classified into more than one cell.
  • Do not Create Diagonal Relationships Between Cells: The Framework is described in plain English. Each perspective defines its own semantics for the aspects or columns. Therefore creating diagonal relationships could lead to semantically incomplete communication. This could lead to big disasters and hence there must not be any diagonal relationships.
  • Do Not Change the Names of the Rows or Column: Each name has a semantic meaning, changing names would, in effect, change the meaning for the row or column. In that case, the framework would not be a Zachman Framework anymore. Naming should be as follows,
    • For Generic Frameworks rows should be named as Scope, Owner, Designer, Builder, Out-of-context, Product. And Columns should be named as What, How, Where, Who, When, Why.
    • For Enterprise Specific Framework rows should be named as Scope, Models of the Business, Systems Models, Technology Models, Detailed Representations, Functioning Enterprise.
    • And columns should be named as Data, Function, Network, People, Time, Motivation.
  • The Logic is Generic and Recursive

The Framework itself is generic enough to classify descriptive representation of anything and therefore it is enough to analyze anything relative to its architectural composition.

Critical Evaluation of the Zachman Framework[6]

  • Support for Enterprise Asset Reuse

One of the main strengths of the Zachman Framework is that it operates above and across the individual project level, and thus provides a framework within which to accumulate reusable assets such as patterns and components.

  • Bias Towards Data-Driven and Process-Decomposition Methods

The Zachman Framework positions itself as being neutral across methods, processes, modeling techniques and tools, and therefore as being able to offer a set of benchmarks against which an enterprise can evaluate these approaches and tools prior to their adoption. It is, however, questionable as to whether true neutrality of this kind can ever be achieved and, in fact, the Zachman Framework is based on a set of assumptions and terminology which implicitly align it with data-driven and process-decomposition methods and processes, rather than use-case-driven, object-oriented or component-based approaches. While this is mainly a question of presentation, it may act to bias users of the framework to be predisposed against recognition of the ability of [^UML-Unified-Modeling-Language|UML] and [^Rational-Unified-Process-RUP|RUP] based tools and processes to effectively support the models outlined in the Zachman Framework.

  • Tendency towards heavy-weight, ‘completist’, and detailed ‘top-down’ enterprise modeling

It is easy to fall into the trap of being seduced by the neatness and symmetry of the Zachman Framework, and the danger is that it can result in undertakings which become Quixotic quests to build and maintain a complete set of models which model every conceivable aspect of the enterprise at every conceivable level of abstraction, with no regard for how much these modeling enterprises cost nor what value they are delivering and to whom. For example, the ‘Who, Where, Why, What, When and Why’ questions feel like a nice, neat and complete set of interrogatives, such that once you’ve used the first three or four you feel obliged to go on and complete the set despite the fact that the last two or three uses are increasingly artificial and serve more to distract than illuminate (witness the subheadings within the first section of this article). Zachman himself implies that the What, How and Where are in general more important than the Who, When and Why, which are there more for completeness, but the Framework does not formalise this distinction between those elements that are genuinely valuable, and those that are largely there for completeness. Since the Zachman Framework itself contains no process, it is devoid of advice in terms of what models should be built, when and why. The danger, therefore, is that adopters of the framework implicitly assume that the ultimate aim must be to build and maintain all levels of all types of model across the whole enterprise, and further conclude that a program should therefore be set in motion with the sole aim of doing just this. It need not be pointed out that a program such as this can easily become an endless, self-serving exercise which winds up delivering little by way of identifiable value to any specific business area or endeavour. Clearly, depending upon the domain and purpose of the models, particular abstractions may have more, less or no value, and again the Zachman Framework, in my experience, can act to discourage such a selective and deliverable-focused approach to modeling.

  • Divorced process, data and other views of the enterprise and its systems

In slicing up the set of models that can be built of the enterprise and its systems into a number of named columns, the Zachman Framework tends to encourage a high level divorce between these views of the enterprise, along the lines of those encouraged by data-driven and process-decomposition approaches, where models are progressed by drilling down these columns in the framework independently, and producing models which are highly stove-piped views of the enterprise. The value of use-case driven, object-oriented and component-based models is that they show at any particular level of abstraction how function and form are interlinked and how they work together to achieve the goals of the system. The Zachman Framework, in depicting the various model elements as being isolated within cells, has no way of depicting the links which must exist to integrate these model elements into useful views of the enterprise.

See Also

Enterprise Architecture
Enterprise Architecture Framework
Business Systems Planning (BSP) Enterprise Architecture Management (EAM)
Enterprise Architecture Value Framework (EAVF)
Federal Enterprise Architecture Framework (FEA)
Department of Defense Architecture Framework (DoDAF)
The Open Group Architecture Framework (TOGAF)
Adaptive Enterprise Framework (AEF)
Technical Architecture Framework for Information Management (TAFIM)


  1. Definition - What is the Zachman Framework? Wikipedia
  2. The Origins and Purpose of the Zachman Enterprise Framework Technical Communicatores
  3. Understanding the Zachman Framework™
  4. Structure of Zachman Framework Visual Paradigm
  5. Rules of Zachman Framework L. Ertaul, V. Rathod
  6. Critical Evaluation of the Zachman Framework Rational

Further Reading

  • The Zachman Framework Evolution (Part 1) [^ John P Zachman]
  • A Tutorial on the Zachman Framework for Enterprise Architecture
  • Implementation of the enterprise architecture through the Zachman Framework Tiko Iyamu
  • An analysis of the Zachman framework for enterprise architecture from the GERAM perspective Ovidiu Noran
  • Increasing Effectiveness Of The Zachman Framework Using The Balanced Scorecard Anagha Gokhale
  • Two IT gurus face off on value of enterprise architecture frameworks Techtarget
  • Enterprise architecture tools: Fake and real Svyatoslav Kotusev