MBSE

MBSE Tool Maturity – Where does your organization stand?

By |

MBSE Tool Maturity LevelsMy initial intention for this blog was to talk about what I describe as MBSE tool maturity levels. And I will surely get around to those levels. But first I think it is important to draw attention to the definitions of MBSE that experts use and offer some observations that might be helpful to those who are beginning their own MBSE initiatives.

What is MBSE?

The International Council on Systems Engineering (INCOSE) describes MBSE as the “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through-out development and later lifecycle phases.” This is simple enough to digest and the only noticeable difference between it at their definition of systems engineering is the reference to “formalized application of modeling.” They do not however, define what “modeling” means.

NASA says MBSE “involves applying software-based tools to capture systems engineering evidence — typically called “artifacts” — in a systematic, disciplined way that allows people to manage complexity while communicating effectively across the life cycle of a system.

  • MBSE is to perform systems engineering – connects system relationships
  • Controlling system configurations
  • Communicates an overall system picture accessible to all
  • Makes it easier to integrate disparate material
  • Ensures everyone is working on the same up to date material at all times
  • Eliminates problems with version control

RELATED: MBSE Made Easy – Overcoming the Organizational Challenges 

What is a Model?

NASA’s definition certainly provides a good deal of information, but they don’t even use the word “model” in their description. Lenny Delligatti, one of the most respected MBSE experts in the world wrote that, “A modeling method is something like a road map; it’s a documented set of design tasks that a modeling team performs to create a system model. More precisely, it’s a documented set of design tasks that ensures that everyone on the team is building the system model consistently and working toward a common end point. Without such guidance, there will be wide variance in the breadth, depth, and fidelity that each member of the team builds into the system model.” What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system.” These definitions are super informative.

An observation I have is that organizations instantly equate MBSE with the use of a SysML tool. The experts tell us however, that MBSE is the combination of methods to create a representation. None of them say that to perform MBSE one must adopt a graphical modeling tool. There are many different methods to create models/representations. Some are graphical and some are textural. At the heart of MBSE is the drive to move from static documents (Word and Excel) into an information-based paradigm. The table below eloquently articulates the differences and standout benefits of using an MBSE approach.

MBSE table

Table source: Laura Hart, Lockheed Martin

MBSE Tool Maturity Levels

There are certainly many organizations that are still performing systems engineering only using documents. For the rest, there are a plethora of tools in the ecosystem used to create models including tools that support SysML. To begin the journey of MBSE, you don’t have to adopt a SysML tool right away. Maturity of MBSE is still young. Very few organizations do it for a program in an end-to-end manner. The learning curve is steep. Generally, a few engineers become the “scribe” and then end up translating to the extended team. And keep in mind a systems engineer is a “cat herder.” This person is the one who sees the big picture, understands the problem, and is the translator across engineering domains and the business. A SysML tool won’t be the only tool in their arsenal.

MBSE Maturity Levels

This finally brings me to describing MBSE tool maturity levels. Many organizations are already performing MBSE without even calling it MBSE just by the tools and processes they use in the organization. Level 0 is what I describe as only using documents and having no model representations at all. Level 1 is barely a step up from level 0 but the have a requirements tool in place or possibly a Kanban board that is capturing loosely coupled relationships between data. Level 2 is where teams are now combining the use of the RM tool with diagrams. Perhaps they are drawing diagrams in Visio or a UML tool. Level 3 is the combination of requirements, architectures, diagrams are used in conjunction with a defined methodology for how the information is defined, related, and analyzed. The tool will programmatically constrain the data in order to provide consistency as well as provide the mechanisms to define once and then reuse. Level 4 tool maturity is where organizations use a requirements tool and SysML tool.

Jama Connect aligns as Level 3 maturity. Customers who use Jama Connect experience their requirements becoming a source for strategic information during all stages of the system lifecycle. Requirements are turning into actionable data. The software world with its mass adoption of agile practices is trickling into the systems space and requirements now take different shapes. MBSE takes more than use of a language-based graphical modeling tool. Even for a Level 4 maturity, natural language is still the great common denominator. Not everyone will be an engineer and able to interpret models. Requirements and the structured architecture within Jama Connect provides the necessary context. Jama Software’s Companion MBSE approach can be seen as the bridge one uses to leave behind documents and move towards Level 4 maturity.



Cary Bryczek
Latest posts by Cary Bryczek (see all)