John Zachman

From Wikipedia, the free encyclopedia
Jump to: navigation, search

John A. Zachman (born December 16, 1934) is an American business and IT consultant,[1] early pioneer of enterprise architecture, Chief Executive Officer of Zachman International (, and originator of the Zachman Framework.


Zachman holds a degree in Chemistry from Northwestern University. He served for a number of years as a line officer in the United States Navy, and is a retired Commander in the U.S. Naval Reserve.[2]

He joined IBM Corporation in 1964 and held various marketing-related positions in Chicago, New York and Los Angeles. He became involved with Strategic Information Planning methodologies in 1970.[3] and in 1973 he was assigned responsibility for the Business Systems Planning (BSP) program in IBM’s Western Region.[4] In 1984 he began to concentrate on Information Systems Architecture. In 1989 at IBM he joined the CASE Support organization of the Application Enabling Marketing Center, where he worked as a consultant in areas of Information Systems Planning and Architecture.[3] He retired at IBM in 1990, having served them for 26 years. Afterwards he co-founded, with Samuel B. Holcman, the Zachman Institute for Framework Advancement, which was discontinued in December, 2008.

He is a Fellow for the College of Business Administration of the University of North Texas. He serves on the Advisory Board for Boston University’s Institute for Leading in a Dynamic Economy (BUILDE), the Advisory Board for the Data Resource Management Program at the University of Washington and the Advisory Board of the Data Administration Management Association International (DAMA-I).[2]

In May 2002 he was awarded a Lifetime Achievement Award from the Advisory Board of the Data Administration Management Association International.[5] He was awarded the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation.[2]

After years of collaboration, in August 2015, John Zachman, the father Enterprise Architecture, joined the Board of Directors at - LEADing Practice and Global University Alliance with a mission to evolve how organizations gain value out of Enterprise Standards. His work includes Enterprise Ontology, Enterprise Semantics and Enterprise Architecture concepts. Zachman joins the board along with the other Board Members:

  • Prof. Dr. Dr. hc mult. August-Wilhelm Scheer (father of our Process thinking today)
  • Prof. Mark von Rosing (Chairman of the Global University Alliance)
  • Henrik von Scheel (CEO of LEADing Practice)
  • Mikael Munck (Saxo Bank)
  • Henk Kuil (KLM/ Air France)
  • Rod Peacock (European Patent Office)
  • Bas Bach (Dutch Railway)
  • Thomas Christian Olsen (Novozymes)


John Zachman is one of the founding developers of IBM's Business Systems Planning (BSP),[6] and worked on their Executive team planning techniques (Intensive Planning). In 1987 he originated the Zachman Framework a standard for classifying the descriptive representations (models) that comprise enterprise architecture.

Business Systems Planning[edit]

Business System Planning (BSP) is a method for analyzing, defining and designing an information architecture of organizations. It was first issued by IBM in 1981, though the initial work on BSP began in the early 1970s.[7] At first, it was for IBM internal use only. Later it was made available to customers[7] and this method became an important tool for many organizations. It is a very complex method dealing with data, processes, strategies, aims and organizational departments which are interconnected.

Business Systems Planning (BSP) and Business Information Control Study (BICS) according to Zachman (1982),[8] are both "information system planning methodologies that specifically employ enterprise analysis techniques in the course of their analyses. Underlying the BSP and BICS analyses are the data management problems that result from systems design approaches that optimize the management of technology at the expense of managing the data". The both methodologies have similarities and differences, and strengths and weaknesses. The "choice between using one or the other methodology is strongly influenced by the immediate intent of the study sponsor, tempered by the limiting factors currently surrounding the BICS methodology".[8]

Zachman Framework[edit]

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

The Zachman Framework according to Zachman (2008)[9] is "a schema - the intersection between two historical classifications that have been in use for literally thousands of years".

  • "The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why. It is the integration of answers to these questions that enables the comprehensive, composite description of complex ideas".
  • "The second is derived from reification, the transformation of an abstract idea into an instantiation that was initially postulated by ancient Greek philosophers and is labeled in the Framework: Identification, Definition, Representation, Specification, Configuration and Instantiation. ..."

More specifically, 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 is 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 of whatever)".[9]

According to Zachman, "this ontology was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created in the process of designing and producing complex physical products (e.g. buildings or airplanes). It uses a two dimensional classification model based on the six basic interrogatives (What, How, Where, Who, When, and Why) intersecting six distinct perspectives, which relate to stakeholder groups (Planner, Owner, Designer, Builder, Implementer and Worker). The intersecting cells of the Framework correspond to models which, if documented, can provide a holistic view of the enterprise".[10]

A way of thinking for Enterprise Architects[edit]

