Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...

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

by John A. Zachman

I don't know why everybody has so much trouble figuring out the difference between Conceptual, Logical, and Physical. Let me explain this one more time ...

  • The "Owner": CONCEPTUALLY .... "I would like a pot of flowers in the center of my patio about 10 feet off the ground. They would be purely for ascetic reasons, but I want the pot to be BIG and the flowers to be real."
  • The "Designer": "Hmmmm. Let me see now ... the physics of this situation would suggest that there are two LOGICAL alternatives ... either 1) you would have to have a pedestal about 10 feet high, the weight it would have to sustain is max of 100 pounds so if it was 10 square inches in area (cross-section) the material would have to hold 10 lb. per sq. inch. You're second alternative 2) would be to hang it from something above the pot ... do you have a roof over the patio?? If not, that would mean we would have to construct a tripod to suspend the pot from the apex. Do you care if you see the tripod? Hmmmm. I recommend you go with the pedestal."
  • The "Builder:" "Hmmmm ... the Architect is suggesting a pedestal that would be 10 feet high and sustain 10 pounds per square inch. That Architect wouldn't recognize a lathe if he fell on one ... but here's what we could do ... we could PHYSICALLY build the thing in three pieces and then glue it together with superglue ... just in case, we could make flanges on the pieces so we could bolt the pieces together to make sure they don't come apart. Your other alternative is to have it made in Japan and ship it in one piece and then we could install it by drilling a hole in the patio, sinking the base down 2 feet and filling in the hole with cement."

Conceptual ... Logical ... Physical.... Anyone in manufacturing or construction would recognize the Owner's requirements, the Engineer's design, and the Manufacturing Engineer's design ... conceptually what you are trying to produce ... logically how it would be designed ... and physically how you intend to build it.

The information people's problem is, we start at Row 3 and look downwards and we think that Row 3 is Row 2, that "entities" are "Things" ... and then we can't figure out what Row 3 is. Actually, Row 3 is Row 3 ... "entities" are logical representations of Business "Things," not the Business Things themselves.

Then the problem is, we never figure out what Row 2 actually is. We start with Row 3. We think that Row 3 is "Requirements" when actually, we never define "Requirements" from an Enterprise Perspective. We are starting with "Engineering" (logical) design and calling it "Requirements." Probably, that is because we are SYSTEMS (Row 3) people, not BUSINESS (Row 2) people.

Row 2 models are the models of the actual business as the Owner conceptually thinks the business is (or, maybe, wants the business to be).

Row 3 models are the models of the "systems" of the Business -- logical representations of the Business that define the logical implementation of the Business. There are a bunch of "systems." There is the marketing system, the manufacturing system, the distribution system, the management system, the accounting system, the planning system, engineering system, the inventory management system, the check processing system, the personnel system, the management development system, the legal system, the library system, and so on, and so on ............ and the information system.

Why the Logical Models are so Important

There are two reasons why the logical models (Row 3) are so important to the Enterprise.

First, you can't design something (Enterprise included) using the actual material components of the product (Enterprise). For example, you don't design a hundred story building by trial and error, starting with logs, I-beams, steel cables, a tank of plastic, and some welding rods.

No. You start with the logical representation of all of those things on a piece of paper -- the Engineering Drawings, etc. That's the only way you will be able to think through the detail and make sure the laws of physics are obeyed before you actually start constructing the pieces. It is a LOT cheaper to try everything out on paper before you try to fit the actual materials together by trial and error!

From an Enterprise point of view, you wouldn't start with a warehouse full of Raw Materials, an office building full of people, and a distribution center full of finished Products and try to form them into a coherent Enterprise.

No. You would start with the logical representations of these things and sketch out how it would work in fact on paper. It would be a LOT cheaper that way!

Of course, if you already have an Enterprise that does not have any models and then want to change it, you would have to reverse engineer the models out of the implemented Enterprise so you could then re-engineer it into something coherent. It would still be a lot cheaper (and faster) to reverse engineer the models than to try to change it physically by trial and error -- especially if it is large and complex and if the changes are coming faster than you can get them assimilated and you don't have a lot of time to recover from any mistakes!

If you were defining Logical Models only for that portion of the Enterprise that deals with the actual material transformations of the things of the Enterprise (for example, the transformation of raw material into finished goods, or the manipulation and storage of the actual paper orders received, or the handling of cancelled checks, etc.), the resultant models would be the engineering for the "blue collar" systems of the business.

However, a second reason you need the Logical Models is because when the business grows so big that management is no longer able to physically maintain contact with the "Things" of the business, they will have to create data "surrogates" of those things in order to manage the Things. For example, when the business grows so big that management no longer has physical contact with the products that are being produced, they will have to create a data "surrogate"(a "white collar" system) for the products so they can keep track of the products and know what is present and what is absent. That is, if the Enterprise gets so big and so complicated that when they want to know how many products are ready for shipment, they don't have go out and physically look for the products -- counting them by sight and then deciding what to do.

