Requirement
Motivation
Have an underlying paradigm to help building ISA is a mean to promote coherence and consistency. And this on both faces of the architecture: internal and external. In this way it is easier to follow all the previously expressed wishes and in particular the N°5 (simple and freed of experts) and N°7 (life cycle foundations and ground floor) . It also gives guidelines for choosing among solutions in particular on reuse of an existing one (wish N°8 – use existing technologies when acceptable.).
More fundamentally, relying on a paradigm, on an abstraction, on a model, gives a way of dealing with the complexity of such a wide architecture like ISA. It is a guideline to follow in elaborating the artifacts that will compose ISA.
Of course, the underlying paradigm should be carefully chosen in order to provide a large range of concepts and a deep experience in real world.
This approach is fully in accordance with the pragmaticism principle concluding the post Idealism versus Pragmatism.
Another advantage of sharing a common paradigm from the lowest layers (hardware) to the highest (abstract design), is to incorporate in the same manner the ways of doing things. Therefore, there can never be any mismatch of impedance, neither conceptual nor in concrete implementation. This is an enormous factor to optimize efficiency of a system taken in its whole, and also all together. This is a means to incorporate in low layers, even in silico, an implementation that would be much more costly in a higher layer.
Limitation
However, a paradigm can have some limitations. For instance, for a given problem, the solutions available coming from a given paradigm could all be worse that another solutions family coming from another paradigm.
More generally, it could be difficult to see beyond a way of thinking in order to imagine other possible approaches.
This limit particularly applies in the lowest layers. Thus if there is a better way of doing things outside of the choosen paradigm, and that the paradigm remain applied despite all, the bad consequences affect the entire architecture.
So it is very important to remain vigilant on that limit when implanting of low level artifacts.
Therefore, these limits could be overtaken in incorporating solutions coming from other paradigms. However, these kind of answers must be compatible with the retained main paradigm. If not, if the solution leads to break the base paradigm in a way that the coherence or consistency cannot be guaranteed, in this case do not take the jump.
Candidate paradigms
One can distinguish two kinds of paradigms in IT: artifact oriented or process oriented. For ISA, the purpose is mainly on the first type: Artifact. However, in the future, I will certainly post my opinion on the paradigms “process oriented”. There is so much to say about that…
A first list of candidate paradigms could be established applicable to ISA as a whole:
- No paradigm.
- object Oriented.
- Sets (relational).
- functional.
- Sets + functional.
- Service Oriented Architecture (soa)
They will be studied in detail in the next post, except for soa that has its own post.