How Organizations Can Democratize Their Model-Based Systems Engineering Approach

In my previous posts, I explained how simulation models and architectural models are merging, and how this is foundational to an Agile, model-based approach to developing complex systems. Another important step to enabling model-based systems engineering (MBSE) is to convert from a document-based approach.

While systems engineers have played a unique role to date in overseeing entire complex systems being designed, the goal is to democratize this ability. After all, numerous people are involved in bringing complex systems to market, from systems engineers and software developers to project managers, procurement, and manufacturing.

As organizations make the shift to MBSE, they must embrace a strategic approach to ensure success. Here are practical steps they can take to make this vision a reality.


Want to experience more?
Try Model-Based Systems Engineering For 30 Days.


Invite Others to Participate

As more stakeholders manage tasks concurrently to support the design ad manufacture of complex, connected systems, they need to understand how to work within a model-based approach. As they put in place a construct to support all stakeholders, organizations should consider the following:

  • Why is the language so complex?
  • Must everyone always consider all perspectives?
  • How can we train people to do all this correctly?

This consideration has to be in line with the processes the organization is obligated to follow. This might include safety norms (e.g., DO178B/C, ISO26262, IEC61508, or others, depending on the domain), process norms (e.g., ISO12207, ISO15288, ISO2655x) or process maturity levels, like SPICE, A-SPICE, or CMMI. The roles involved in introducing the processes and ensuring that projects follow the rules are the best fit to look after the MBSE-relevant roles and their needs. That’s because more and more of these norms recommend or require model-based approaches.

Then the organization should educate and train all participants on the approach and their roles. This includes defining the following:

  • What roles are needed
  • How simulation and architectural models are structured
  • How perspectives are connected
  • How to contribute to the completeness and correctness of the common knowledge in the model

Minimize Complexity

As organizations start down this path, it’s important to keep in mind that those outside of design engineering can be intimidated by the complexity of today’s systems and systems engineering methodologies. Only certain stakeholders in the process need to see how all elements link together. In fact, some stakeholders (such as customers) should not see everything involved in the system as organizations must protect their intellectual property.

To ensure people only see what is absolute necessary, organizations should take the following measures:

  • Only expose the necessary options of the language in use.
  • Distinguish between active and passive use of the modeling language and what is required for each, just as when someone is learning a natural language. The European CEFR, as an example, mentions the capability to understand, interact, or produce.
  • Clearly define the roles in the process.
  • Enable everyone to do his or her job using role-based access to the model and role-based model perspectives.

Rather than expose all the options of the language in use, organizations should define who is responsible for what and what types of artifacts, elements or links are part of that responsibility by role. Instead of giving everyone access to everything in the model, they can supply role-based apps that enable people to access all needed information while ensure they are handling the right tasks using the right data.

Those involved in the project that want to see how requirements are handled in the architectural model could access the requirements, which links into specific perspectives of the model. For example, they could see use cases, functional requirements, and context diagrams for interface requirements. Or someone responsible for the product portfolio could access the variability model and create logical connections between functions but not see how the options are linked into the system model or product family model.

Everyone should play their role in building up the organization’s systems engineering methodology so it does not all rest on the shoulders of a few systems engineers. Organizations can take these steps to make the necessary MBSE-related knowledge and resources accessible to all team members so that they are equipped and empowered to participate.

Found this article interesting? Take your research to the next level. Try MBSE for 30 Days!