How to Keep MBSE from Becoming Just a Buzzword (or Is It Too Late?)

The term “Model-Based Systems Engineering” or “MBSE” has been around for nearly a decade. We see the term in requests for proposals, marketing materials, social media, conferences and many other places in the systems engineering community and even in the general public. Clearly, MBSE has become an important part of systems engineering, but has it also become the definition of a buzzword? First, take a look at the definition of a buzzword.




  1. a word or phrase, often sounding authoritative or technical, that is a vogue term in a particular profession, field of study, popular culture, etc.


So, it definitely sounds authoritative, as it comes from the “International Council on Systems Engineering” (INCOSE). It sounds technical, using “Model-Based” and “Systems Engineering.” And clearly, it’s “in vogue,” from its appearance everywhere.


What the definition of a buzzword doesn’t seem to provide is the way a buzzword has a negative context or as Dilbert put it:



What this means is that a buzzword is used by people who don’t really know what it means. I’m sure we have all heard many people use it without any idea of what it means. So, what does MBSE really mean?


Well to understand its real meaning, we need to review the definition of MBSE from INCOSE:

 “Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” – INCOSE


As systems engineers, the first thing we want to do is decompose this rather long sentence. It can be broken down into two parts:

  • Modeling (formalized application); and
  • Lifecycle (system requirements, design, analysis, verification and validation).


The formalized application of modeling means that we create models of the system using a “standard.” We know that there are a number of formal and informal standards, which are applied in many different ways. The standard most are familiar with is SysML since it is a profile of UML. SysML focuses on communicating with the software community primarily. The Lifecycle Modeling Language (LML) open standard (, covers the second part of the definition better, as its name implies. It also addresses the program management aspects of systems engineering (risk, cost, schedule, etc.), none of which is really addressed by SysML.


But we have been creating drawings, which are a type of model, since well before anyone called the discipline systems engineering. So, what makes this term different from classic systems engineering?


The key difference is the type of modeling we use when we talk about MBSE. We mean the development of “computable models.” Computable models are models based on data (usually in a standard ontology, like the one LML provides) that can be visualized in standard ways (again using any drawing standard, which both SysML and LML provide). These models can also be tested to determine their validity and to make sure we don’t introduce errors in logic or problems related to dynamic constraints (i.e., lack of resources, bandwidth, latencies, etc.). This testing also includes checking the models against general rules of quality, such as “all function names should start with a verb.” The tools for this kind of testing today include simulation (e.g., discrete event, Monte Carlo) and natural language processing (NLP).


Having models that can be tested and testing them is a clear way to make MBSE real and not a buzzword. Therefore, to implement MBSE you need a tool or set of tools to conduct this testing.


When considering a “MBSE” tool, you will hear claims from almost all of the tool vendors that they are one. To distinguish between those who deliver on the promise of MBSE and those who are treating it as a buzzword, just ask the following questions:


  1. Are your diagrams essentially drawings or are they automatically generated from the data?
  2. If I make a change to one piece of data in the database is that automatically updated in all the other visualizations of that piece of data, including the diagrams?
  3. Can I execute the models using strong simulation techniques?
  4. Do those simulation techniques include discrete event and Monte Carlo?
  5. Do the simulations take into account resource, latency, and bandwidth constraints?
  6. Does your tool test the entire model against common standards of good practice (heuristics)?
  7. Does your tool support the entire lifecycle (system requirements, design, analysis, verification and validation) in a seamless, integrated fashion?


If you ask all these questions, you will find a limited set of tools that can even come close to keeping MBSE from just being a buzzword. So, it’s essential that you carefully evaluate these tools to make sure they provide the support you need to become more productive and produce higher quality products. To see a tool that does meet all these needs check out