There are two ways to omit details in a model, to introduce abstraction:
- Omitting details you know exist but don’t need now (abstraction on purpose)
- Omitting details you don’t know that exist (abstraction by accident)
As you can see from the phrasing used, the second type is a dangerous kind of abstraction. If you don’t know the details you left out, you don’t know if you got the abstraction right or not.
You’ll often be in a situation where you just don’t know enough (yet) about the system to be ensure you got the abstraction right or not. In such cases, you are carrying an unknown variable with you in your design process.
That variable should eventually become (sufficiently) known. Once it does, you can revisit earlier made abstractions and verify if they were justified or not and make adjustments where applicable and required.
In any case. abstracting details away when you are not sufficiently aware of what you are abstracting away is a dangerous road to take. It’s the architectural equivalent of proving that 1 = 0 using some sneaky (but wrong) trick.
I often say that “high level makes you fall deep” meaning that if you make high level diagrams (omitting a lot of details) without being aware of the abstractions you are exposing yourself to considerable risk later on in the design and realisation phase.
Recently I heard someone make the statement that you need in describing a system using models, you need to find the proper balance between precise models and flexible models.
In this context, precise models would be models that are correct, are as complete as possiblem flexible models would be models that are less correct but are capable of conveying information to stakeholders (mostly business people).
I would dare to state that above is not correct.
The chapter on viewpoints in the ArchiMate specification, makes a distinction between three types of viewpoints (models):
Deciding Viewpoint. Models in this category are meant for people who need to make decision, decide on trade-offs. They typicall compare several alternatives based on a list of criteria.
Informing Viewpoint. Models in this category are meant for people who need to get or give information on the system. They must be adapted to whatever area of interest and level of interest the audience has.
Designing Viewpoint. Models in this category are meant for people who have to further design and build the system. These people need completeness and precision.
So back to our inital question: do we need to find a balance between precision and flexibility in models describing a system? I say: no. You need precise models and you need flexible models. It depends on what they are used for (deciding, informing, designing) and who they are intended for.
If you insist on making only one set of models, for all stakeholders and for all purposes, there is no end to the amount of damage can you do. If you find yourself deciding on ‘the right balance’ in a model, take a step back and see if you are not trying to model the system using a one-size-fits-all model.
One would assume that a speaker on a Data Management Conference got the distinction between conceptual, logical and physical right? Well … no
It’s very common to define these terms based on the level of detail they contain. There are a few things wrong with this definition:
First, it completely ignores what we know about idealization. Idealization is the idea that defines terms like conceptual, logical and physical. People familiar with the Zachman framework will recognize this.
Secondly, it’s a very ambigious defition. What if I add a small detail to a conceptual model, did it just became logical? If not, what if I add this other small detail?
These are the definitions I use, based on idealization:
Conceptual Model. A model describing a system where there is complete abstraction of any implementation with an information system.
Logical Model. A model describing a system where we don’t abstract away a realisation with an information system, meaning we have to make design choices, but we still abstract away the technology used.
Physical Model. A model where neither the fact it is implemented using a particular information system nor the technology used, is abstracted away.
You can still have ‘very detailed’ or ‘high level’ if you want, since that is ortogonal to the above. You can have a high level physical model or a very detail conceptual model.