Zachman framework

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Simple example of The Zachman Framework.[1][2]

The Zachman Framework is a framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise.

The Framework in practice is used for organizing enterprise architectural "artifacts" in a way that takes into account both:

These artifacts may include design documents, specifications, and models.[3]

The Framework is in essence a matrix,[4]. It is named after its creator John Zachman, who first developed the concept in the 1980s at IBM. It has been updated several times since.[5]


[edit] Overview

The term "Zachman Framework" has multiple meanings. It can refer to any of the frameworks proposed by John Zachman:

  • The initial framework, named A Framework for Information Systems Architecture, by John Zachman published in an 1987 article in the IBM Systems journal.[6]
  • The Zachman Framework for Enterprise Architecture, an update of the 1987 original in the 1990s extended and renamed .[7]
  • One of the later versions of the Zachman Framework, offered by Zachman International as industry standard.
Collage of Zachman Frameworks as presented in several books on Enterprise Architecture from 1997 to 2005.

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:

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 process for an architecture. Rather the matrix is a template that must be filled in by the processes specifically required by the organization. If these processes do not exist already, the framework helps identify these gaps in the architecture.[12]

The framework is a simple and logical structure for classifying and organizing the descriptive representation of an enterprise. It is significant to both the management of the enterprise, and the actors involved in the development of enterprise's systems.[13] While the framework is focused on the application oriented area of enterprise architecture, its scope includes non-IT components such as people, processes, and time, making it an appropriate addition to the overall IT Strategy toolkit for CIOs.[14]

Furthermore, the Zachman Framework provides a common context for understanding a complex structure. The Framework enables communication among the various participants involved in developing or changing the structure. Architecture is the glue that holds the structure together. The Framework defines sets of architectures that contain the development pieces of the structure.[15]

[edit] History

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[16] 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 to the, in that time considered, more esoteric issues of enterprise architecture, to data-driven systems design, to data classification criteria, and some more.[16]

[edit] Information Systems Architecture Framework

The first version of the originally called "Information Systems Architecture Framework" presented by John Zachman in 1987.
Simple example of the 1992 Framework.

In the 1987 article "A Framework for Information Systems Architecture"[17] 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.[18] 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.[18]

In the 1992 article "Extending and Formalizing the Framework for Information Systems Architecture" John F. Sowa and John Zachman presents the framework and its recent extensions and shows how it can be formalized in the notation of conceptual graphs.[19]

According to Stan Locke, 2008.[20]

  • John Sowa proposed the additions of the Scope perspective of the ‘planner’ (bounding lists common to the enterprise and its environment) and the Detailed Representation perspective of the ‘sub-contractor’
  • The Who, When and Why columns were brought into public view, the notion of the four levels of metaframeworks and a depiction of integration associations across the perspectives were all outlined in the paper.
  • Keri Anderson Healey assisted by creating a model of the models (the framework metamodel) which was also included in the article.

Later during the 1990s[20]

  • 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

Eventually the chosen terms in the framework are a move towards a more generic business language on the enterprise framework as shown in the diagram below.

[edit] Framework for Enterprise Architecture

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".[21]

In 2008 Zachman Enterprise introduced the Zachman Framework™: A Concise Definition as a new Zachman Framework standard.

[edit] Extended and modified frameworks

Since the 1990s several extended frameworks have been proposed, such as:

[edit] Zachman Framework topics

