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.

# # #