There are a number of efforts afoot to come up with a systems metamodel for model-based systems engineering. The necessity for such a metamodel is gaining recognition in the system design world. At its heart, a systems metamodel is a map for guiding system designers from what we know to what we don’t. It is the framework into which we lay our information about the system under examination, revealing where we need additional clarity in order to fully understand that system and its ability to meet our needs. The systems metamodel shines a light on the adequacy of our knowledge of a given system and points us to what we need to know.
The systems metamodel is known by a variety of names. Some refer to it as an ontology, others as a schema. But whatever we may call it, the systems metamodel is a critical enabler for defining and describing a system.
The source
While most of the systems metamodel efforts are seeking to construct or define the framework within which to norm the models that are to be built there, there is a better way than invention for establishing the systems metamodel. Systems, particularly complex systems, exist naturally and are structured on a framework that is common to all of them. By deriving the systems metamodel framework from this naturally occurring structure, systems designers can draw on the power of a proven framework.
The existence of a natural framework can easily be illustrated by looking at rational human behavior. (NOTE: Since we are looking for a framework for designed systems, we will look to intentionally designed or rational behavior, leaving aside for the moment the effects of pathology, inattention, or weakness that may lead to irrational behavior that disrupts the framework.)
Real-world example
We have all heard it said that if we want to understand what a person’s real values are we should look not to her articulation of those values but to her checkbook and calendar. In other words, our application of our resources through our behavior is driven by what we value. Further, our behavior is made possible by the way we create the mechanisms to aid us in performing it. We construct our lives to facilitate the behavior that brings our values to reality.
Our lives are a system driven by our values, realized by our behavior and performed by the mechanisms we create or employ to perform that behavior. For example, if I am committed to obtaining a Ph.D., I will obtain the necessary funding by creating a mechanism or mechanisms to do that. I may get a higher-paying job, use an inheritance, cash in my 401K or adopt some other mechanism so that I can pay my tuition. The value (get a Ph.D.) drives my behavior (pay the necessary tuition) using the mechanism (a higher paying job etc.).
The framework for this system is that the values drive the behavior which is performed by the mechanism. This describes how systems work. They are configured to behave in a way or ways that will achieve their purpose.
Systems metamodel foundation
If we change the nomenclature for values to “requirements,” and mechanisms become “components,” we have a simple foundation for a systems metamodel. Requirements are the basis of behavior which is allocated to the components to be performed by them. Viewed in reverse, components perform behavior which is based on the requirements. This can be illustrated simply as in Fig. 1.
Fig. 1
This fundamental picture is the foundation of a systems metamodel that can be applied to any intentionally designed system where the system purpose is defined by a set of requirements that express the needs that drive the creation of the system. Using the systems metamodel to frame the design thinking, behavior can then be specified to satisfy the requirements, and a structure of components can be created to perform the behavior. If the requirements are right-—the subject of a validation process—and the components perform behavior which actually satisfies the requirements—demonstrated by a verification process—the designers can be assured that their system will meet the needs that are driving its creation.
Adding nuance
Designing “real” systems in a complex and evolving world demands a more nuanced systems metamodel to account for their more detailed construction. Such a framework can and does exist without losing its fundamental grounding as a positive description of real-world systems structure. (See Fig. 2.)
Fig. 2
Note that the fundamental structure of requirements (top), behavior (“function”- right) and components (left) remains intact and is simply elaborated to cover the needed nuance.
Real world grounding
The advantage here is that this systems metamodel is derived from reality and already exists. It does not require development or “inventing.” It is a positive rather than a normative statement of system structure. That is, it isn’t an artificially created description that is set up as a standard or mold into which system models must fit. It is rather a description of the system framework derived from reality to be used as a guide for modeling systems that work in real-world applications.
It is here!
Not only is this systems metamodel grounded in reality, but the nuanced version depicted in Fig. 2 has also been proven over and over again in practical application across more than 50 years. This is the systems metamodel that has been in use at Vitech for decades. It has framed the design of successful systems in contexts ranging from property and casualty insurance processes to missiles and airplanes to intelligence gathering and reporting. It is the foundation of the Vitech tools CORE and GENESYS. In the face of a grounded, proven systems metamodel, there is no need to reinvent what is already working. There is certainly no need to wait for its appearance on an uncertain timeline. It is here today and here to stay.
A few things seem to be missing:
– Desires come before requirements. Requirements are not given by the user directly. They emerge as part of the early system development. The stakeholders provide desires, but usually cannot articulate requirements until some system modeling as been done to provide information of about Performance, Effectiveness, Risk, Cost and Schedule, PERCS. Many system developments fail due to ill conceived requirements. NASP comes to mind.
– A system meta model should explicitly identify all stakeholders, what they do, how they do it and with what tools. Stakeholders are part of the system. Stakeholders, controllers and users, who ultimately control the development and usage of the system, should be explicitly identified. They manage, effect, control and manipulate the many components of system. They do this using software, tools and resources. Controllers and users of the system need to be trained to support the system.
– A system meta model should encompass risk quantification. Systematic risk reduction should direct system development. Risk can be defined as a product of uncertainty and sensitivity of various key performance parameters.
There are other issues but these are the first that come to mind.
John-
Thanks for taking the time to engage. You are clearly familiar with the world of system models and your observations are well stated.
Perhaps I have not been clear enough but there seems to be confusion over some basic concepts. The first, and perhaps the largest, concerns the difference between the systems metamodel and a system model.
As I pointed out in the blog, “At its heart, a systems metamodel is a map for guiding system designers from what we know to what we don’t. It is the framework into which we lay our information about the system under examination, revealing where we need additional clarity in order to fully understand that system and its ability to meet our needs.” The word metamodel uses the Greek word meta that has come to mean beyond or about. Literally the metamodel is a model “about” models in the same way that metacognition is thinking “about” thinking.
The systems metamodel addresses what elements and relationships are possible in the models developed within its framework. So, there is a class called “Requirements” in a systems metamodel but there are no specific instances of requirements. The instances of the class “Requirements” would be elements of a system model NOT a part of a systems metamodel.
So, when you say, “A system meta model should encompass risk quantification” you are blurring the difference between metamodel and model, between the framework and the contents. Risk is an important part of any design. So the systems metamodel contains a class for Risks and a class for Concerns. But a systems metamodel does not contain specific risks or concerns related to a particular design. That would be a part of a model.
(NOTE: It is beyond the scope of this blog entry to identify the content of the systems metamodel or its detailed structure. The point here is that should exist and having a systems metamodel that is grounded in the way in which systems are actually structured is an indicia of its strength.)
When you suggest that, “A system meta model should explicitly identify all stakeholders, what they do, how they do it and with what tools” you are confusing the metamodel or framework for building the model with the model itself. Arguably, depending on the boundary of the system being modeled, stakeholders, their functions and tools might be some of the elements that make up the model but they are not a part of the systems metamodel.
That brings us to a second source of confusion. Establishing the borders of a system design is a critical undertaking. Some stakeholders (e.g- users) may be inside the boundary of the design while others (e.g.- stockholders of the company paying for the system development) may be outside. It depends on how you draw the boundary. Some stakeholder (users, controllers- to borrow your language) may well be part of the operation of the system and at the same time be beyond the control of the designer. Otherwise, would we have planes designed so that they are crashed due to pilot error? Other stakeholders- like the aforementioned stockholders- may be clearly outside the boundary of the system of interest.)
You have suggested that “Desires come before requirements. Requirements are not given by the user directly. They emerge as part of the early system development. The stakeholders provide desires, but usually cannot articulate requirements until some system modeling as been done to provide information of about Performance, Effectiveness, Risk, Cost and Schedule, PERCS. Many system developments fail due to ill conceived requirements.” This is true as far as it goes. The Systems Engineering Body of Knowledge (SEBoK) states it this way, “Stakeholder needs are transformed into a defined set of Stakeholder Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.” The transformation of needs into requirements statements is definitely a critical part of developing the system model.
But, the discussion here was not for the purpose of providing a nuanced discussion of the process of deriving requirements in an iterative system design. It was to suggest that a systems metamodel in which the values (desires) expressed as requirements drive the design behavior reflects the actual structure of intentionally-crafted behavior (like saving money for an education) and this reflection helps to validate the metamodel.
Fundamentally, the point of this blog is to underscore the importance of having a systems metamodel to structure our models and the advantage of having one that is grounded in reality and experience. It is not about what is or should be part of such a metamodel or what is involved in building a model using the systems metamodel. Those may well be subjects for another day.
Again, thank you for your response and let me know if I can help in any way.
Zane