|
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.
Reality
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.
Abstracting
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?
Reasons
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
Benefits
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
|
