In the systems engineering world we talk extensively about models. For those discussions, we adopt the aspects of the conventional definition of the word “model.” Although the specific wording of the definitions may vary, models are “representations” of existing or proposed realities.
Many representations technically meet the definitions of models. Pictures are representations, mathematical models are representations, physical constructs are representations . . . the list is expansive.
This leads to confusion. From the point of view of utility, a model is judged by how well it incorporates the aspects of the reality of depicts that are relevant to its purpose. A police sketch is a “good” model to the extent that it provides a recognizable portrait of a suspect. By calling such a broad range of representations “models” in our systems engineering discourse, we confuse very limited models and relatively complete models in terms of their utility.
This leads us to truncate our pursuit of a systems design model that embodies all aspects that are necessary to the specification of its design. We are satisfied with less than the maximum level of utility in our systems model because we “model” the design using a number of representations, all of which we call “models” of the system.
We say several things which grow out of the loose way we define the term model. The first is that it is possible to have a complete representation of the system design by aggregating a number of representations. Another is that it is impossible to create a single model that represents the entirety of what is necessary to specify a system design for implementation. Both of these are counter-productive for our efforts.
It may be difficult to use a single model to incorporate all of the necessary system specifications into a model that embodies the relationships of those specifications but it certainly isn’t impossible. By calling it impossible we effectively surrender our efforts to achieve that end. That does not serve us.
We also become satisfied with a number of models among and between which we port information in an effort to replicate the relationships between the aspects of the system design. This satisfaction comes tied to a risk. That risk is that we will lose information or misrepresent and/or break the relationships.
In support of the view that building a single model is impossible, we cite the complexity of many of our designs. We posit that this complexity makes it impossible to create the single model. However, it is that complexity that makes a single model more important than ever. The risk of mangling or losing relationships increases with complexity and it is the single model that provides the best defense against that risk.
Not only is it possible to build such a model, it has largely been done. The main body of the system specification is incorporated in single tool, single repository models like those developed using CORE. It isn’t necessary to surrender our quest to develop such models on the mistaken belief that it is an impossible dream.
What is needed is a language that encourages us to believe in the possibility of such models. Perhaps we can refer to limited purpose models as models but reserve the term “system model” for the larger representation. It would also to be helpful to refer to documentary or graphic representations as “views.”
The system model would contain all the information about entities and relationships. Views would become the “answers” to queries delivered in conformity with the conventions for those views. Specialized models (like domain-specific simulations) would draw their basis from the system model and feed the relevant results back to it. The idea would be that we could put an end to the practice of thinking about a design, as composed of the sum of separate representations, in favor of an integrated model.
Rather than talking about a logical model, a physical model, a simulation, or testing model of our design, we could begin to think in terms of an integrated model which embodies and incorporates these aspects of the design. That would be a better approach. Realizing it in a complex world calls for a better language.
