Ask any engineer what they do, and once you drill down past the knee-jerk response of “build stuff/make stuff” to the real essence of their profession, they will tell you that they “solve problems.” The very word “engineer” is rooted in the Latin words ingenare (to create, contrive, devise) and ingenium (cleverness). To see engineers as those who devise clever solutions to problems is to have a pretty clear picture of the profession—one that is applicable across the various engineering disciplines. While the nature of the problems to be solved changes from discipline to discipline—electrical to mechanical to civil—the essential function of cleverly creating solutions remains the same.
This is just as true for systems engineers as for any other discipline. Their work simply transcends the classical disciplines to encompass problems seen at the system level. In a recent initiative of the International Council on Systems Engineering, the definition of systems engineering proposed by INCOSE Fellows emphasizes the transdisciplinary nature of systems engineering. The Fellows define systems engineering as, “a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.”
The Fellows explain their use of “transdisciplinary” as:
This emphasis on a holistic approach distinguishes it from cross-disciplinary, which focuses mainly on working across multiple disciplines while allowing each discipline to apply their own methods and approaches. Systems engineering is simultaneously cross-disciplinary and transdisciplinary. (Systems Engineering and System Definitions, Fellows Initiative on System and Systems Engineering Definitions, International Council on Systems Engineering. December, 2018.)
The significance of this definition for our purposes is as a reminder of the special nature of the systems engineering problem and the way it must be solved. The transdisciplinary nature of the problem requires that systems engineers solve the problem first in the logical domain and then allocate the problem-solving behavior onto a balanced physical architecture.
Along the journey from the logical model to the allocation to a physical architecture, the transdisciplinary approach requires the synthesis of a variety of disciplinary perspectives into a coherent system design. This synthesis is the purview of the systems engineer. It is at the systems level where the integrative approach of systems engineering draws together the disciplinary perspectives to form the complete design.
While the design incorporates the transdisciplinary perspectives, the systems engineering processes allow the various disciplines to derive their perspectives using their own methods and approaches. This preserves the integrity of the disciplines while leveraging their input to complete the model. In this way, systems engineering is simultaneously cross-disciplinary and transdisciplinary.
A further challenge for the systems engineer is the increasing complexity of the problems they are called upon to solve. They are not free to work in a merely “complicated” world where cause and effect are linear and determinant and where segments of a solution are largely decoupled. Complex physical and adaptive systems present feedback loops which produce intended and unintended effects. They have high interconnectivity and interactions between the segments of the solution. This complexity is directly reflected into the effort to solve the problem in the logical domain.
A key tool in meeting the challenge of complexity in solving transdisciplinary problems is the model. Constructed by systems engineers in the logical domain, the model can lead to an understanding of the behavior that will solve the problem while controlling or compensating for the effects on the context system. It should provide a complete picture of the behavior that can then be allocated to a balanced physical architecture to effect a system solution to the problem being solved. But to be truly effective, the system model must reflect the transdisciplinary and complex aspects of the problem and solution.
This means that the model must be constructed in an ordered, logical way. It must be able to account for all aspects of the problem and solution. That cannot happen in an ad hoc, piecemeal fashion. The organizing structure must be a systems metamodel.
The systems metamodel provides the framework within which the systems model is constructed. It provides for the interconnectivity among a variety of elements and disciplinary perspectives while preserving the structure of the integration required for a coherent system solution. As the Vitech Primer for Model-Based Systems Engineering points out, the systems model must have:
Language—The model is seen in terms of language. The system definition language (SDL) [what we now characterize as the systems metamodel] expresses and represents the model clearly, so that understanding and insight can arise. This is critical to successful system design. The system definition language must be clear and unambiguous in order to depict the model accurately and understandably.
Structure—The model must have structure. This allows the model to capture system behavior by clearly describing the relationships of the system’s entities to each other.
Argumentation—The purpose of the model is to represent the system design in such a way that the design team can demonstrate that the system accomplishes the purposes for which it is designed. Therefore the model must be capable of making the critical “argument” that the system fulfills the stakeholders’ requirements.
Presentation—Not only must the system be capable of making that argument, but it must also include some mechanism of showing or “presenting” the argument in a way that can be seen and understood.
These are provided by the systems metamodel. Without the systems metamodel, the model would lack structure and coherence. It would be incapable of providing a complete, coherent and consistent look at the reality of the solution. Any fragmentation of the model would lead to inaccuracies that would become misleading to the solution-seeking process. Without a systems metamodel, such inaccuracies are not only possible but probable.
So having a systems metamodel is critical, but not just any metamodel will do. Just as we wouldn’t buy an airplane without insisting that its design and function had been tested, we shouldn’t be satisfied with an untested system metamodel. The systems metamodel should be proven successful across many kinds of designs over years of experience. Such a track record of success provides the assurance of producing reliable and useful system models suited to the problem-solving task.
Systems engineers working in a transdisciplinary environment on designing systems solutions to complex problems need the support of complete, consistent models. Such models can only be built on the framework of a proven systems metamodel that provides the reassurance of a solid track record of experience and success. With such a tool the systems engineer can say with confidence, “What do I do? I solve problems!”
