Subscribe to the FREE Business Rules Journal Newletter





Conceptual, Logical, Physical: It Is Simple (part 2 of 2)

by John A. Zachman

Last time I discussed the ideas of "Conceptual, Logical, and Physical" from the perspective of the Enterprise.   In this article, let me speculate why those words are so confusing and misunderstood by those of us who come from the Information community.   Similar confusion centers around the words "Requirements, Architecture, and Design."   I think the source of the confusion around both sets of words is the same.

First of all, it depends upon who you are, what you are thinking is "Conceptual," "Logical," and "Physical" ... or "Requirements," "Architecture," and "Design."

Whatever Cell you are working on, the Cell above you looks to you like "Conceptual" (or, "Requirements") and the Cell below looks like "Physical" (or, "Design").   By default, you either don't know what to call what you are working on, or you call it "Logical" (or, "Architecture.")

If you happen to be working at Row 3, to you Row 2 looks to be "Conceptual" and Row 4 looks to be "Physical."   However, if you are working at Row 4, Row 3 looks to be "Conceptual" and Row 5 looks to be "Physical."  If you are working at Row 5, Row 4 looks to be "Conceptual" and Row 6 looks to be "Physical."   (You can substitute the words "Requirements" for Conceptual and "Design" for Physical in this paragraph for the same effect.)

Conceptual, Logical, Physical ... it's all RELATIVE.   It depends upon who you are.   The "Requirements" for any one Cell are coming from the Cell above, and the implementation of that Cell is reflected in the Cell below.

Therefore, please notice, "Quality" is a function of the vertical relationship between the Cells of any one Column.   For example, where do you find the quality criteria for Column 1, Row 5, the Data Definition?   That is, how do you know whether you have the correct product specification for the data elements?   Well ... from the Cell above, the Data Design, Row 4.    The quality question is, "does the product specification support the intent of the Data Design?"

Where do you find the quality criteria for the Column 1, Row 4, Data Design?  That is, how do you know whether you have the correct Physical Data Model (Data Design)?  Well ... from the Logical Data Model, Row 3.   The quality question is, "does the Physical Data Model support the intent of the Logical Data Model?"

Where do you find the quality criteria for the Column 1, Row 3, Logical Data Model?  That is, how do you know whether you have the correct Logical Data Model?    Well ... from the Enterprise Semantic Model, Row 2.   The quality question is, "does the Logical Data Model support the intent of the Enterprise Semantic structures?"

In a TOTAL sense, how do you ensure that the data in the Database (Row 6) will meet the intent of Management (Row 2)??   Well ... you have to keep all of the quality criteria incrementally ALIGNED vertically from Cell to Cell. Total Quality Management is defined as "Producing Products (Row 6) that meet the 'Requirements' of the Customer (Row 2)."   That is, INCREMENTALLY, does the Cell you are producing meet the "Requirements" of the Cell above, and get successfully "Designed" (implemented) in the Cell below?

To further the confusion, the word "Architecture" tends to be associated with either "Requirements" or "Logical" whereas "Design" tends to be associated with "Physical."   This probably stems from the fact that we, the I/S community, are starting at Row 3 and in an absolute, Enterprise sense, don't truly address Row 2, the Conceptual models.    As a result of our Row 2 deficiencies, some people would like to change the name of Row 3 to "Architecture" and Row 4 to "Design" and then eliminate all reference to the words, "Conceptual, Logical, and Physical."    My opinion is, changing any Row names would only add to the confusion.    In order to resolve the confusion, we must perceive the Enterprise in its entirety and in an absolute sense perceive:

  • Row 2. "The Owner's View."
  • Row 3. "The Designer's View."
  • Row 4. "The Builder's View."

RELATIVELY speaking, it is confusing because, with the exception of Rows 1 and 6, it is ALL Conceptual, it is ALL Logical and it is ALL Physical ... and it is ALL Requirements.   It is ALL Architecture and it is ALL design ... because it is ALL RELATIVE, depending upon who you are.

I will forever be dogmatic -- the Framework ("The Framework for Enterprise Architecture") depicts the total set of descriptive representations relevant for describing an Enterprise and therefore, it is all "Architecture," in the sense that it is all descriptive, short of being the actual Enterprise itself.  In an absolute sense, Row 2 are "Models of the Business" (the "Owner's View"), Row 3 are "Models of the Systems" (the "Designer's View"), and Row 4 are "Technology-constrained Models" (the "Builder's View").  This is a demonstration of why the Framework is a useful communication tool ... to help be "absolutely" specific about what we are talking about so we can avoid any misinterpretation of what is Conceptual, Logical, or Physical ... or what is Requirements, Architecture, or Design.

