Our panel of experts are, clockwise from top left: David Long, Mark Malinoski, Zane Scott, and Mark Simons.
As you reflect on the past year, what is one new insight you had regarding systems engineering and/or model-based systems engineering? Where is model-based systems engineering headed at this point in our evolution, 20 years into the 21st century? What are the challenges we face in our practice? And how can we address them?
These are questions I asked four members of our roving team of content providers at Vitech. David Long is founder and president of Vitech, past president of the International Council of Systems Engineering, and also an INCOSE Fellow. Mark Malinoski is Vice President of Business Development at Vitech, and an inventor who holds six patents. Zane Scott is Vice President for Professional Services at Vitech and chair of the Corporate Advisory Board of INCOSE. And Mark Simons is a principal systems engineer with over 25 years of experience in the systems engineering of space, aviation, telecommunication, and defense systems.
I was particularly interested in hearing what these experts had to say, as they have a finger on the pulse of the systems engineering community—traveling the globe as they do, giving presentations, conversing with other systems engineers, and conducting training classes.
Misperceptions
In the course of asking my questions, I noticed that everyone had registered misperceptions that get in the way of a strong systems engineering practice. Let’s look at a few.
Model-based systems engineering is about selecting “a tool”
Many organizations are now grappling with implementing or improving their MBSE practices. But approaching it only as a tool selection can quickly lead teams into a thorny thicket, Mark Malinoski asserts. Successful MBSE produces system designs and architectures that guide the enterprise. That success is as much about the methodology as it is the tool that implements it. “Many are beginning to recognize we are not going to get to digital engineering without an underpinning systems metamodel,” Malinoski says. “We need to foster the realization that MBSE is not just a tool. It’s more than that—it’s fundamental that the enterprise achieve commonality of MBSE practice so that designs and architectures fully engage performers across the enterprise.”
Let’s make sure at this point that we understand what the systems metamodel is. The systems metamodel is the fundamental structure of the information needed to develop a descriptive systems model. Think concepts like requirement, component, and risk, along with the properties for those items and the valid relationships between them. (Previous Vitech blog posts that discuss the system metamodel include: Using the System Metamodel to Wrangle Complexity, Systems Thinking: Schemas, Metamodels, and MBSE, The Systems Metamodel and Communication, What is the Difference Between a System Model and a Systems Metamodel?, and A Grounded Systems Metamodel – Now!)
Confusing MBSE with “just doing modeling and simulation”
“There’s a confusion that systems engineers are ‘just doing modeling and simulation,’” Mark Simons notes. “The systems engineering aspect gets forgotten. We have to return to the idea that the underlying systems metamodel forms the basis for our engineering practice,” he continues. “It does so by connecting our detailed engineering design to our systems engineering. It does so by using high-level requirements and risks, and connecting those to our detailed engineering analyses.”
Rules for constructing diagrams in a modeling language are all that matters
“Representations, be they documents, tables, or diagrams, are part of a language that’s used to communicate data in a systems metamodel, but they are not the modeling language itself,” says Zane Scott. “The language of modeling is actually the language of the structure of the metamodel that gives the model its semantic meaning.” This view is not commonly held, Scott maintains. “Most people think rules for constructing diagrams representing aspects of the model are all that matters.”
MBSE is too hard
“Model-based systems engineering done right makes it easier for people to learn and understand systems engineering,” David Long says. “However, in general, MBSE is thought of as an advanced topic—that is, that it’s hard.” While it demands a certain amount of rigor, it’s no different than the kind of “rigor” one applies, for example, when baking an apple pie or building a bunk bed. One needs to have the end result in mind, take each step in its course, think about how one element might affect another, and so on. Yes, it requires effort and focus, but the results are well worth it. “The practice of MBSE gets us back to essential information—it becomes a skeleton upon which you can lay all the processes and methods of systems engineering,” says Long.
Challenges
As any self-help book will tell you, when we are conscious of the challenges we face, we are better able to come up with ways to deal with them. When we aren’t, they have a way of running our lives, or at the very least, of surprising us. Our experts pointed out several challenges that face the systems engineering community.
Telling decision-makers about the enormous ROI of MBSE
“It’s so important to be able to tell the story of the benefits one can obtain by using MBSE,” Simons says. “We need to be able to explain to decision-makers what the return on investment is in using MBSE—and it’s enormous.” What is the ROI? Simons elaborates: “It’s lowering the churn factor. Teams will tend to revisit the same problems over and over again without making forward progress unless they have a consistency of practice. That will only happen when you understand what the systems metamodel is, and why that is the basis of model-based systems engineering.”
Miscommunication between “colliding silos”
“There are huge populations within ‘expertise silos’ that define a problem in different ways,” says Malinoski. In one silo, the problem is defined in one way; in another, it’s defined in another way. Both populations are calling it the same thing. When they talk about the problem with each other, it’s clear that the silos are simply colliding—there’s no real communication going on. “What we see is people arguing that the problem is MBSE and the best tool is XYZ without even realizing that they’re solving different problems.”
Resistance to seeing things in a new way
“There is substantive momentum toward applying systems engineering to socio-technical challenges such as clean water, health care delivery, etc.,” Scott says. At the same time, there’s resistance to this. “The resistance comes from the tendency of people to only see things in the context of their own application and experience,” Scott continues. “Unfortunately, it’s all too rare you meet someone who can think at the conceptual level and not just the applied level. This is especially true in the engineering world, where people pride themselves on being practical.”
Wanting to push the easy button
Paradoxically, at the same time that we must not let the prospect of following sound systems engineering principles intimidate us, we also cannot let ourselves fall into the trap of believing that there is a simple solution. “People keep looking for the easy button,” Long says. “But because systems engineering is fundamentally used to tackle complex problems and innovative things, there is no turn-the-crank formula.” Like Goldilocks, we must find the approach that is just right. Neither is MBSE too hard, nor is it too easy.
Not realizing that one’s MBSE artifacts are inadequate
Often, Simons says, teams believe they have a solid set of artifacts. “But what they think are MBSE artifacts are in fact disconnected. We sometimes see designs that are only defined at the lowest level of the system. There’s no design hierarchy. The presence of the design hierarchy is indicative of a solutions-oriented approach. A solid design with connected artifacts is facilitated with the use of a systems metamodel that explicitly defines how artifacts are related to one another.”
The Path Forward
Taking all of the above—the misperceptions and the challenges—how do we move forward? The experts I spoke with had several ideas.
We must continue to seek the fundamental nature of systems engineering
“We’re maturing as a discipline,” Long notes. “If you look at systems engineering compared to science, we’re really immature. At this point, systems engineering is more of an art and a craft.” Long gave an analogy to explain. “In electrical engineering, you have Ohm’s Law. In physics, you have Newton’s three laws. If we can discuss fundamental laws in systems engineering, we can build methods and tools around them that will help the engineer.”
A change is afoot, though, and it “is being influenced by what we have to do to get MBSE and digital engineering to work,” according to Long. As another example, consider human-to-human interchange. It’s sloppy, messy. “From computer to computer, though,” Long points out, “you have to be much more precise. This rigor is helping us as a discipline.”
We must learn to think conceptually
As noted above, Scott talked about our need to expand the application of MBSE to fields outside of the traditional mil-aero environment. This will only happen when we can think at the conceptual level, applying general systems engineering principles across industries and environments, so that we’ll be able to see all the opportunities that this opens up. Simons concurred, noting that “MBSE is playing a role in enabling a broader engineering environment.”
We must acknowledge the primacy of the systems metamodel
Each one of the experts I spoke with expressed, in one way or another, the absolute importance and primacy of the systems metamodel. It is the underpinning of the explicit relationships, and guides a commonality of practice (Malinoski); it keeps engineers within different parts of an organization together and is the basis of consistency in an engineering practice (Simons); it provides a structural language that allows us to communicate productively (Scott); and it defines the essential information that we need to effectively and efficiently engineer a system (Long).
Systems engineering, I’m sure you will agree, is a fascinating topic. I look forward to learning more about it in 2020.
