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

John A.  Zachman
John A. Zachman Chief Executive Officer, Zachman International Read Author Bio || Read All Articles 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.

# # #

Standard citation for this article:

citations icon
John A. Zachman , "Conceptual, Logical, Physical: It Is Simple (Part 2)" Business Rules Journal Vol. 2, No. 3, (Mar. 2001)

About our Contributor:

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

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). He served IBM for 26 years, retiring in 1990 to devote his life to the science of Enterprise Architecture.

Mr. Zachman is the Founder and Chairman of his own education and consulting business, Zachman International®. He is also Founder of the Zachman Institute™, a nonprofit organization devoted to leveraging Zachman International's vast network of professionals and resources to offer services to small businesses and nonprofit organizations as they prepare for and experience growth.

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 (DAMAI) 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.

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 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 Management at Emporia State University, on the Advisory Council to the School of Library and Information Management at Dominican University and on the Advisory Board for the Data Resource Management Program at 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.

Read All Articles by John A. Zachman
Subscribe to the eBRJ Newsletter
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
Strategy Spectrum for Enterprise Engineering and Manufacturing
In The Spotlight
 John A. Zachman
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Ronald G. Ross

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.