# Enterprise Quantum Mechanics (Part 1)

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.

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

[3] Merriam Webster Dictionary

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

# # #

### About our Contributor:

**Spotlight**

**BRSolutions Professional Training Suite**

**All About Concepts, Policies, Rules, Decisions & Requirements**

We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.

Define Business TermsHow to Define Business Terms in Plain English: A PrimerDecision Analysis Q-Charts^{™}How to Use DecisionSpeak^{™}and Question Charts (Q-Charts^{™})Decision Tables TableSpeak^{™}Decision Tables - A Primer: How to Use TableSpeak^{™}Tabulation of ListsTabulation of Lists in RuleSpeak^{®}: A Primer - Using "The Following" ClauseBAM InsiderBusiness Agility ManifestoBRManifesto InsiderBusiness Rules ManifestoBMM InsiderBusiness Motivation ModelDecisions InsiderDecision Vocabulary[Download]

[Download]

SBVR InsiderSemantics of Business Vocabulary and Business Rules