Zachman Framework

Definition of Zachman Framework

The Zachman Framework, developed by John Zachman, is an enterprise ontology and is a fundamental structure for Enterprise Architecture that 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 is 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.

The Origins and Purpose of the Zachman Enterprise Framework
The Zachman Enterprise Architecture 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 organizations 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 organization, 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 organization’s architecture. It is a proactive business tool, which can be used to model an organization’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 airplanes 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 Architecture Framework is represented and promoted by the ZIFA (Zachman Institute for Framework Advancement) organization. It is not a standard and there are similar enterprise architecture frameworks that have been derived from it, such as the Federal Enterprise Architecture Framework (FEA), The Open Group Architecture Framework (TOGAF), and the Department of Defense Architecture Framework (DoDAF).

Understanding the Zachman Framework™

• 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 are 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 a 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 do you want for producing composite models (Enterprise implementations) from your Enterprise Architecture (primitive models), that is, how constrained (little flexibility) or unconstrained (much flexibility) do 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.

source: Zachman.com

Structure of Zachman Framework
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 focus 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 that are descriptions of the enterprise from the specific viewpoint of a group of stakeholders. The stakeholders are generally grouped as planners, owners, designers (architects), implementers, sub-constructors, and 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 organization, from the perspective of different stakeholders. These are ordered in the 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
The Zachman framework defines some rules to alleviate the 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 of 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 Columns: Each name has a semantic meaning, changing names would, in effect, change the meaning of the row or column. In that case, the framework would not be a Zachman Framework anymore. The naming should be as follows,
  • For Generic Frameworks rows should be named Scope, Owner, Designer, Builder, Out-of-context, and Product. And Columns should be named What, How, Where, Who, When, and Why.
  • For Enterprise Specific Framework rows should be named Scope, Models of the Business, Systems Models, Technology Models, Detailed Representations, and Functioning Enterprise.
  • And columns should be named as Data, Function, Network, People, Time, and 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

• 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 and 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 that become Quixotic quests to build and maintain a complete set of models that 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 formalize 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 models 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 that winds up delivering little by way of identifiable value to any specific business area or endeavor. 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

The Zachman Framework for Enterprise Architecture (EA) is a schema to organize and analyze the components of an enterprise's architecture. It is considered a foundational structure for understanding the complex relationships within IT infrastructure and how it aligns with business goals. The framework, developed by John Zachman in the 1980s, is not a methodology for creating architecture but rather a taxonomy that helps organize architectural artifacts (designs, documents, models) logically.

• Enterprise Architecture (EA): A conceptual blueprint that defines the structure and operation of an organization. EA aims to determine how an organization can most effectively achieve its current and future objectives.
• Architecture Framework: A standardized methodology organizations use to create and describe the architecture of their systems. The Zachman Framework is one such example, providing a structured way of viewing and documenting the enterprise architecture.
• Ontology: In the context of the Zachman Framework, ontology refers to the comprehensive classification scheme for all the elements of an enterprise's architecture. It is used to provide a common vocabulary and a unified perspective.
• Business Process Modeling (BPM): The activity of representing processes of an enterprise to analyze and improve them. BPM fits into the Zachman Framework as a tool for detailing the business process layer.
• Data Modeling: Creating a data model for storing the data in a database. This activity is crucial in the Zachman Framework for defining how information is structured and managed across the enterprise.
• Application Architecture: The layer of the Zachman Framework that focuses on how applications are structured and interact to perform business processes and tasks. It includes the selection of application systems and their relationships with each other.
• Technology Infrastructure: The lowest layer of the Zachman Framework, focusing on the physical technologies and standards used by the organization. This includes hardware, networking equipment, and software environments.
• Stakeholder Perspective: Each row of the Zachman Framework represents a different perspective on the architecture, corresponding to different stakeholder roles, including executives, business managers, architects, engineers, and technicians.
• Modeling Languages: Tools used within the Zachman Framework to create the artifacts and models that populate each framework cell. Examples include Unified Modeling Language (UML) for application architecture and Entity Relationship Diagram (ERD) for Data Architecture.
• Governance and Compliance: Refers to the practices and operations within the Zachman Framework that ensure the enterprise architecture meets regulatory and policy requirements, aligns with strategic goals, and is effectively managed and updated over time.

The Zachman Framework provides a meticulous and structured approach to understanding and documenting an enterprise's architectural complexity. It allows for a detailed view of how information, technology, and business operations interrelate, guiding strategic decisions and technology investments.

Further Reading

• The Zachman Framework Evolution (Part 1)
• A Tutorial on the Zachman Framework for Enterprise Architecture
• Implementation of the enterprise architecture through the Zachman Framework
• https://www.researchgate.net/publication/221990209_An_analysis_of_the_Zachman_framework_for_enterprise_architecture_from_the_GERAM_perspective An analysis of the Zachman framework for enterprise architecture from the GERAM perspective ]
• Increasing Effectiveness Of The Zachman Framework Using The Balanced Scorecard
• Two IT gurus face off on value of enterprise architecture frameworks
• Enterprise architecture tools: Fake and real