No. They access their "information system" (the "white collar" system -- manual or automated) of data "surrogates" that parallels (or maybe, "mirrors") the physical system that tells them how many products are ready for shipment ... no physical inventory required. That's the only way they could realistically manage a large Enterprise that has lots of Things, scattered all over the place. However ... when the information system doesn't "align" with the "real" Enterprise, physical system (that is, when it doesn't accurately represent what is really happening), Management will tend to get really upset!!!

I suspect that the "blue collar" system (the actual physical, material "Things" of the Enterprise) and the "white collar" system (the data surrogates for the physical, material "Things" of the Enterprise), at the logical level, are actually one and the same system, based on the logical "DATA SURROGATES" for the actual Enterprise "Things."

In fact, maybe, not only do the data surrogates mirror the physical Things of the Enterprise, but the information processes (Col. 2) are the "mirror" of the material transformations. Maybe the logical distribution of data surrogates and process surrogates (Col 3) mirror the distribution of the material Things and transformations (Processes). Maybe the Work Flow of the "White Collar" system mirrors the Work Flow of the physical material. Maybe the logical system cycles mirror the material cycles. Maybe the systems "constraints" mirror the Enterprise motivation. That is, logically, at Row 3, the Blue and White Collar systems may actually be one and the same.

Then, Row 4 is the technology-constrained, physical implementation design of the systems of the business. This is where the systems specialize. If the technology is lathes, robots, material handling equipment, optical check sorters, etc., etc., then the resultant system is going to be a "blue collar," actual material manipulation system. If the technology is pencils, paper, and file cabinets, then the resultant system is going to be a "manual" system (probably a manual, "white collar" system). If the technology is stored programming devices and electronic media, then the resultant system is going to be an automated (probably, "white collar," information) system.

All of these systems designs would be derived from the same logical model, the heart of which is the logical representations of the "Things of the Enterprise." That is, there could be more than one physical implementation for the same logical model ... but the physical implementations would have to be kept in synch or every time management needed to know something, they would have to go out and take inventory or physically sight things. (Once again, if the "systems" are not aligned with the Enterprise reality, the probability is that management is going to get really frustrated!)

Column 1 -- Think "Things"!

For Column 1, I am confident that the Row 2 model is a model of the THINGS of the Enterprise -- think "THINGS"! Do not think "entities" or "objects" or "information areas" or even "terms" ... but "THINGS." Call them what you want, but you'd better think "Things" or you are going to get confused!!

"Things," -- those are what the Enterprise Owners care about CONCEPTUALLY. (Actually, you probably should call them "Things" as well as thinking "Things" so nobody gets confused, including the "Owners," but especially, WE!)

As an aside, they (the Owners) will care about "intersection Things" in the Conceptual Model as well as the actual "Things." In fact, where there is an intersection, they will typically create a piece of paper that records the intersection and then put a serial number on that piece of paper (intersection) and keep an inventory of the pieces of paper ... that is, it becomes an Enterprise "Thing" in its own right. (I have recently seen an Enterprise where management did not create such an intersection "Thing" and, as a result, they couldn't manage that aspect of their Enterprise. It was only when they saw the Column 1, Row 2 "Semantic Model" (the Conceptual Model of the Enterprise "Things") that they discovered what the problem was -- a missing intersection "Thing."

For Row 3, think "logical representations" of Enterprise "Things." Now we are into "entities" or "objects," etc. This model would be a LOGICAL Data Model ... fully normalized ... the basis for the filing system that records information about the actual "Things" so management can keep track of them without having to physically sight them -- the basis for the "white collar" information system.

Probably, this Logical Data Model is also the basis for engineering the "blue collar" aspects of the Enterprise as well as the "white collar" aspects, because the "entities" in the model are the logical representations, the surrogates of the actual Enterprise "Things." That is what you would need in order to "Engineer" the Enterprise logically ... not the actual things, but a paper (logical) representation so you can think through all of the physics issues to make sure it will work when you get it implemented.

Then, Row 4 would be the physical storage design ... how (depending on what storage device, file cabinet or storage bin) are you going arrange the storage of the "Things" so you can find the Thing (the data surrogate or actual "Thing") again when you need it? (Which device, in which location it goes on is a Column 3 issue). In a relational implementation, the Row 4 Model would be the table structure with the keys, foreign keys, and so on -- the "Data Design," or "PHYSICAL Data model."

Conceptual, Logical, Physical ... Row 2, Row 3, Row 4. Simple -- in an absolute sense, simple.

 


Having discussed the ideas of "Conceptual, Logical and Physical" from the perspective of the Enterprise, in my next article I will speculate why these words are so confusing and misunderstood by those of us who come from the Information community.

...to be continued

Copyright, 2000. Zachman International.

January 2017
The Issue Is THE ENTERPRISE
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

 

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 ]