After 15 years of practice, there is still a great deal of confusion surrounding model-based systems engineering – not only what MBSE is but also the difficulty of application. Some see MBSE as simple, the only possible way they could imagine engineering a system of any scale. Others perceive it as a highly complex undertaking, only worthwhile when addressing the most challenging of situations. Interestingly, these perceptions don’t necessarily align with the beholder’s level of MBSE expertise, the depth of systems engineering experience, or comfort with tools and technology.
So what is the case for MBSE being simple? Or complicated? Or complex? For each, there are both a legitimate argument to understand and traps to avoid. More important than the question of simple, complicated, or complex is the question of how we move beyond these perceptions to better frame and implement MBSE as we engineer systems.
MBSE as Simple
To see model-based systems engineering as simple, it helps to understand some of the fear, uncertainty, and doubt that surrounds the label itself. “Model” includes any simplified representation – physical, mathematical, graphical, or verbal – that aids in communication, analysis, or reasoning. The breadth of what might qualify as a model translates to a broad range of interpretations for what qualifies as MBSE, and this breadth of interpretations leads to confusion. (Before we are tempted to rebrand MBSE under a different label, recognize that Digital Engineering suffers from similar challenges due to the varying interpretations of “digital.”)
Rather than attempting to define our way out of this ambiguity, I prefer to describe model-based systems engineering. Put simply, MBSE is about making the descriptive and analytical system models explicit, coherent, consistent, and actionable (or computable if you prefer). It’s about an evolution in the fidelity of the representation of information for both communication and analysis. What could be more natural in concept than seeking to improve the representation of the information required to engineer systems?
The trap is moving from simple to simplistic, and there are at least two ways to make that error. The most common mistake is failure to understand the difference between a view of a model and a drawing. Just as top/front/side views in CAD are not the same as three disjoint views drawn in Visio, there is a difference between a view of an integrated systems model versus a diagram. The first done properly is descriptive MBSE seen from many viewpoints. The second is MBSE’s dangerous imposter DBSE (diagram-based systems engineering) – looking simple on the surface but simplistic in implementation as it lacks the essential coherence, consistency, and foundation for reasoning we need.
The other error is seeking to simplify systems engineering by simplifying the information elicited, analyzed, and managed. For a given problem, there is a necessary set of information – and relationships between that information – required to successfully engineer the solution system. Those who seek to address complexity through simplicity often find that the aspects of the problem that they simplified away become the root causes of their failure.
MBSE as Complicated
To see model-based systems engineering as complicated, don’t focus on the model-based aspect. Instead, focus on the systems engineering. If model-based is an approach to better represent the essential information, the foundational complication resides in systems engineering itself. MBSE – or, more accurately, systems engineering – as complicated is a reflection of the breadth of and relationships between the information necessary to successfully engineer a system.
Over the years, systems engineers have developed a portfolio of processes, methods, and tools to elicit, develop, and analyze this information. While that portfolio evolves as we implement MBSE, model-based systems engineering also exposes and clarifies the scope and interrelationships of the necessary information. MBSE does not simplify this complication, but it eases the management of the information and interdependencies. It also better equips the systems engineer with a fundamental understanding of the relationships that drive emergence – in the system of interest and the systems engineering process.
The trap comes in attempting to reduce complications in systems engineering through subdividing systems engineering. Often, organizations choose to implement subsets of systems engineering due to ease of understanding or ease of adoption. Or, an organization may choose to implement the breadth of systems engineering but via silos in teams, tools, processes, and information. This reductionist approach appears to address the complication but violates the holistic nature of systems engineering. By breaking systems engineering apart, we may simplify, but we lose the inherent value of the systems perspective.
MBSE as Complex
To see MBSE as complex, look neither to systems engineering as a practice, the technology of modern systems, nor the tooling of model-based systems engineering. Look to the human – as stakeholder, as user, as participant within the system boundary, and as member of the engineering team. Much is made of our technical transition from electro-mechanical to software-intensive and now cyber-physical systems, and this should not be overlooked. The electronics and software that power today’s solutions radically increase the connections and coupling within our systems. But it is in the human and the interaction between humans implicit in socio-cyber-physical systems that the true complexity of systems engineering resides.
On the front end in dealing with stakeholders and users, model-based systems engineering must aid the elicitation of competing needs within differing value systems. Throughout the engineering journey, MBSE must enable shared understanding of both problem and solution across the transdisciplinary team. This requires addressing both the descriptive architecture and the fundamental equations that connect analytical concerns between disciplines and ultimately drive systems performance. Unfortunately, we speak different languages born of our particular discipline and our specific experience. It is up to the systems engineer to effectively bridge this through good MBSE.
The trap comes in believing that the path to effective communication, analysis, and shared understanding resides not in concept but in a single notation. It is appealing to believe that we can address the Tower of Babel through adopting a common language, but just as different tribes have adopted different languages each with their own nuance, disciplines have their own languages which have evolved to communicate effectively within their bounds. Seeking to replace these purpose-built languages (such as the language of computational fluid dynamics or electrical circuit design) with a generic systems language increases complexity while reducing fidelity. The answer is not to replace the language of the disciplines. The answer is to connect their perspectives and languages at the system level, unlocking the power of their insights while enabling their analysis. The power is in the diversity of multiple connected views and viewpoints driven from the authoritative source of truth rather than one set of views in a universal notation.
This places the responsibility on the systems engineer to learn to map to the specialists’ languages and become the translator fusing the perspectives into a unified systems view. That is no small task and one that should not be undertaken unadvisedly. But, done well, it holds the promise of a richness beyond what could be expected by forcing everyone to adopt a “standard” language foreign to their experiences and often ill-equipped to represent their concepts in a way that effectively communicates within their domain of expertise.
Simple, Complicated, or Complex
So then, what is the answer? As we often find, asking an “or” question results in an “and” answer. Rather than weakness, this is strength. When asked about MBSE – whether by an experienced practitioner, an early career systems engineer, a manager, or a member of the C-suite – I first frame the simple answer. The high-level view of MBSE as an evolution in the way we represent the information necessary to engineer a system is both intellectually accessible and an essential perspective. The complications of systems engineering help define the scope, the critical nature of the interrelationships, and some of the value of good MBSE as it provides a conceptual skeleton to help integrate systems engineering’s processes, methods, and tools. And the complexity of humans – as customers, users, parts, and developers – is something we must recognize and respect if we are to deliver the required value to the customer and the stakeholders in an effective and efficient manner free from unintended consequences.
Oftentimes, we err in chasing simplicity. The mistaken pursuit of simple in complicated and complex situations becomes simplistic. But neither should we revel in complexity. Sadly, there is an art in making the simple complex, and too many increase complexity unnecessarily through requirements explosion, intricate processes, and user-hostile tools. The answer is in recognizing simple, complicated, and complex, and ultimately pursuing fit-for-purpose elegance in our system solutions.
I really like this distinction between DBSE and MBSE. Diagrams (and documents) are models, but they are not MBSE unless they are a perspective derived from an explicit “integrated systems model” that provides “the essential coherence, consistency, and foundation for reasoning we need.”