Enterprise Quantum Mechanics (Part 1)

John A.  Zachman
John A. Zachman Chief Executive Officer, Zachman International Read Author Bio || Read All Articles by John A. Zachman

It is my contention throughout my new book[1] that Enterprise Engineering and Manufacturing is the applied physics of systems theory.[2]  There is an enormous body of knowledge supporting not only formal systems theory but also the related subjects that are foundational for modeling, like systematics, the science of classification.[3]  Classification leads to categorization, which leads to taxonomies and semiotics (syntactics, semantics, and pragmatics), which leads to ontology, cosmology, and epistemology, the branches of metaphysics, which leads to philosophy, which ultimately leads to origins, that is, theology.

Modeling is like the tip of the iceberg. You don't have to know about the rest of the iceberg, only that it is down there.

Similarly, arithmetic is the tip of the mathematical iceberg, which can also be traced back ultimately to metaphysics, philosophy, and theology.

You don't have to know everything about the entire iceberg of knowledge to practice modeling any more than you have to know everything about the theories and philosophy of mathematics to do arithmetic. However, in both cases, it can get really complex and ethereal really quickly. In the case of Enterprise modeling, I would call this the "Quantum Mechanics" of Enterprise Architecture.

I have written my book from a very conceptual standpoint. I have not attempted to address the potentially enormous complexity implicit in the subject and all the underlying disciplines. Clearly, Enterprises are enormously complex. Even rather small Enterprises are enormously complex. Life is too short. I cannot possibly know all there is to know about the enormous supporting body of knowledge.

It will remain for others (maybe many others) to take the concepts, including any concepts that I have explored, and form them into a coherent theory of Enterprise Quantum Mechanics. In fact, I doubt that any one person will ever be able to integrate all the complexity of the entire body of knowledge into a unified field theory of Enterprise Architecture. The best we can hope for is a coherent Framework to guide our further study and investigation of the laws of nature relative to Enterprises.

This topic draws from an appendix in my new book, where it was too extensive to present as a footnote. But I didn't want to include it in the main body of the text because I didn't want anyone to be discouraged or intimidated by the complexity or the fact that in 2002, we simply haven't yet integrated all the body of knowledge or understood all of the laws of nature related to Enterprises. At the same time, I am aware that it is useful to discuss some of the complexity because, as practitioners, we are confronted by anomalies to resolve, and clearly the meta community (e.g., the tool and repository suppliers) presently are making explicit trade-offs relative to the structural complexities.

To reiterate, we don't have to know everything before we can begin working on Architecture. Where there are some unknowns, my observation is we just need to use our common sense and understanding of the principles we do know.

Having said all that, let me address the issues of 'primitives' versus 'composites' that are core to this subject. Clearly, the Framework identifies six categories of descriptions, based on the six primitive interrogatives:[4]

What Things Material Composition
How Process Functional Characteristics
Where Location Distribution
Who People Operating Instructions
When Events Timing Diagrams
Why Ends Desired State Specifications

I am confident that these are all primitive because they are all unique, independent variables.

I am confident that they are all comprehensive because they derive directly from the comprehensive six, primitive interrogatives.

To be interesting from a systems theory standpoint as descriptive of the Enterprise (see again note [2]), structure would have to be added to the categories -- internal structure within each category, and external structure across all categories.

Regarding the internal structure, each primitive component would be related to all like components of the primitive category. For example, in Column 1, the primitive component Thing would be related to all the other like components (Things) in the category. Therefore, the internal structure of the Column 1 models would be Things and Relationships, where Relationships would express the existence constraints between the Things.

In Column 2, the primitive components would be Processes and Inputs/Outputs where the Input is some material that is transformed by the Process into some (other) material Output which is Input to some (other) Process, forming the structure of the Process models.

In Column 3, the primitive components are Location and Link, where Link is the connection between the Locations.

In Column 4, the primitive components are Organization (People) and Work Product, where the work product is some physical object or report or decision that one Organization produces and upon which another Organization is dependent.

In Column 5, the primitive components are Events (points in time) and Cycles (lengths of time).

In Column 6 the primitive components are Ends (desired states) and Strategies (the choices of actions to realize the states).