[edit] 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 (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.[6]

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. (Source: here, p.4)

[edit] Views or 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. Nor does an upper row decompose into greater detail in a lower row. 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.[25]

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.[25]

The VA Zachman Framework with an explanation of it's rows.[1]

In the 1997 Zachman Enterprise Architecture Framework the rows are described as follows:[25]

  • Planner's View (Scope) - 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.
  • Owner's View (Enterprise or Business Model) - Next are the architect's drawings that depict the final building from the perspective of the owner, who will have to live with it in the daily routines of business. They correspond to the enterprise (business) models, which constitute the designs of the business and show the business entities and processes and how they relate.
  • Designer's View (Information Systems Model) - The architect's plans are the translation of the drawings into detail requirements representations from the designer's perspective. They correspond to the system model designed by a systems analyst who must determine the data elements, logical process flows, and functions that represent business entities and processes.
  • Builder's View (Technology Model) - The contractor must redraw the architect's plans to represent the builder's perspective, with sufficient detail to understand the constraints of tools, technology, and materials. The builder's plans correspond to the technology models, which must adapt the information systems model to the details of the programming languages, input/output (I/O) devices, or other required supporting technology.
  • Subcontractor View (Detailed Specifications) - Subcontractors work from shop plans that specify the details of parts or subsections. These correspond to the detailed specifications that are given to programmers who code individual modules without being concerned with the overall context or structure of the system. Alternatively, they could represent the detailed requirements for various commercial-off-the-shelf (COTS), GOTS, or components of modular systems software being procured and implemented rather that built.
  • Actual System View or The Functioning Enterprise

[edit] Focus or Columns

In summary, each perspective focuses attention on the same fundamental questions, then answers those questions from that viewpoint, creating different descriptive representations (i.e., models), which translate from higher to lower perspectives. The basic model for the focus (or product abstraction) remains constant. The basic model of each column is uniquely defined, yet related across and down the matrix.[25] In addition, the six categories of Enterprise Architecture components, and the underlying interrogatives that they answer, form the columns of the Zachman Enterprise Architecture Framework and these are:[6]

  1. The Data Description — What
  2. The Function Description — How
  3. The Network Description — Where
  4. The People Description — Who
  5. The Time Description — When
  6. The Motivation Description — Why

In Zachman’s opinion, the single factor that makes his framework unique is that each element on either axis of the matrix is explicitly distinguishable from all the other elements on that axis. The representations in each cell of the matrix are not merely successive levels of increasing detail, but actually are different representations — different in context, meaning, motivation, and use. Because each of the elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell.[6]

[edit] Models or Cells

The kinds of models or architectural descriptive representations are made explicit at the intersections of the rows and columns. An intersection is referred to as a cell. Because a cell is created by the intersection of a perspective and a focus, each is distinctive and unique. Since each cell is distinctive and unique, the contents of the cell are normalized and explicit per the perspective’s focus.[25]

Since the product development (i.e., architectural artifact) in each cell or the problem solution embodied by the cell is the answer to a question from a perspective, typically, the models or descriptions are higher-level depictions or the surface answers of the cell. The refined models or designs supporting that answer are the detailed descriptions within the cell. Decomposition (i.e., drill down to greater levels of detail) takes place within each cell. If a cell is not made explicit (defined), it is implicit (undefined). If it is implicit, the risk of making assumptions about these cells exists. If the assumptions are valid, then time and money are saved. If, however, the assumptions are invalid, it is likely to increase costs and exceed the schedule for implementation.[25]

[edit] Framework set of rules

Example of Zachman Framework Rules.

The framework comes with a set of rules:[26]

  • Rule 1 The columns have no order : The columns are interchangeable but cannot be reduced or created
  • Rule 2 Each column has a simple generic model : Every column can have its own meta-model
  • Rule 3 The basic model of each column must be unique : The basic model of each column, the relationship objects and the structure of it is unique. Each relationship object is interdependent but the representation objective is unique.
  • Rule 4 Each row describes a distinct, unique perspective : Each row describes the view of a particular business group and is unique to them. All rows are usually present in most hierarchical organization
  • Rule 5 Each cell is unique : The combination of 2,3 & 4 must produce unique cells where each cell represents a particular case. Ex: A2 represents business outputs as they represent what are to be eventually constructed
  • Rule 6 The composite or integration of all cell models in one row constitutes a complete model from the perspective of that row : For the same reason as for not adding rows and columns, changing the names may change the fundamental logical structure of the Framework.
  • Rule 7 The logic is recursive : The logic is relational between two instances of the same entity.

The Framework is generic in that it can be used to classify the descriptive representations of any physical object as well as conceptual objects such as enterprises. It is also recursive in that it can be used to analyze the architectural composition of itself. Although, the framework will carry the relation from one column to the other it is still a fundamental structural representation of the enterprise and not a flow representation.

[edit] Applications

Since the 1990s the Zachman Framework is widely used as a means of providing structure for Information Engineering style enterprise modeling.[27] The Zachman Framework can be applied both in commercial companies and in government agencies. Within a government organization the framework can be applied it an entire agency at an abstract level, or it can be applied to various departments, offices, programs, subunits and even to basic operational entities. [28]

[edit] Customization

Zachman Framework is applied in customized frameworks such as the TEAF, build around the similiar frameworks, the TEAF matrix.

Other sources:

  • The TEAF matrix is called a Customization sample, see here, p.22

[edit] Standards based on the Zachman Framework

Zachman Framework is also used as a framework to describe standards, for example standards for healthcare and healthcare information system. Each cell of the framework contains such a series of standards for healthcare and healthcare information system.[29]

[edit] Mapping other frameworks

An other application of the Zachman Framework is as reference model for other Enterprise Architectures, see for example these four:

Other examples:

[edit] Base for other Enterprise Architecture framework

Less obvious are the ways the original Zachman framework has stimulated the development of other Enterprise Architecture frameworks, such as in the NIST Enterprise Architecture Model, the C4ISR AE, the DOE AE, and the DoDAF:

[edit] Example: One-VA Enterprise Architectures

The Zachman Framework methodology has for example been used in the US VA Department to develop and maintain its One-VA Enterprise Architecture in 2001. This methodology required them to define all aspects of the VA Enterprise from a business process, data, technical, location, personnel, and requirements perspective. The next step in implementing the Zachman methodology has been to define all functions related to each business process and identify associated data elements. Once identified, duplication of function and inconsistency in data definition can be identified. The hard job then followed to de-conflict the data definitions and resolve duplicative implementations of the same business function.[34]

The Department of Veterans Affairs in the new Millennium was planning to implement a Enterprise Architecture full based on the Zachman Framework.

  • The Zachman Framework was used as a reference model to initiate a Enterprise Architecture Planning in 2001.
  • Somewhere in between the VA Zachman Framework Portal was constructed.
  • This VA Zachman Framework Portal is still in use as a reference model for example in the determination of EA information collected from various business and project source documents.
  • Now somewhere in the past this "A Tutorial on the Zachman Architecture Framework".

Eventually a Enterprise Architecture Repository is created at the macro level by the Zachman framework and at a cell level by the Meta-model outlined below.[35]

VA EA Meta-Model Cell Details Enlarged.

[edit] Criticism

The primary strength of the Zachman Framework is that it explicitly shows that many views needs to be addressed by enterprise architecture.[12] It also has some potential problems:

  • The Zachman framework can lead to a heavy documented approach : Each of the thirty cells of the framework needs to be supported by some kind of artefact, which can need a lot of documentation.[12]

[edit] See also

[edit] References

  1. ^ a b US Department of Veterans Affairs (2002) A Tutorial on the Zachman Architecture Framework. Accessed 06 Dec 2008.
  2. ^ 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.
  3. ^ A Comparison of the Top Four Enterprise Architecture Methodologies, Roger Sessions, Microsoft Developer Network Architecture Center,
  4. ^ a b Paul Harmon (2003). Business Process Change. Morgan Kaufmann. ISBN 1558607587 p.318.
  5. ^ John Baschab, Jon Piot, Nicholas G. Carr (2007). The Executive's Guide to Information Technology. p. 84.
  6. ^ a b c d VA Enterprise Architecture Innovation Team (2001). Enterprise Architecture: Strategy, Governance, & Implementation report Department of Veterans Affairs, August, 2001.
  7. ^ a b The Open Group (1999-2006). "ADM and the Zachman Framework" in: TOGAF 8.1.1 Online. Accessed 25 Jan 2009.
  8. ^ William H. Inmon, John A. Zachman, Jonathan G. Geiger (1997). Data Stores, Data Warehousing, and the Zachman Framework: Managing Enterprise Knowledge. McGraw-Hill, 1997. ISBN 0070314292.
  9. ^ Pete Sawyer, Barbara Paech, Patrick Heymans (2007). Requirements Engineering: Foundation for Software Quality. page 191.
  10. ^ Kathleen B. Hass (2007). The Business Analyst as Strategist: Translating Business Strategies Into Valuable Solutions. page 58.
  11. ^ Harold F. Tipton, Micki Krause (2008). Information Security Management Handbook, Sixth Edition, Volume 2‎. page 263.
  12. ^ a b c James McGovern et al. (2003). A Practical Guide to Enterprise Architecture. p.127-129.
  13. ^ Marc Lankhorst (2005). Enterprise Architecture at Work. p.24.
  14. ^ John Baschab et al. (2007). The Executive's Guide to Information Technology. p.84.
  15. ^ The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1. September 1999
  16. ^ a b "Business Systems Planning and Business Information Control Study: A comparisment. In: IBM Systems Journal, vol 21, no 3, 1982. p.31-53.
  17. ^ John A. Zachman (1987). " A Framework for Information Systems Architecture". In: IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298.
  18. ^ a b c 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). ISBN 1878289179.
  19. ^ 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.
  20. ^ a b Stan Locke (2008). "Enterprise Convergence in Our Lifetime" In: THE ENTERPRISE NEWSLETTER, TEN42 September 16, 2008
  21. ^ John A. Zachman (1997). "Concepts of the Framework for Enterprise Architecture: Background, Description and Utility". Zachman International. Accessed 19 Jan 2009.
  22. ^ R.W. Matthews. &. W.C. McGee (1990). "Data Modeling for Software Development". in: IBM Systems Journal" 29(2). pp. 228-234
  23. ^ D.J. Schoch &. P.A. Laplante (1995). A framework for real-time systems architecture In: IBM SYSTEMS Journal, Vol 34, no 1, 1995. p.20-38.
  24. ^ Jaap Schekkerman (2003). How to Survive in the Jungle of Enterprise Architecture Frameworks. page 139-144.
  25. ^ a b c d e f g The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1. September 1999
  26. ^ Adapted from: Sowa, J.F. & J.A. Zachman, 1992, and Inmon, W.H, J.A. Zachman, & J.G. Geiger, 1997. University of Omaha
  27. ^ Ian Graham (1995). Migrating to Object Technology: the semantic object modelling approach. Addison-Wesley, ISBN 0201593890. p.322.
  28. ^ Jay D. White (2007). Managing Information in the Public Sector. p.254.
  30. ^ DJ de Villiers (2001). "Using the Zachman Framework to Assess the Rational Unified Process", In: The Rational Edge Rational Software 2001.
  31. ^ David S. Frankel et al. (2003) The Zachman Framework and the OMG's Model Driven Architecture White paper. Business Process Trends.
  32. ^ Hervé Panetto, Salah Baïna, Gérard Morel (2007). Mapping the models onto the Zachman framework for analysing products information traceability : A case Study.
  33. ^ Roland Traunmüller (2004). Electronic Government p.51
  34. ^ Statement of Dr. John A. Gauss, Assistant Secretary for Information and Technology, Department of Veterans Affairs, before the Subcommittee on Oversight and Investigations Committee on Veterans' Affairs U.S. House of Representatives. March 13, 2002.
  35. ^ Meta-Model Cell Details Accessed 25 Dec 2009

[edit] External links

Personal tools