Often—and more often than one might think—we hear statements from customers and prospects along the lines of, “I heard MBSE would help us—it’s the latest thing. I hear that Tool X is the ‘industry standard.’ It’s cheap/simple/used by organization Y. If you buy tool X and start building models, it will do systems engineering for you.” This package of statements contains a number of misconceptions that get the speaker and his organization off to a bad start on an important journey.
We should make no mistake about the fact that the process of adopting model-based systems engineering is a journey. It is a journey in which we seek to move from where we are in our systems engineering practice to a desired state of that practice. Starting the journey without a clear picture of what we are seeking is as foolish as starting a long trip with no idea of where we are going. As Yogi Berra astutely pointed out, “If you don’t know where you are going, you’ll end up someplace else every time.”
The advice contained in the maxim “We must slow down in order to speed up” has direct application to the start of the successful model-based systems engineering (MBSE) journey. By carefully asking—and answering—a number of preliminary questions, we can avoid a series of costly mistakes that can force us to cripple or even abandon our journey to the benefits and power of MBSE. We slow down to ask the questions that ensure we know where we are going and, as a result, get there more efficiently. The questions matter and the order in which we ask them matters as well.
It is tempting to answer the “how” question first. We see this all the time with people who choose a tool first, often in the mistaken belief that a particular tool will “do MBSE.” The truth is that no tool “does MBSE;” only systems engineers do MBSE. But, despite the temptations and claims to the contrary, it is the “why” that must be understood before the “how.” Without knowing why we need MBSE, it is premature to even ask “How?”
Why make the journey at all?
The first question we must ask ourselves concerns what we hope to accomplish by adopting MBSE. The answer to this question has numerous ramifications for how we will choose to make the journey. Answering it involves knowing what we are doing. Are we engaged in process design/improvement, or are we designing products? The answer to that will help us decide whether our journey needs to include developing the ability to connect the model to physics-based analytic models.
Are our designs “clean-sheet” unprecedented efforts? Or are we engaged in the redesign or replacement of existing systems? The answers to those questions impact the way we will gather data and construct our models. These questions bear on why we choose to engage with MBSE at all, and impact the path we will choose for that journey.
How will we implement MBSE?
Once we know what we want to do, we can then—and only then—begin to ask how we will implement MBSE. Here, we will want to know how complex the problems and solutions that make up our design space will be. Complexity will make demands on the MBSE process and tooling. Those demands must be met by our process and tools in order to obtain a useful model of our design.
At this point, it becomes appropriate to begin the selection of tools. Any viable tool candidate must be capable of producing a fully integrated model of the problems and solutions under consideration. To that end, it must organize the system entities, relationships and attributes according to a robust systems metamodel instantiated in the tool as a database schema. Anything less leads inevitably to incompleteness and inconsistency. High levels of complexity makes the need for this organizing schema particularly important.
The tool must organize the model using a language that is sufficiently nuanced and sophisticated to describe the complexity of the problems and solutions it is used to depict. Simplicity in the name of ease of use is a siren song that invites the practitioner to crash her MBSE vessel on the rocks of a tool too crude to create an accurate picture of her designs. The language must describe the entities, relationships and attributes of the model in detail. It must provide a set of control constructs rich enough to model and simulate the system behavior with a high degree of fidelity.
The tool must present a variety of representations that can be generated from the model data by the tool that are sufficient to communicate the various aspects of the system design to the broadest possible audience. Narrowing the set of representations, even in the name of “standardization,” simply impoverishes the communication and limits the audience for the design.
Horse and cart in proper order
With these questions answered in the proper order, with the “why” properly in position to drive the “how,” the journey to a robust and effective MBSE practice can begin. Having in hand a destination and the means to get there offers a reasonable assurance that the journey is well begun. Anything less is placing success in jeopardy.
