What is MBSE?

Part 1, Deriving a Definition

Every field of technology has its buzzwords and fads.  Systems engineering is no different.  The latest buzzword is Model-Based Systems Engineering, or MBSE for short.  Is MBSE just a buzzword or real change in how systems engineers do their jobs?  Not surprisingly, there are still systems engineers who don’t understand what MBSE is.

A key reason that some SEs still have a blank stare on their face whenever MBSE comes up is that many don’t understand what the term really means.  They can expand the acronym, but still not have an understanding.  For many systems engineers, MBSE exists only in contrast to legacy systems engineering, which was document based.  A document based approach was what most experienced systems engineers learned on the job, and have used throughout their careers. Without a real understanding of MBSE, systems engineers will return to what they know: textual documents, PowerPoint and Visio graphics.

To move SE forward to a MBSE mindset, we need to resolve this issue of understanding; we need to define what MBSE really is.  Let’s walk through a process of finding or deriving a definition for MBSE.  Along the way we might learn a few things too.

Unfortunately, when you have a buzzword or phrase with vague terms in it, you really have no choice but to delve into the definitions of those terms.  When in doubt about a definition, I first go to either a recognized authority, or the dictionary.  In this case, we can look to INCOSE as a recognized authority. INCOSE’s SE Vision 2020 provides this definition of MBSE is:

“…the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software. In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes.”

INCOSE also provides a definition of systems engineering:

“Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Cost & Schedule, Performance, Training & Support, Test, Disposal, Manufacturing.

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.”

Unfortunately, these definitions don’t help very much.  They essentially say only that MBSE is an application of modeling that supports the process of systems engineering.  So, what is modeling, or a model for that matter?  This time we can go to the dictionary.  Merriam-Webster has many definitions for “model”, but these seem to be the most pertinent:

Model; noun:

…

3: structural design

4: a usually miniature representation of something; also: a pattern of something to be made
…

11: a description or analogy used to help visualize something (as an atom) that cannot be directly observed
12: a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs; also: a computer simulation based on such a system

For our purposes, I’ll combine these and synthesize one big definition:

Model; noun: a representation, generally visual, serving as a pattern of some thing to be made, including information such as the structure, data, states, behavior and inferences about the thing

We have a pretty good idea of what a model is now; it is the representation of important information about a system. That information will be unique to the specific system based on the purpose of the system, unique technology,  regulatory issues, and schedules, among other constraints.  The information will serve to plan, organize, direct and control the lifecycle development of the system, with an emphasis on design and development in the case of systems engineering.  We might even describe that information as strategic.

Still, there’s something missing.

Pinned to my office wall is a visual representation of a 10 step process to follow to perform systems architecture.  It’s a visual representation of a pattern of steps, and it captures strategic information, but it’s still just a collection of pixels printed on a large sheet of paper. I can manipulate the pixels to adjust size, shape and color, but I can’t manipulate the strategic information.  The information has no independent form.

The representation is just a means to visualizing the information.  In order to manipulate the information underlying the representation, the information needs to have its own form.  It needs to exist in a repository, and there needs to a single controlled copy of it.  Furthermore, it needs to have a syntax and meaning to it so that engineers all interpret it the same way.  The information needs to be “formalized,” which is supported by definitions in the Merriam Webster dictionary.  (Reviewing the dictionary in this case is an exercise left for the reader.)

If we accept this derivation process, combining definitions of modeling with systems engineering, then our definition becomes

MBSE: the process of creating formalized representations, generally visual, that 1) serve as patterns for systems to be made and 2) capture strategic information about the systems, in order to realize those systems successfully.

Personally I think this is a better definition than INCOSE’s, but there is some pride in authorship.

The principles behind MBSE do change the way SEs approach the discipline.  The approach radically shifts from writing descriptive documents to an exercise of managing critical information that describes the system patterns.  Documentation is inevitable, but under MBSE it changes from being the end goal of the systems engineer to being reports that describe or visualize the underlying information architecture.  The documents report on the model.  The quality of the information in the model and its organization are the new goals of model based systems engineers.

The next time you need to explain what MBSE is, you have not only a better definition to use, but you should have a better understanding of how the definition came about.  For that matter, if you want to challenge the definition, you now have a basis for creating your own.

The typical challenge to this definition is addressed in another post.