Regarding the external structure across all of the Columns, the model would relate all of the primitive components in all of the Cells across a Row, as appropriate. That is, since all of the primitive components are Things (that is, nouns, for example, Things, Relationships, Processes, Inputs/Outputs, Locations, Links, Organizations, Work Products, Events, Cycles, Ends, Strategies), they can be related to each other in a typical Thing – Relationship – Thing fashion. The horizontally-integrated model across any one Row of the Framework will express the existence constraints between the various primitive components of the whole Row.

Next time, I will conclude with some other interesting observations about the nature of Architectural primitives and composites. I will explain why I say that if you are not building primitive models you are not doing Architecture; you are doing implementations.

...to be continued

Notes

[1]  For information on John Zachman's new book visit www.ZIFA.com. return to article

[2]  "Formal System," (from the Encyclopaedia Britannica) also called Logistic System, in logic and mathematics, abstract, theoretical organization of terms and implicit relationships that is used as a tool for the analysis of the concept of deduction. Models -- structures that interpret the symbols of a formal system -- are often used in conjunction with formal systems.
    Each formal system has a formal language composed of primitive symbols acted on by certain rules of formation (statements concerning the symbols, functions, and sentences allowable in the system) and developed by inference from a set of axioms. The system thus consists of any number of formulas built up through finite combinations of the primitive symbols -- combinations that are formed from the axioms in accordance with the stated rules.
    In an axiomatic system, the primitive symbols are undefined; and all other symbols are defined in terms of them. In the Peano postulates for the integers, for example, 0 and ' are taken as primitive, and 1 and 2 are defined by 1 = 0' and 2 = 1'. Similarly, in geometry such concepts as "point," "line," and "lies on" are usually posited as primitive terms.
    From the primitive symbols, certain formulas are defined as well formed, some of which are listed as axioms; and rules are stated for inferring one formula as a conclusion from one or more other formulas taken as premises. A theorem within such a system is a formula capable of proof through a finite sequence of well-formed formulas, each of which either is an axiom or is inferred from earlier formulas.
    A formal system that is treated apart from intended interpretation is a mathematical construct and is more properly called logical calculus; this kind of formulation deals rather with validity and satisfiability than with truth or falsity, which are at the root of formal systems.
    In general, then, a formal system provides an ideal language by means of which to abstract and analyze the deductive structure of thought apart from specific meanings. Together with the concept of a model, such systems have formed the basis for a rapidly-expanding inquiry into the foundations of mathematics and of other deductive sciences and have even been used to a limited extent in analyzing the empirical sciences. See also deontological ethics; metalogic; metatheory.
    Copyright © 1994-2000 Encyclopædia Britannica, Inc. return to article

[3]  Merriam Webster Dictionary return to article

[4]  I have used some slight terminology variations when I have discussed these, but the essence of the ideas is constant. return to article

# # #

Standard citation for this article:


citations icon
John A. Zachman, "Enterprise Quantum Mechanics (Part 1)" Business Rules Journal, Vol. 3, No. 3, (Mar. 2002)
URL: http://www.brcommunity.com/a2002/b108a.html

About our Contributor:


John  A. Zachman
John A. Zachman Chief Executive Officer, Zachman International

John Zachman is the originator of the "Framework for Enterprise Architecture" (The Zachman Framework) which has received broad acceptance around the world as an integrative framework, an ontology for descriptive representations of Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM's Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning).

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Chief Executive Officer of his own education and consulting business, Zachman International® and Owner and Executive Director of the Federated Enterprise Architecture Certification Institute in Washington, D.C.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has directed innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent.

Read All Articles by John A. Zachman
Subscribe to the eBRJ Newsletter
CONTRIBUTOR ARCHIVES
7 Common Myths (Plus 1) About the Zachman Architecture Framework
Enterprise Architecture Defined: Architecture Abstractions
Enterprise Architecture Defined: (2) Complexity and Change
Enterprise Architecture Defined: (1) What is Architecture?
The Business Agility Manifesto — The Authors Speak Out Q&A with Roger T. Burlton, Ronald G. Ross, & John A. Zachman
In The Spotlight

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.