Whenever I visit an organization engaged in systems engineering, the #1 challenge is always the same. Large or small, seasoned or new, government or commercial, the complaint is always the shortage of good systems engineers. The common refrain is “we don’t have enough, and many of the ones we have are retiring.” As organizations embrace model-based systems engineering, the problem worsens with a limited pool of model-based talent in high demand around the globe. As a profession, how do we better develop the next generation of systems engineers? Surprisingly enough, the answer lies in MBSE—but not in the way most people think.
Systems engineering is vast. The breadth of processes, methods, and tools required to engineer a system can be daunting as we think of the many aspects from first statement of need through architecture, design, production, operation, maintenance, upgrade, and ultimately retirement. When considering the processes described in the INCOSE Systems Engineering Handbook, the 36 competencies reflected in the INCOSE Competency Framework, and The Paradoxical Mindset of Systems Engineers: Uncommon Minds, Skills, and Careers, it’s no surprise that systems engineers are in short supply. But the problem is far greater than simply the volume and breadth of knowledge and experience required to become a good systems engineer. The problem is in the interconnections. That is both where we often fall short and the pointer to our future success.
Systems are about holism and interactions. In engineering systems, we are taught to see the big picture. In fact, part of the paradoxical mindset of systems engineers is the ability to simultaneously see the big picture and the detail, enabling the systems engineer to understand the impacts of local design on global system performance. In systems, it is the interactions that yield emergence, and it is the interactions that make the whole greater than the sum of the parts. The same is true in systems engineering as we think of the interactions among a diverse team studying problem and solution from multiple perspectives.
When we fall short in developing future systems engineers, it is often because we fail to honor the systems part of the systems engineering practice. We teach the parts of systems engineering—the library of processes, the diverse methods, and the many tools. But we fail to effectively establish the framework of the big picture and interactions which bind together processes, methods, and tools equipping the practitioner to effectively elicit, analyze, and manage the information necessary to successfully engineer a system. When we succeed, we embrace the mindset, holism, and interrelationships which govern not only the systems we engineer but also the approach and practices we use to engineer them.
So how is MBSE the answer? It’s important to note that not all MBSE training is created equal. Not all MBSE training is the answer. Many courses and approaches fall into the same trap of disconnectedness teaching MBSE as a specific collection of diagrams. Some may teach a methodology to step from one diagram to the next, but the result is largely the same. The new practitioner has a library of notations and representations at his fingertips but lacks the holistic understanding of interrelationships between representations, between the processes they support, and most importantly between the information itself.
Whether process or representation, anything taught as a collection of disjoint pieces makes the challenge worse, not better. This is certainly true of the way some have chosen to teach and implement MBSE. Far too many have been misled into believing that knowledge of notation translates to a command of systems engineering. This is a myth we cannot tolerate.
Instead, the answer lies in the information that underpins the practice of systems engineering. The answer lies in acknowledging and embracing the interrelationships among the data. The answer lies in the holistic information framework that binds together process, method, tool, and the multitude of representations we need as we move from understanding the problem to architecting and implementing the solution.
Whether I am teaching systems engineering or MBSE, a short workshop or a full course, it is the systems metamodel that binds the systems engineering practice together into a consistent, coherent, and understandable package. It is the systems metamodel that increases comprehension and lowers the barrier to entry for the student. Most believe that introducing MBSE makes things more complex, and it does if one focuses on diagrams and notations.
If one emphasizes the essential systems metamodel instead, there is a clear organizing framework upon which processes, methods, tools, and representations can hang. It is the systems metamodel in the language of the systems engineer that expresses how requirements, behavior, physical architecture, analytics, and test interrelate. It is the metamodel—specifically the interconnections and interactions between key systems engineering concepts—that provides a map for practitioners, allowing them to confidently move from what they know to what they don’t. It is the metamodel that provides a way to model the complexity of the system interrelationships. It is the metamodel that simultaneously provides a big-picture view and detailed interactions for the practice of systems engineering.
Take, for example, the concepts that bind together behavior and physical architecture when characterizing a system. A system is (it has a physical manifestation, even if that manifestation is in software) and a system does (it performs some action). One could describe the identification of functions, the definition of items (data, mass, and energy transferred between functions), and the composition of functions and items into a meaningful behavioral architecture.
One could then describe the physical architecture reflecting the composition and interconnection of subsystems and components which comprise the system of interest.
Finally, one could talk of the mapping of behavioral onto physical to fully characterize the interwoven web that represents what “a system is and a system does”. For an experienced practitioner, this process becomes second nature with practice. For those learning systems engineering, confusion and overload set in long before they get to the point of understanding the interrelationships and interconnections required to specify a consistent solution. They simply see many pieces, many parts, but not the big picture. Changing from documents to diagrams and describing how to move from diagram to diagram does not help. In fact, it often further complicates the situation by adding new notations alongside new concepts in a disjoint mess.
Instead, what if we begin with a picture of how the concepts interrelate? We still have to understand what a function is, what an item is, and what it means for a function to input, output, or be triggered by an item. We must still understand that physical architecture reflects the concepts of composition and connection. But now we have an explicit, shared map of how the information relates—the big picture we are seeking and the gap each piece of information fills. We understand how in allocating functions to components we implicitly define our internal interfaces due to the items being exchanged. We understand how changing one aspect (perhaps choosing to redefine a physical interface) can lead us to reconsider another (in this case the details of our behavioral solution). And we see how various processes come together to help elicit, analyze, and manage the vast amounts of information required to coherently and consistently define both the behavioral and physical dimensions of a system.
Simplified Engineering Schema
When INCOSE launched its 2014 strategic objective to “accelerate the transformation of systems engineering to a model-based discipline”, most focused on “model-based”. The promise of MBSE is not simply in the transformation of systems engineering to a digital practice. The critical word in fact is “discipline”. Computers deal best with explicit information, and the same is true for humans. Advancing the explicitness required for computing forces us to make clear the implicit concepts and interrelationships we use in engineering systems. As we then engage multidisciplinary teams to analyze and address systems challenges, the same explicitness of concept and interrelationship which powers digital approaches underpins shared understanding within the team. The promise of MBSE is the maturation of our practice as we move from implicit to explicit understanding of the information required to engineer a system. The promise of MBSE is enterprise alignment built upon a shared systems metamodel that helps us connect not only our tools but our processes, practitioners, and organizations. That same promise is the key to developing our future systems engineering workforce.
Often the greatest problems are those problems we accidentally introduce ourselves. In many cases, we have overcomplicated systems engineering training and education by emphasizing the part in the absence of the whole. In seeking to simplify systems engineering for the new practitioner, we cannot become simplistic. Nor can we violate the fundamental principles of systems engineering by tearing apart the interconnections and interactions that define both our systems and our practice. As we look to developing the systems engineering workforce required to address the challenges of today and tomorrow, we must avoid these well-intentioned traps. We cannot errantly focus on disjoint processes or diagrams and succeed in teaching holism. Taking this approach fails our future workforce and our organizations. Taking this approach undermines our systems engineering practice and our profession.
If we want to successfully develop the next-generation systems engineer, we must paint the big picture. . . provide a map and a framework. A good systems metamodel lowers the barrier to entry, highlights the critical concepts of systems engineering, and makes explicit the interrelationships necessary to successfully engineer a system. A good, explicit systems metamodel is the foundation upon which the systems engineering practice and our future systems engineering workforce must be built. It is time we stop accepting anything less.
