Every sprinter knows the importance of the first steps out of the blocks. The start is absolutely critical to their success in the race. No sprinter would hamper his start by trading his speedy, lightweight running spikes for a pair of heavy construction boots. And yet, systems engineers quite often squander their project success with poor choices on the front end of the effort.
Whether considering the start of a single MBSE project or the implementation of an enterprise-wide MBSE approach, the most critical point is the start. Missteps here will cost the effort across its whole course. Like a runner one or two steps behind out of the blocks, the systems engineer making premature or poorly-informed choices at the beginning will never catch up to the project or program potential.
In working with clients, we frequently hear concerns that are the result of one or more of the same set of poorly thought out start-up choices. Anxious to taste the advantages of model-based systems engineering, they often suppose that the key lies in the tool or tools used. They act on this assumption and begin to search for an “industry standard” tool. The problem is that there is no such thing as an “industry standard” set of problems; tools are designed to address particular sets of problems. Systems engineers should appreciate that different objectives or even different contexts translate to different problems. Without standard problems there can be no standard tools.
So the first way to hamper your start is to quickly choose a tool and say, “I am embarking on the MBSE journey and I have chosen Tool X. Now where should I begin?” A fuller version of this says, “When we started on the MBSE journey, we found we couldn’t make models because we didn’t have the tooling to do so. So we put the tools into the hands of the engineers responsible for creating the systems models by making them available on the system for the engineers to use. We provided training on how to use the tools. Now we can make models but nobody really knows what to model because we don’t know how we will use them. So we are still stuck.”
Because the journey began with the tool choice instead of a problem analysis, the work is off to a poor start. Without knowing what the question is (“What do I need to do?”) until after the answer (the tool) is determined, the engineer is left in a quandary. One customer described it as trying to fit the pegs of his reality into the holes offered by the chosen tool. Put in the language of the systems engineer, the journey has fallen into the classic trap of leaping to solution rather than working to truly understand the problem. We counsel others about the need to begin in the problem space, and those who ignore their own advice do so at peril.
The problem shows up in the form of the question of what to model. With the tool already chosen, the temptation is often to model what the tool will model. In order to respond to the sunk cost of the tool investment, you can find yourself shaping the work to fit the capability of the tool. The tool shapes your view of the problem and/or you can’t figure out how to use the tool to solve it given your understanding of it. No amount of training in the tool will help to answer this problem. Tool training teaches you how to manipulate the tool, not how to know what you need to model.
A variant on this decision takes the form of asking what you want to do but answering with only the short run in view. Perhaps you think, “I want to work on requirements first.” That may be so, but the journey to systems engineering is an MBSE journey, not an MBRE journey—model-based SYSTEMS engineering, NOT model-based REQUIREMENTS engineering. Success at MBSE will rest on taking a systems level view, not just a requirements view, of the work. Not only will a requirements tool help you only with requirements, but it will also encourage you to think from that perspective. You can quickly become an engineer with a systems problem and only a requirements answer.
The same problem manifests itself whenever you try to partition systems engineering, whether by intentionally purchasing a requirements management tool or seeking an MBSE / architecture tool. A customer who had purchased, instantiated and trained in a tool that offers diagram-based “pictures” of various aspects of the design without fully integrating them surveyed its engineering community about their experience with modeling. Asked about their most critical pain points, a significant number of them responded that they needed a way to link requirements, behavior and components into an integrated design so that they could see the impact of changes in one on the others and verify that the design met the requirements. The modelers were trained and competent in the new tool, but the tool was inadequate to the task. Without a pre-implementation investigation into the needs of the modelers, the tool choice hampered their success from the start.
The problem in all these instances is exactly that—implementation of a “solution” before understanding the need. Just as a runner would choose among trail shoes, flat-soled running shoes, and racing spikes only after knowing what the race course surface will be, no systems engineer should try to choose and implement the use of a tool before understanding what is to be accomplished. Just as no amount of training on running in racing spikes will make them the appropriate shoes for mountain trail runs, no amount of training in the wrong tool will position the systems engineer to solve problems outside the tool’s capability. Those who errantly leap to the solution space without truly understanding the problem (including the context) run into the age-old challenge of solving the wrong problem. We recognize these as validation errors – errors exposed late in an effort but errors that often trace to poor decisions made on day one of the program.
A poor choice or choices at the start will leave the engineer fitting pegs into ill-shaped holes or suffering with pains that the tool can’t alleviate. Understanding the needs and tailoring the implementation to them is the key to MBSE success. Do that and you won’t start out behind.
