Zachmanフレームワークはエンタープライズ分野向けのオントロジーであり、事業体を形式的・構造的な形で捉え（ビュー・モデル）、定義するためのエンタープライズアーキテクチャフレームワークである。オントロジーは2次元の分類スキーマになっており、昔から用いられている2つの分類法の組合せで作られている。1つ目の軸は基本的な疑問文（5W1H）で、2つ目の軸は哲学上の概念であり抽象的な概念の具体化を意味する具象化（Reification）をもとに作られている。
Zachmanフレームワークは、記述の対象となる情報の収集・管理・使用について特定の手法や手順に依ったものではなく、方法論ではない。Zachmanフレームワークはむしろ、アーキテクチャ上の成果物（言い換えると設計文書、仕様、モデル）を整理するための分類体系であり、成果物のターゲットとなる人（たとえば事業のオーナーや起業家）と解決すべき特定の課題（たとえばデータや機能性）の双方を考慮したものと言える。
Zachmanフレームワークという名前は、1980年代にIBMでこの概念を最初に開発したJohn Zachmanにちなんで命名されたものである。開発された後、数回の改訂がされている。
概要
本記事のタイトルである"Zachmanフレームワーク"は、2021年時点でThe Zachman Framework for Enterprise Architectureの最新版であるバージョン3.0のことを指している。Zachmanフレームワークは、30年間におよぶ歴史の中で以下のように発展してきた。 最初期のフレームワーク。"A Framework for Information Systems Architecture"という名前で、1987年にJohn ZachmanがIBM Systems journalで発表したもの。 1987年の版を、1990年代に拡張してThe Zachman Framework for Enterprise Architectureと改称したものThe Open Group (1999–2006). "ADM and the Zachman Framework" in: TOGAF 8.1.1 Online. Accessed 25 Jan 2009.。 その後のZachmanフレームワークで、Zachman Internationalから業界標準として提示されているもの。
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 framework to organize and analyze data,William H. Inmon, John A. Zachman, Jonathan G. Geiger (1997). Data Stores, Data Warehousing, and the Zachman Framework: Managing Enterprise Knowledge. McGraw-Hill, 1997. . 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 schemeKathleen 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. 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 perspectives 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.James McGovern et al. (2003). A Practical Guide to Enterprise Architecture. p. 127-129.
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.Marc Lankhorst (2005). Enterprise Architecture at Work. p. 24. 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.
歴史 In the 1980s John Zachman 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"Business Systems Planning and Business Information Control Study: A comparisment. In: IBM Systems Journal, vol 21, no 3, 1982. p. 31-53. 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.
情報システム仕組フレームワーク thumb|320px|Simple example of the 1992 Framework. In the 1987 article "A Framework for Information Systems Architecture"John A. Zachman (1987). " A Framework for Information Systems Architecture". In: IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298. 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.Durward P. Jackson (1992). "Process-Based Planning in Information Resource Management". In: Emerging Information Technologies for Competitive Advantage and Economic Development. Proceedings of 1992 Information Resources Management Association International Conference. Mehdi Khosrowpour (ed). . 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 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.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.
拡張と形式化 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.John F. Sowa and John Zachman (1992). "Extending and Formalizing the Framework for Information Systems Architecture" In: IBM Systems Journal, Vol 31, no.3, 1992. p. 590-616. 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 engineering implementation, and determining a logical build sequence of the pieces.
エンタープライズアーキテクチャフレームワーク 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".John A. Zachman (1997). "Concepts of the Framework for Enterprise Architecture: Background, Description and Utility". Zachman International. Accessed 19 Jan 2009.
In 2008 Zachman Enterprise introduced the Zachman Framework: The Official Concise Definition as a new Zachman Framework standard.
拡張され、変更されたフレームワーク 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"). 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 all (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.
Zachmanフレームワークのトピックス 概念 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 increasingly detailed views or levels of abstraction 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.The government information factory and the Zachman Framework by W. H. Inmon, 2003. p. 4. Accessed July 14, 2009.
横行のビュー 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. thumb|420px|The VA Zachman Framework with an explanation of its rows.US Department of Veterans Affairs (2002) A Tutorial on the Zachman Architecture Framework. Accessed 06 Dec 2008.Bill Inmon called this image "A simple example of The Zachman Framework" in the article John Zachman - One of the Best Architects I Know Originally published 17 November 2005. In the 1997 Zachman Framework the rows are described as follows: