Why Separate Physical and Logical Models?

Logical Models
Knowledge is rich and sophisticated, taking many (e.g. infinite) forms. When managing it, and the real-life problems and issues it addresses, we naturally first consider logical models, often also referred to as business models or even as real-world models. Logical models correspond to what we are trying to manage. They reflect what we see (e.g. know) about problems, their symptoms and manifestations. Logical models are problem models, directly mapping the various problem or issue aspects.

Physical Models
As we program systems and applications to manage the knowledge and problem issues expressed in logical models, the first approach often seems to define corresponding data and computing structures (e.g. physical models) that also directly map the logical or business models.

While today's systems and programming environments can process physical models that are direct mappings of logical models, the added abstractions of separating logical and physical models introduce many additional benefits. Just like minds process all knowledge and thinking as neural patterns that map reality and issues, computing network graphs that articulate knowledge, problems, and issues can provide great efficiency and many advantages. In fact, network graphs are the closest thing that computers can have that resemble the mind's neural patterns.

But why and how would this additional abstraction step be truly justified? Why not just let systems manage our logical business models directly, especially as, today, computing resources are more and more readily available?

Comments and suggestions are greatly appreciated. There are surely many answers and reasons, including these few, maybe:

  • Flexibility: Decoupling physical and logical models, allows them to evolve separately, each optimized for their specific respective purposes, without impacting the other. More specifically, for example, business (e.g. logical) models can be refined and developed without having to change existing applications based on the corresponding physical models. In the same way, physical models and associated applications can be optimized for processing and exchange, without disrupting corresponding business models. A great side effect of this flexibility is linear, rather than exponential, complexity growth: as business models get more complex, the impacts on applications can be staggering and grow on an exponential curve, but has separated physical models are designed to more efficiently support logical model variations and enhancements, the complexity growth of physical models, and the associated applications can be kept under the linear growth curve
  • Generalization: Physical models can be designed to support many, possibly concurrent, variations of related business processes (e.g. logical models), without change. The applications can then be generalized to manage more cases, without increasing their complexity, or even changing them in any way
  • Compatibility: Through the associated generalization, more applications and more data models can be made compatible, as they share the same physical models, further fostering the development of more applications, as well as of standards, which can also bring even more compatibility, as well as the associated exchange, sharing, and collaboration productivity
  • Efficiency: As physical models are optimized for computing, without compromising logical and business models, processing efficiency is improved, adding to, and even factoring flexibility, generalization, and compatibility advantages

Separating logical and physical models is not a compromise for systems and computers. Rather, it is a more efficient way to consider and manage issues and the associated knowledge. It also seriously benefits systems and applications, just has managing knowledge benefits from the minds abstractions to neural patterns.

Continue to