Again, I am not a database expert. The Wikipedia page on data modeling describes the three levels above, so I’m proceeding from their definitions, which are roughly:

1. Conceptual model: Things in the domain and their relationships.
2. Logical model: A database schema, where we would commit to tables and data formats.
3. Physical model: The embodiment of a logical database, with commitments to things like row ordering and geographical location of the data (eg redundancy).

I’m not sure I completely understand the set of commitments made in the logical model vs. physical model, because the parent post says that commitments to varchar vs. string(20) would not be made in the logical model. Or perhaps the definition of logical model varies.

We build models for a purpose. It is not fair to build a model for one purpose and judge it by its suitability to another purpose. If I build an architecture model to design a secure, fast system then the model might stink for helping be build a modifiable system or a testable system.

In my experience, I have always used a conceptual model when building an architecture model. Depending on the specific quality attribute needs of the architecture, either or both of the logical or physical models could be helpful. On most IT projects I would suggest that you avoid making specific data representation commitments, like the varchar vs. char(20) commitments. However, if this were an app for an embedded device with limited storage, such commitments would be pretty important, so I would include them.

In a way, I think our desire to have a single, easy to understand definition for “architecture” is leading us in the wrong direction. If we asked a related question like “What models would be helpful to for designing a system to do X?” then I think we would realize that the answer is “It depends on what X is”. There is increasing consensus that architecture is more about quality attributes (latency, security, usability, deployability, …) than it is about functionality. It’s not that functionality isn’t important, but that I could build a 3-tier system or a monolithic system or a peer-to-peer system or a SOA system that all achieved the same functions, but had quite different quality attributes. If you tell me what quality attributes the system should have, it’s easier to decide what models to build, i.e., what parts of data modeling to include in its architecture.

Regards,

-George