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.