By David Long, Vitech President
Over the past six weeks, I have had the pleasure of participating in a wide range of systems engineering forums, workshops, and conferences in multiple regions and across diverse domains. I continue to be impressed by the energy and passion that permeates these events and all those engaged in moving systems engineering forward toward a model-based discipline. At the same time, I am disappointed by some of the continued missteps I see. These easily avoidable mistakes drain energy and continue to slow our progress toward the ultimate goal of moving the practice and profession of systems engineering forward. If we can relegate these challenges to the past, we can certainly accelerate our progress.
Failing to Define Our Terms
In presentation after presentation and event after event, I watch practitioners talk right past one another. In some cases, they appear to be in strong agreement though in reality they are highlighting different concepts and concerns. In other cases, they argue vehemently but aren’t necessarily in conflict. The fundamental issue is a failure to clearly define their terms.
As noted in “Time to Drop MBSE?”, the meaning of model is extremely broad, particularly in engineering. Documents and diagrams satisfy the general definition of model. Descriptive architectural models and analytical models are both valid systems models. So often we assume that when we use the term “model” in the context of MBSE, we are talking about the same thing. From listening to many presentations and watching countless dialogs, I can assure you that we are not.
At this point, there is no way that we are going to stop and unambiguously define “model” as part of our journey to MBSE. That would divert tremendous amounts of energy for little, if any, progress. At the same time, we cannot afford the continued miscommunication. How do we handle the impasse? Simply by being a little more verbose. Rather than using the shorthand but ambiguous “model,” let’s be clear what we mean by model. Are we talking about a single diagram, an integrated descriptive architectural representation, a high fidelity analytical representation, or something else? Once offered, let’s not pause to debate whether what someone chooses as their model matches our definition (hence inciting a dogmatic discussion). Instead, let’s use their definition to better understand the concept they frame and hold value-added discussions rather than continuing to talk past one another. It is only via discussion and shared experiences that we can move the community and the practice forward collectively.
Framing Modeling as a Separate Practice
Modeling and simulation is different than MBSE. It is extremely valuable in bringing rigor to both design and test activities, may be part of MBSE, but is not MBSE per se. For me, modeling and simulation is models in systems engineering, not model-based systems engineering.
That clarification aside, there are those positioning MBSE as a distinct discipline from systems engineering. This can be framed in many different ways but is generally positioned as MBSE requiring modelers separate from systems engineers. Note that the individuals are not advocating for modeling and simulation (which I agree is different), but instead allocating the task of developing and capturing the descriptive architecture to someone other than systems engineers. The rationale for this allocation is rarely stated, but when it is, the rationale is either systems engineering attitudes or tool complexity.
Models are inherent to the way engineers think, reason, and communicate – and that includes systems engineers. If we are experiencing adoption problems due to culture or attitudes, we need to address these issues – via training, reverse mentoring, team composition, or other approaches to workforce development. If we are seeing challenges because of the complexity of a chosen process, method, or tool, we need to assess the validity of the particular approach, possibly changing the approach or tool if the one selected is not yielding the desired results. However, segregating systems engineering into two classifications – the engineers and the modelers – separates the engineer from the fundamental representation of knowledge. At best this makes the model a data capture exercise (a poor percentage of its true capability). At worst, this cripples the systems engineering practice as the expert practitioner cannot effectively bring their insight and experience to bear.
Reinventing the Wheel
Countless times over the past six weeks I have heard a presenter proudly proclaim “for the first time ever, we have been able to accomplish X.” In stating this, the presenter is not talking about incorporating a new practice within the organization. Instead, they are announcing a fundamental first in the industry. To the broader audience, it must feel like the organization and the practice are truly moving forward. Sadly, in many cases we are simply stuck in place, perhaps even moving backward.
Each time I have heard this – whether proclaimed by a young acolyte or a seasoned practitioner – I can point to others in the systems profession who have done it many years before and have well instantiated this particular “advance” within their organizational practice. To be fair, I have multiple advantages. In my time as INCOSE President, many organizations shared their challenges and approaches with me. In my time with Vitech, I have had the pleasure of working with countless organizations at many different levels of proficiency. However, it is not these advantages that have clued me into these practices. Instead, I have simply had to listen to industry discussions, watch industry presentations, or do a basic literature search.
Without a doubt, systems engineering as a profession restricts sharing across organizational boundaries. In large part, organizations limit the sharing of their practices and certainly of their mistakes. However, there are many papers published by practitioners and case studies developed by trusted members of academia. Before investing time and energy in a “novel concept,” we should investigate what has already been done and published – by vendors, by practitioners, and by researchers. If it suits our purposes, we should adopt it and get on with the engineering task at hand rather than reinventing the wheel. If it doesn’t fit our specific needs, we should learn what we can and then build upon this foundation, referencing back so that others can understand the gap and find their path forward. What we cannot afford to do is to continue to deny past progress, whether out of ignorance or simply “not invented here” mentalities. To do so inhibits the greater systems engineering community as we invest more and more resources to making the same “progress” time and time again.
Making MBSE More Complex than It Needs to Be
In our zeal to frame all that is possible through the journey to MBSE, we often paint an overwhelming picture for those just beginning their efforts. In our desire to share not only the outcomes but all the details of the technology (the engineer who describes how the watch works when asked what time it is), we create fear, uncertainty, and doubt about the difficulty of adoption of new techniques. In our passion for specific approaches (often dogmatic adherence to specific tools and notations), we create complexity. As ambassadors for new approaches, where we should seek to lower the barrier of entry – without becoming simplistic – we too often intimidate the uninitiated.
Each of us has the right to be passionate about our specific processes, methods, and tools. That passion helps us drive forward. At the same time, we need to be good ambassadors for MBSE, embracing Einstein’s approach of making things as simple as possible but no simpler. We need to be inclusive, not dogmatic. Fundamentally, MBSE is about making system-descriptive and analytical models explicit, coherent, and consistent. It is a natural evolution from low-fidelity representations in documents to higher-fidelity, richer representations. It is about improved granularity of knowledge capture for management, analysis, and learning. Perhaps that’s not awe-inspiring enough for some. Perhaps that doesn’t rise to the level necessary for transforming our practice. However, it is an honest representation of MBSE that is accessible, open to many different specific instantiations tailored to problem and practitioner proficiency, and simple without being simplistic. If we continue to shroud MBSE in specific representations and methods with all potential complexity, we exclude many of the practitioners necessary to truly advance as a community.
There is much to be proud of in the model-based systems engineering community – the passion present, the progress made, the potential ahead. If we take a moment to eliminate these basic yet recurring missteps, we can constructively channel even more energy toward moving systems engineering forward to become a model-based discipline.
