{"id":56287,"date":"2021-09-30T03:00:18","date_gmt":"2021-09-30T10:00:18","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=56287"},"modified":"2026-07-19T13:36:45","modified_gmt":"2026-07-19T20:36:45","slug":"mbse-is-not-sysml","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/2021\/09\/30\/mbse-is-not-sysml\/","title":{"rendered":"MBSE is Not SysML"},"content":{"rendered":"

\"SysML\"With the trend of organizations practicing Systems Engineering to move towards what is referred to as \u201cModel-based Systems Engineering\u201d (MBSE), there are various perspectives as to just what is meant by MBSE. Similar to the old story of the blind men and the elephant, MBSE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice MBSE, wise systems engineers recognize and use each perspective as appropriate to their specific needs. Based on these needs, they choose the appropriate capabilities, tools, and visualizations that will meet their needs. One size doesn\u2019t fit all.<\/p>\n

The degree to which the data and information is captured and managed is driven by the needs of the organization and projects from a business and technical perspective based on the size and complexity of their systems, their product line, culture, processes, workforce, their diversity and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.<\/p>\n

SysML and other language-based modeling tools<\/strong><\/h2>\n

MBSE is a concept that is maturing and means different things to different people.\u00a0 To some practitioners, MBSE is equated to the use of SysML and other language-based modeling tools. With these tools, practitioners can develop detailed analytical, behavior, and architectural models of a system, with a primary focus of functionality, performance, and interactions between various entities defined to be part of the system being modeled. These types of models are useful tools for system analysis, developing simulations, and creating what is referred to as a \u201cdigital twin\u201d.<\/p>\n

To others, what they are calling MBSE is really Model-based Design (MBD). MBD design starts with a set of requirements and using various language-based modeling tools to architect and design a system, develop simulations to assess the behavior of the system, and then develop a set of design output specifications to which the system is built or coded. Often the MBD activities are completed in a silo separate from the other SE lifecycle process activities.<\/p>\n

MBSE is much more than SysML!<\/strong><\/h3>\n

The above language-based modeling approaches do not address the true intent of MBSE. While these capabilities can be useful, MBSE is much more than using language-based modeling tool to develop analytical, logical, behavioral, and architectural models.<\/p>\n

The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) so as to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system life cycle process activities, resulting artifacts, and their underlying data and information.<\/p>\n

MBSE is not really about any particular\u00a0type of model or visualization<\/em>\u00a0of data and information \u2013 whether that be a model, diagram, report, document, sets of needs, or sets of requirements \u2013 but is about the underlying data and information model<\/em>\u00a0that enables consistency across the data and information that represents the various models and visualizations.<\/p>\n

The data and information model that must be developed should represent SE artifacts generated during the product development process activities across all lifecycle stages. Information associated with the elicitation of stakeholder needs and requirements, lifecycle concepts definition, analysis, and maturation, deriving an integrated set of textual needs, transforming those needs into sets of textual design input requirements, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages, prove compliance with standards and regulations, as well as help assess the impact of changes made to any of the data items across all lifecycle stages.<\/p>\n

Can my organization adopt MBSE without using SysML or other language-based tools?<\/strong><\/h3>\n

Sadly, there are many organizations that have a misconception concerning what the true intent of MBSE is \u2013 as a result they think that MBSE is not for them.<\/p>\n

In a recent conversation with a system engineer, I was told that her organization was not going to adopt MBSE because they don\u2019t see the utility of developing complex SysML models of their products. In addition, she noted that to do so would require a change in how their managers and engineers think based on the SysML standard as to how to construct models and the specific terminology used.\u00a0 To them SysML modeling is not intuitive, has a large learning curve, and has little apparent utility and return on investment \u2013 for their organization, especially for their product line that has a minimum amount of software and complexity.<\/p>\n

My response to her was: MBSE is not SysML!<\/strong><\/p>\n

I told her what the true intent of MBSE is to practice systems engineering with a data-centric perspective, establishing the capability to capture, manage, access data, and manage the interrelationships between SE work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map\/index) of disparate data sources.<\/p>\n

The resulting data and information model can be captured using a variety of SE tools and applications. To effectively manage our ever increasing complex, systems there are benefits to managing this underlying data and information in such a way it can be shared across the system life cycle process activities, shared between the various SE tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex systems as well as enable collaboration between not only the project team members, but also external stakeholders involved in the development of the system.<\/p>\n

Parting Thoughts<\/strong><\/p>\n

The answer to the question: \u201cCan my organization adopt MBSE without using SysML or other language-based tools?\u201d is YES!<\/p>\n

Since one size doesn\u2019t fit all, an organization must assess their needs and produce an MBSE solution that best fits its domain, product line (degree of complexity), and culture. As a minimum, they need to establish a capability to define and manage needs, requirements, verification, and validation across the system lifecycle. \u00a0These capabilities will allow the organization to build a data and information model of their products and systems engineering process activities and artifacts.<\/p>\n

Based on these needs and desired capabilities, the organization can choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.<\/p>\n

Stay tuned for more to come from Lou Wheatcraft in the coming months.\u00a0<\/em><\/p>\n

\n

<\/p>\n

<\/div>\n