As systems problems and solutions become more complex, it is increasingly important to strengthen the connection between systems engineering and her sister disciplines. The work of each informs the others, and the solution-seeking process benefits from the consideration of all the engineering aspects inherent in the design.
The use of a systems design tool becomes critical as the complexity of the design increases. This is further exacerbated by the expanding number of engineering disciplines impacting the designs. The problem of overlapping complexities is gaining recognition as systems engineering talks more and more about “connected” (or “concurrent”) engineering. When we use the term “connected engineering” here, we mean the integration of domain expertise and multi-disciplinary engineering into the greater design processes.
In solving complex problems requiring complex solutions, we can no longer afford to treat other domains as isolated islands of expertise. They must be tightly connected to provide a two-way avenue through which specialized questions about the design can be asked and answered. The effective systems engineering tool in this environment must implement and facilitate those connections.
In an earlier post, we stated:
The ultimate test of any tool is whether or not it helps the user in the way intended at its acquisition. In other words, “Does it do what we need it to do for us?” This is certainly true for systems engineering tools. To judge their value, we must look to their performance against our needs.
The basic requirement for a robust and useful systems engineering tool is that it be capable of ingesting and storing the fundamental nature and relationships of the system elements in a construct that is useful to the designers in creating a model of the solution. That model must allow all those involved to think about and realize the best possible solution to their problem. To the extent that a tool does this, it is “good.” To the extent that it does not, it fails the test of a good tool because it does not “do what we need it to do for us.”
In the context of connected or concurrent engineering, this requires two fundamental components: a strong, proven metamodel and a robust accessible application program interface (API).
The API allows the tools and models of a variety of disciplines to connect with the systems engineering tool and inform the design as it develops. Various engineering and domain disciplines use differing tools attuned to their particular needs. Physics-based models analyze component performance and constraints while spreadsheet-based tools are used to collect requirements—there are as many variants in the tool constellation as there are uses for those tools.
While none of these specialty tools are system design tools, all of them produce information relevant to the design. By connecting to the systems engineering tool through its API, the domain tools can provide their information to the design. This maximizes the value of the tools populating the connected engineering ecosystem.
The need for this information is the product of the complexity of the design problems and solutions. The information speaks to the fundamental nature and relationships of the system elements. But it is not enough to gather the information through the API—it must be organized and integrated into the design process. The responsibility for this rests squarely on the use of a strong, proven metamodel as the foundation of the model created by the tool.
As David Long explained in his blog The Meaning is in the Metamodel, a metamodel “. . . can be considered an explicit representation of the information necessary to engineer a system. It is a framework within which the fundamental concepts and their interrelationships are defined with clear semantic meaning. (It is not enough to define the concepts in isolation.)” The metamodel provides the organization of the design-critical information about the system of interest—the real “meaning” that enables the information gathered to become useful.
The need for such a metamodel is gaining more and more recognition. Some would argue that their set of “connected” drawings amounts to a metamodel. But, metamodels are about organizing information, not representing it.
Not just any metamodel can answer the call for creating the kind of meaning needed. The successful metamodel must be grounded in systems engineering expertise and experience. It also has to be sound from the standpoint of knowledge management. And, perhaps most importantly, it must have stood the test of practical usage. In short, it must be strong and proven. Vitech’s metamodel, for example, is grounded in 50 years of practical experience coupled with insights drawn from a variety of architectural frameworks and Vitech’s engineering innovation.
In order to serve the need for connected or concurrent engineering, the truly robust tool must have a strong, proven metamodel and a robust API. This enables the tool to gather the information from the tools of other relevant domains and to organize and integrate that information into a useable framework for the design team. The tool promotes effective communication that creates a shared understanding of the problem and solution.
A strong, proven metamodel and a robust API are not all there is to an effective systems engineering tool. We have treated other characteristics of such a tool elsewhere. But the metamodel and the API are critical to the connected engineering venture. Without them, there can be no truly authoritative source of design information. Without them, the tool will not do what we need it to do for us in the context of connected engineering.