The often forgotten but increasingly important discipline is the ability to model the Enterprise Architecture. “There is a set of architectural representations produced over the process of building a complex engineering product representing the different foci of design as well as the different perspectives of different participants.” The article went on to identify those different participants as the Owner of the end product (the ‘customer’), the Designer of the product (the ‘engineer’ or ‘architect’) and the Builder of the product (the ‘manufacturing engineer’ or ‘contractor’). This concept is known as the Zachman Framework, in which the Owner’s, Designer’s and Builder’s perspectives, that is in the original Framework graphic is described. The Row 2 was labeled “Conceptual”, Row 3 “Logical” and Row 4 “Physical.” With many, this caused a lot of confusion because many people interpreted what was described to mean Conceptual, a high level of detail; Logical, a medium level of detail; and Physical, an excruciating level of detail. That is not what was described or even meant. It was detailed that the;

  • “Contextual Models” are the perspective of the Planners of the Enterprise.
  • “Conceptual Models” are the perspective of the Owners of the Enterprise.
  • “Logical Models” are the perspective of the Designers of the Enterprise.
  • “Physical Models” are the perspective of the Builder’s of the Enterprise.

Important to understand is that already in the original article, the case was made that the view and models the Builder applies, are not more detail than the Designer’s perspective models. In fact, they are different models. The same applies to the view and models of the Designer; they are not more detail than the view and models of the Owner. They are as argued different models. What differentiates the views and models is not levels of details, the models in the different Rows are different views and subsequently different context in terms of purpose and goals to the models. The reason this is so important is that the different views have all different value potential e.g. purpose and goals and as a result the different views have their specific transformation potential and governance concept that need to be explored and interlinked. The views are therefore not a decomposition view. Decomposition and composition happens through the relevant objects across the views and their models.

A way of working – the Enterprise Layers[edit]

The terms “Contextual, “Conceptual”, “Logical” and “Physical” are used in the context of the Enterprise, in which case “Contextual” means the Planners view and models, “Conceptual” means the Owner’s view and models, “Logical” means the Designer’s view and models and “Physical” means the Builders view and models. One could use the terms “Contextual”, “Conceptual”, “Logical” and “Physical” relative to an application or a system to mean high level, medium level and excruciating level of detail, given an indication of way of thinking, way of working and a way of modelling (building) but that is not all, one can and should use it relative to the Enterprise. An abstraction that represents and considers the enterprise as a whole. An enterprise should be considered as a whole which subsequently includes the views and models that capture the:

  • Business Perspective such as the resources, roles, enterprise competencies, enterprise capabilities, functions, process, and service.
  • Application Perspective such as the application components, application modules, tasks, application services, as well as the data components, data objects, data entities, data tables and data services.
  • Technology Perspective such as the platform components, platform function, platform devices and platform services, as well as the infrastructure components, infrastructure functions, infrastructure devices, infrastructure services.

The main principle behind working in an layered enterprise architecture development concept, and what makes it so unique from other traditional enterprise architecture concepts, is the fact that it does not only work in domains, but across layers (business, application and technology). It thereby enables the organization to work within multiple domains (also at the same time), with right illustrative perspective of the various views i.e. contextual, conceptual, logical and physical. In the combination of having a detailed ontological and semantic foundation it applies basic decomposition and composition principles to integrate effortlessly across the different layers when interlinking the different modelling principles. While Enterprise Architecture is relative, it is very precise and it is not arbitrary, it is absolute in the context of the Enterprise.

For that reason, the Enterprise Architecture principle that applies is an agile way of working, wherein the Enterprise Architecture one works on depends 1) what one is trying to do 2) which roles are involved. If you are trying to transcribe the Executive Stakeholder’s (the “Owner’s”) perspective, one will be working on the conceptual models e.g. the Business Layer Models. If one however, is the Architect (the “Designer”) trying to design the system logic to support the Executive Stakeholder’s concepts, one would be working on the Application Layer Models. If you however, are the Engineer (the “Builder”) trying to build the systems as designed by the Architects, you will be working on the Technology Layer Models, etc. For further specification, if you were working on the Business Processes, one would be working on the Process Models, while the expert working on the business services would work with the service models and so on. There is therefore a connection between the views, specific layer involved, the roles involved and the concern/challenge and or goal they need to solve and which models in terms of artefacts they work with.


Zachman has published three books, several articles[11] and forewords to more than a hundred books on related subjects. A selection:



  1. ^ Elizabeth N. Fong and Alan H. Goldfine (1989) Information Management Directions: The Integration Challenge. National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. p.63
  2. ^ a b c John A. Zachman Biographical Sketch. Accessed 15 Dec 2008.
  3. ^ a b Judith J. Newton, Frankie E. Spielman (1990). Data Administration: Standards & Techniques. p.18.
  4. ^ John A. Zachman : National Accounts Division, Los Angeles. California. Accessed 16 Dec 2008.
  5. ^ Data Management Association - Lifetime Achievement Award
  6. ^ Clifford A. Morton (1984). Managing Operations in Emerging Companies. Addison-Wesley. ISBN 0-201-15860-4, p. 127.
  7. ^ a b Business Systems Planning (IBM Corporation), paper 1. Robinson College of Business, Georgia State University.
  8. ^ a b John Zachman (1982). "Business Systems Planning and Business Information Control Study: A comparisment. In: IBM Systems Journal, vol 21, no 3, 1982. p.31-53.
  9. ^ a b John Zachman's Concise definition of the Zachman Framework, John A. Zachman, Zachman International, 2008
  10. ^ Interview with John Zachman, by Roger Sessions, Editor-in-Chief, Perspectives of the International Association of Software Architects
  11. ^ John A. Zachman List of publications from the DBLP Bibliography Server.

External links[edit]