The Zachman Framework is a structured tool used in enterprise architecture to organize and understand complex business systems. It acts as an ontology, providing a clear and formal way to describe an enterprise through a two-dimensional grid. This grid combines two key perspectives: the basic questions of What, How, When, Who, Where, and Why, and the process of turning abstract ideas into concrete realities, known as reification. These reification stages include identification, definition, representation, specification, configuration, and instantiation. While influential in shaping enterprise architecture, the framework is often considered theoretical, with limited direct adoption in fast-paced industries like technology, where agile methods are preferred.
Unlike a methodology, the Zachman Framework does not prescribe specific steps or processes for gathering or using information. Instead, it serves as a schema to categorize architectural artifacts—such as design documents, specifications, and models—based on who they are for (e.g., business owners or builders) and what they address (e.g., data or functionality).A Comparison of the Top Four Enterprise Architecture Methodologies, Roger Sessions, Microsoft Developer Network Architecture Center,
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, with version 3.0 being the most current.
Overview The Zachman Framework has evolved in its thirty-year history to include: The initial framework, named A Framework for Information Systems Architecture, by John Zachman published in a 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.The Open Group (1999–2006). "ADM and the Zachman Framework" in: TOGAF 8.1.1 Online. Accessed 31 July 2024. One of the later versions of the Zachman Framework, offered by Zachman International as industry standard.
In other sources, this framework is explained as, for example: a framework to organize and analyze data, a framework for enterprise architecture.Pete Sawyer, Barbara Paech, Patrick Heymans (2007). Requirements Engineering: Foundation for Software Quality. page 191. a classification system, or classification scheme.Kathleen B. Hass (2007). The Business Analyst as Strategist: Translating Business Strategies Into Valuable Solutions. page 58. a matrix, often in a 6x6 matrix format a two-dimensional modelHarold F. Tipton, Micki Krause (2008). Information Security Management Handbook, Sixth Edition, Volume 2. page 263. or an analytic model. a two-dimensional schema, used to organize the detailed representations of the enterprise.O'Rourke, Fishman, Selkow (2003). Enterprise Architecture Using the Zachman Framework. page 9. In addition to John Zachman's original frameworks, various extensions and applications have emerged, often referred to as Zachman Frameworks, though they typically serve as graphical overlays atop the core framework.
The Zachman Framework organizes key perspectives of enterprise architecture into a two-dimensional matrix. The rows represent different stakeholder types, while the columns outline various architectural aspects. It does not provide a specific methodology for architecture development. Instead, the matrix serves as a template to be populated with the organization's unique goals, rules, processes, materials, roles, locations, and events. Mapping relationships between columns helps identify gaps in the organization's documented state.James McGovern et al. (2003). A Practical Guide to Enterprise Architecture. p. 127-129.
The framework is a 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.Marc Lankhorst et al. (2005). Enterprise Architecture at Work. p. 24. While there is no 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.
History In the 1980s, John Zachman contributed to IBM's development of Business System Planning (BSP), a method for analyzing, defining, and designing organizational information architectures. By 1982, Zachman"Business Systems Planning and Business Information Control Study: A comparisment. In: IBM Systems Journal, vol 21, no 3, 1982. p. 31-53. recognized that such analyses extended beyond automating systems design and data management, impacting strategic business planning and management science broadly. The approach could also apply to emerging fields like enterprise architecture, data-driven system design, and data classification methodologies.
"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 architecture, and a variety of complex engineering projects in industry. He saw a similar approach and concluded that architectures exist on many levels and involve at least three perspectives: raw material or data, function or processes, and location or networks.
Zachman's 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.Alain Wegmann et al. (2008). "Augmenting the Zachman Enterprise Architecture Framework with a Systemic Conceptualization". Presented at the 12th IEEE International EDOC Conference (EDOC 2008), München, Germany, September 15–19, 2008.
Extension and formalization In the 1992 article "Extending and Formalizing the Framework for Information Systems Architecture" John F. Sowa 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 Finkelstein refocused on the top two framework rows which he labeled Enterprise Engineering and has one of the most successful methods for converging the business needs with information technology 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 said that the framework should be referred to as a "Framework for Enterprise Architecture", and should have been 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)R. W. Matthews. &. W. C. McGee (1990). "Data Modeling for Software Development". in: IBM Systems Journal 29(2). pp. 228–234 extended the three initial perspectives "what", "how" and "where", to event (the "when"), reason (the "why") and organization (the "who"). Schoch & Laplante (1995) published in the IBM Systems Journal (vol. 34, no.1, January 1995, pp.22-38) "A Framework for Real-Time Systems Architecture," an extension of the original Zachman Framework that applies to real-time systems. Evernden (1996) presented an alternative Information FrameWork. The Integrated Architecture Framework developed by Capgemini since 1996.Jaap Schekkerman (2003). How to Survive in the Jungle of Enterprise Architecture Frameworks. page 139-144. Vladan Jovanovic et al. (2006) presents a Zachman Cube, an extended of the Zachman Framework into a multidimensional Zachman's Cube.Vladan Jovanovic, Stevan Mrdalj & Adrian Gardiner (2006). A Zachman Cube . In: Issues in Information Systems. Vol VII, No. 2, 2006 p. 257-262.
Topics
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 (i.e., 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.VA Enterprise Architecture Innovation Team (2001). Enterprise Architecture: Strategy, Governance, & Implementation report Department of Veterans Affairs, August, 2001.
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. by W. H. Inmon, 2003. p. 4. Accessed July 14, 2009.
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.The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1 . September 1999
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.
The current version (3) of the Zachman Framework categorizes the rows as follows: Executive Perspective (Scope Contents) – The first architectural sketch is a "bubble chart" or Venn diagram, 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.