Zachman Framework - Revision history

User at 16:33, 27 June 2024

2024-06-27T16:33:50Z

User at 15:16, 5 March 2024

2024-03-05T15:16:54Z

User at 22:44, 18 January 2023

2023-01-18T22:44:06Z

User at 22:26, 18 January 2023

2023-01-18T22:26:00Z

User at 09:21, 17 January 2023

2023-01-17T09:21:07Z

User at 16:00, 19 December 2022

2022-12-19T16:00:09Z

User at 20:10, 21 November 2022

2022-11-21T20:10:17Z

Show changes

User: /* See Also */

2022-01-17T22:57:19Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T19:20:26Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

Show changes

User: /* See Also */

2019-12-05T00:25:14Z

@@ Line 91: / Line 91: @@
 ===Further Reading===
 *[http://www.brcommunity.com/articles.php?id=b811 The Zachman Framework Evolution (Part 1)]
 *[http://apps.adcom.uci.edu/EnterpriseArch/Zachman/Resources/ZachmanTutorial.ppt A Tutorial on the Zachman Framework for Enterprise Architecture]

@@ Line 1: / Line 1: @@
 ==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.<ref>[https://en.wikipedia.org/wiki/Zachman_FrameworkDefinition - What is the Zachman Framework?]</ref>
+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.<ref>[https://en.wikipedia.org/wiki/Zachman_FrameworkDefinition - What is the Zachman Framework?]</ref>
 __NOTOC__
@@ Line 6: / Line 6: @@
 '''The Origins and Purpose of the Zachman Enterprise Framework'''<ref>The Origins and Purpose of the Zachman Enterprise Framework [http://www.technical-communicators.com/articles/zachman_framework.pdf Technical Communicatores]</ref><br />
 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)|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).
+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)|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 Framework|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).
@@ Line 70: / Line 70: @@
 ===See Also===

@@ Line 6: / Line 6: @@
 '''The Origins and Purpose of the Zachman Enterprise Framework'''<ref>The Origins and Purpose of the Zachman Enterprise Framework [http://www.technical-communicators.com/articles/zachman_framework.pdf Technical Communicatores]</ref><br />
 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)|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)]].
+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)|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).

← Older revision		Revision as of 22:26, 18 January 2023
Line 70:		Line 70:

	===See Also===		===See Also===
−	*[[Enterprise Architecture]]	+
−	*[[Enterprise Architecture Framework]]
−	*[[Business Systems Planning (BSP)]]
−	*[[Enterprise Architecture Management (EAM)]]
−	*[[Enterprise Architecture Value Framework (EAVF)]]
−	*[[Adaptive Enterprise Framework (AEF)]]
−	*[[Technical Architecture Framework for Information Management (TAFIM)]]
−	*[[Enterprise Architecture Governance]]
−	*[[Enterprise Architecture Life Cycle (EALC)]]
−	*[[Architecture Description Language (ADL)]]
−	*[[Architecture Development Method (ADM)]]

@@ Line 64: / Line 64: @@
 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.
+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.
+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.

@@ Line 72: / Line 72: @@
 ===See Also===
-[[Enterprise_Architecture|Enterprise Architecture]]<br />
+*[[Enterprise_Architecture|Enterprise Architecture]]
-[[Enterprise_Architecture_Framework|Enterprise Architecture Framework]]<br />
+*[[Enterprise_Architecture_Framework]]
-[[Business_Systems_Planning_(BSP)|Business Systems Planning (BSP)]]
+*[[Business_Systems_Planning_(BSP)|Business Systems Planning (BSP)]]
-[[Enterprise_Architecture_Management_(EAM)|Enterprise Architecture Management (EAM)]]<br />
+*[[Enterprise_Architecture_Management_(EAM)|Enterprise Architecture Management (EAM)]]
-[[Enterprise_Architecture_Value_Framework_(EAVF)| Enterprise Architecture Value Framework (EAVF)]]<br />
+*[[Enterprise_Architecture_Value_Framework_(EAVF)| Enterprise Architecture Value Framework (EAVF)]]
-[[Federal_Enterprise_Architecture_Framework_(FEA)|Federal Enterprise Architecture Framework (FEA)]]<br />
+*[[Federal_Enterprise_Architecture_Framework_(FEA)|Federal Enterprise Architecture Framework (FEA)]]
-[[Department_of_Defense_Architecture_Framework_(DoDAF)|Department of Defense Architecture Framework (DoDAF)]]<br />
+*[[Department_of_Defense_Architecture_Framework_(DoDAF)|Department of Defense Architecture Framework (DoDAF)]]
-[[The_Open_Group_Architecture_Framework_(TOGAF)|The Open Group Architecture Framework (TOGAF)]]<br />
+*[[The_Open_Group_Architecture_Framework_(TOGAF)|The Open Group Architecture Framework (TOGAF)]]
-[[Adaptive_Enterprise_Framework_(AEF)|Adaptive Enterprise Framework (AEF)]]<br />
+*[[Adaptive_Enterprise_Framework_(AEF)|Adaptive Enterprise Framework (AEF)]]
-[[Technical_Architecture_Framework_for_Information_Management_(TAFIM)|Technical Architecture Framework for Information Management (TAFIM)]]<br />
+*[[Technical_Architecture_Framework_for_Information_Management_(TAFIM)|Technical Architecture Framework for Information Management (TAFIM)]]
-[[IT Strategy (Information Technology Strategy)]]<br />
+*[[IT Strategy (Information Technology Strategy)|IT Strategy]]
-[[IT Governance|Governance of Information Technology]]<br />
+*[[IT Governance]]
-[[Enterprise Architecture Governance]]<br />
+*[[Enterprise Architecture Governance]]
-[[Enterprise Architecture Life Cycle (EALC)]]<br />
+*[[Enterprise Architecture Life Cycle (EALC)]]
-[[Architecture Description Language (ADL)]]<br />
+*[[Architecture Description Language (ADL)]]
-[[Architecture Development Method (ADM)]]<br />
+*[[Architecture Development Method (ADM)]]
-[[Architecture Driven Modernization]]<br />
+*[[Architecture Driven Modernization]]
-[[Architected, Model-Driven Development (AMD)]]<br />
+*[[Architected, Model-Driven Development (AMD)]]
-[[Architectural Pattern]]<br />
+*[[Architectural Pattern]]
-[[Architectural Principles]]<br />
+*[[Architectural Principles]]
-[[Architectural Risk]]<br />
+*[[Architectural Risk]]
-[[Architectural Style]]<br />
+*[[Architectural Style]]
-[[Architecture Tradeoff Analysis Method (ATAM)]]<br />
+*[[Architecture Tradeoff Analysis Method (ATAM)]]
 ===References===