All too often, even experienced systems engineers confuse the systems metamodel with the individual system model. The former provides the framework within which to build the latter. They are not the same.
The confusion is expressed in several ways. Sometimes it arises in discussing the metamodel. The metamodel might be criticized because it “doesn’t describe the operator of a particular system, detailing what she does and how she does it.” That description is appropriate in a system model—the model of a particular system of interest—but not in the system metamodel which describes the framework for creating a system model.
Even worse is the assumption that all that is necessary is the system model. The model is created ostensibly without a guiding framework. But, the metamodel is like philosophy. Having no philosophy is a philosophy. And, in reality, having no framework is, in itself, having a framework.
The lack of a guiding metamodel is a form of guidance—and a bad form at that. All of the convention, discipline and rigor of having a defined structure is removed, and the resulting model lacks its essential power to define, communicate, and give confidence.
In order to be consistently successful at modeling systems, we have to have a systems metamodel on which to build our models. This necessity is gaining recognition in the systems engineering world. That systems metamodel must be robust, declared, and proven in order to deliver maximum value to our effort.
By being robust, the systems metamodel makes our models useful
George E. P. Box is famous for having said, “All models are wrong, but some are useful.” His fuller statement elaborates on that idea by saying, “ . . . the practical question is how wrong do they have to be to not be useful.” (The quote is from his book, Empirical Model-Building and Response Surfaces, which he co-authored with Norman Draper.)
For any given model, the line between “useful” and “not useful” is drawn by its purpose. The purpose of a system model is to provide enough information that design choices can be made to arrive at a system design that will meet its purpose(s) and can be implemented. It is the discipline of the systems metamodel that ensures that the model will contain what it needs to be useful.
For example, in designing the system logic, functions (behavior) must be enabled (that is, all prior functions have completed execution), and any required triggers must be present in order for the function to execute. (Long, D. and Scott, Z., A Primer for Model-Based Systems Engineering, Vitech Corporation, 2011.) So, in order for a system model to depict a fully executable logical architecture, it must include functions and items and the relationships among them to establish the conditions for execution. Similarly, it is important to capture not only the outcome of design, but also the series of concerns, considerations, risks, and decisions that led to the design—the design journey, if you will. So we must be able to capture this information relating it to the corresponding systems aspects—both source and resolution—to understand the full context for our chosen solution.
The robust systems metamodel provides for all the element classes, relationships and attributes necessary to fully describe the system design (model) constructed in its framework. This means that the system model and its particulars rest squarely on the “useful” side of Professor Box’s “useful/not useful” line. If the system metamodel framework were inadequate (lacking in element classes, possible relationships, or attributes), the system model could not fully describe the design and would, therefore, be inadequate to its purpose.
By being declared, it makes our models communicate
Humans communicate using models as the foundation from which they speak. It is not possible for us to talk about a horse without some idea (model) of a horse on which to base our comments. With ordinary, familiar subjects like a horse, we can communicate with reasonable certainty—at least on a general level—that our communication has a common basis. This is because we share a culturally common understanding of the concept of a horse.
But, when we enter the complex world of system design, we can’t be certain that our models are constructed in a common framework that makes the aspects of the design common to all the participants (stakeholders, designers, etc.). If, on the other hand, we submit our system models to the discipline of a declared framework (systems metamodel), we can see that we are discussing the nuances of the design set in that common framework. This allows us to communicate with the assurance that we are all talking in the same contextual setting.
By being proven, it gives us confidence
So, we have a useful model that we can understand and describe to each other and our stakeholders. The remaining question is whether or not it is adequate. We have made a useful model from which we can build an implementation of the design. But, will it really work? Is the framework adequate to produce a model of a workable solution to the problem driving the need for a solution?
This is where the track record of the use of the systems metamodel to produce real-world solutions to real-world problems must be the source of our confidence. When we consider a systems metamodel, we should always consider its history of modeling success. It can look complete and perhaps even have the endorsement of knowledgeable systems engineers, but the real test is how the framework has performed in the arena of actual design. Success there can give us the confidence to proceed with its use in the context of our particular problem.
The framework and the model
The systems metamodel is the framework for the system models that will describe our design solutions. It is not the particular system model itself. The systems metamodel is common to the whole spectrum of system models produced within its framework. It includes classes of elements where a system model would be comprised of instances of those classes. It allows for a set of relationships where a system model uses those relationships. It provides for a range of attributes that the system model can assign to its elements and relationships. The systems metamodel does not describe a particular system—it describes systems models in general.
The robust systems metamodel enables us to make useful system models. The declared systems metamodel allows us to communicate with a common understanding about our system models. And the proven systems metamodel gives us the confidence of real-world successes that the system model built in its framework will be adequately described to provide an implementable solution.