There is one more factor that should be considered ... from a "Scope" standpoint (i.e., project scope, Department Scope, Enterprise-wide Scope, etc., etc.), the Enterprise should be looked at holistically as these models are being produced as well.   That is, for example, it probably is NOT a good idea to look at the Marketing System as a stand-alone implementation, or the Manufacturing System as a stand-alone system, or the Accounting System as a stand-alone system (etc., etc.) because, this will lead to introducing discontinuity and redundancy into the data surrogates of the Enterprise ... that is, it would result in building "stove-pipes" or "Islands of Automation."   In this event, by definition, the "White Collar" system will get out of sync with the "Blue Collar" system and the "Owners" are likely to become very unhappy ... it is only a matter of time.   The advisable thing to do is to look at the Enterprise holistically, at least at Row 2 first, and then figure out how to break it up into pieces for implementation incrementally, controlling the discontinuity you are building into ANY of the Columns of models.   But this is a subject for a different discussion.

Conceptual, Logical, and Physical ... or Requirements, Architecture, and Design ... it is simple.   That is, it is simple as long as you recognize their relativity and establish the ENTERPRISE context absolutely.

Copyright, 2001. Zachman International.

January 2017
By John A. Zachman

October 2016
Strategy Spectrum for Enterprise Engineering and Manufacturing
By John A. Zachman

July 2016
The New EA Paradigm
(4) The Assemble-to-Order Pattern

By John A. Zachman

June 2016
The New EA Paradigm
(3) The Provide-from-Stock Pattern

By John A. Zachman

May 2016
The New EA Paradigm
(2) The Make-to-Order Pattern

By John A. Zachman

April 2016
The New EA Paradigm
(1) Expenses and Assets

By John A. Zachman

March 2016
The Information Age: (3) Powershift
By John A. Zachman

February 2016
The Information Age: (2) The Third Wave
By John A. Zachman

January 2016
The Information Age: (1) Future Shock
By John A. Zachman

December 2015
Defining Enterprise Architecture: Economics and the Role of I.T.
By John A. Zachman

November 2015
Enterprise Physics 101
By John A. Zachman

September 2015
A Historical Look at Enterprise Architecture with John Zachman
By John A. Zachman

August 2015
Cloud Computing and Enterprise Architecture
By John A. Zachman

June 2015
The Zachman Framework Evolution (Part 2)
Special Guest: John P. Zachman

May 2015
The Zachman Framework Evolution (Part 1)
Special Guest: John P. Zachman

April 2015
Architecture is Architecture is Architecture
By John A. Zachman

April 2013
John Zachman's Concise Definition of The Zachman Framework
By John A. Zachman

November 2004
The Zachman Framework and Observations on Methodologies


November 2003

Framework Fundamentals: Frameworks, Reference Models, and Matrices


August 2003

Framework Fundamentals:  A Dialog With John Zachman


June 2003

Framework Fundamentals:  Miscellaneous Enterprise Engineering Concepts


April 2003

Framework Fundamentals:  Framework Fundamentals:  Level of Detail is a Function of a CELL


February 2003

Framework Fundamentals:  Responding to Questions from the OMG


May 2002

Enterprise Quantum Mechanics (Part 2)


March 2002

Enterprise Quantum Mechanics (Part 1)


January 2002

"What" Versus "What"


November 2001

Security And The "Zachman Framework"


September 2001

Fatal Distractions (Part 2)


July 2001

Fatal Distractions (Part 1)


May 2001

You Can't "Cost-Justify" Architecture


March 2001

Conceptual, Logical, Physical:  It Is Simple  (Part 2 of 2)


January 2001

Conceptual, Logical, Physical:  It Is Simple  (Part 1 of 2)


September 2000

Building The Enterprise - An Infusion Of Honesty


July 2000

All the Reasons Why You Can't Do Architecture or ("We Has Met the Enemy and He Is Us")


May 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 2)


March 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 1)


November/December 1999 & January/February 2000

Enterprise Architecture: Issues, Ingibitors, and Incentives

July/August & September/October 1999

Packages Don't Let You Off The Hook

By John A. Zachman

January/February & March/April 1999

Life Is a Series of Trade-Offs and Change Is Accelerating!

November/December 1998

"Yes Virginia, There IS an Enterprise Architecture"

July/August 1998

Enterprise Architecture:  Looking Back and Looking Ahead

January/February 1998

The Framework for Enterprise Architecture (The 'Zachman Framework') and the Search for the Owner's View of Business Rules



 about . . .



John A. 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 for 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®.

Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO) and on the Advisory Board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2009 Enterprise Architecture Professional Lifetime Achievement Award from the Center for Advancement of the Enterprise Architecture Profession as well as the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation.  In August 2011,  he was awarded the Gen. Colin Powell Public Sector Image Award by the Armed Services Alliance Program.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has facilitated 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.

In addition to his professional activities, Mr. Zachman serves on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California), the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way, the President’s Cabinet of the King’s College University, the Board of Directors of the Los Angeles Citywide Children’s Christian Choir, the Board of Directors of Heavenworks, an international ministry to the French-speaking world and on the Board of Directors of Native Hope International, a Los Angeles-based ministry to the Native American people.

Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve. He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration"  for the U. S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Managementat Emporia State University, on the Advisory Council to the School of Library and Information Managementat Dominican University and on the Advisory Board for the Data Resource Management Programat the University of Washington. He has been a Fellow for the College of Business Administration of the University of North Texas and currently is listed in Cambridge Who’s Who.




[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]