My expertise and study in the business and academic realms provide the basis of my discussion on the Systems Engineering Vision 2023–2033. As a result, I will outline what business managers and academic scholars inquire about and seek out in the Model-Based Systems Engineering (MBSE) in this article today. In addition, I am investigating what practitioners are utilizing, what customers are investing in, and what academic scholars are investigating.

I will begin with what the company managers ask or look for regarding Model-Based Systems Engineering (MBSE). Herein, I will inform you where the MBSE is and where it needs to go. Today, Systems Engineering utilizes Document-Based Systems Engineering. By Document-Based SE (DBSE), I do not mean a literal document of Systems Engineering (although many people today love paper). Instead, I am talking about something like the MicroCell and Microsoft Office Suite, so if I am restricted or relying on MS Word, PowerPoint, Excel, and Vizio, that is DBSE. That’s not MBSE. So let me share an observation I’ve made. Today, most business organizations are practicing Systems Engineering with some DBSE models.

Additionally, from my experience and contact with practitioners, most companies are doing Systems Architecting with a model whose focus is mainly on the requirements and architecture, particularly in the architecture part. Most companies today use one or more of the Suite of architecture tools that are available. Yet, they cannot use these tools for detailed design. And for sure, a design engineer very well will argue that these tools are not detailed design tools. These are System Architecting tools.

So, a lot of organizations need to catch up on what MBSE is.

In most cases, this is where we are, yet there are many exceptions where companies are much more mature than simply using Systems Engineering with a model. These companies have a Suite of models that do a subset of the different aspects of Systems Engineering. For example, the ten domains of the “Vee model” (i.e., at the left side of the “Vee model”: Stakeholder needs, Requirements, Architecture, Detailed design; at the bottom of the “Vee model”: Implementation; at the right side of the “Vee model”: Unit testing, Integration & Test, Verification, Validation; at the top of the “Vee model”: Risk management traceability and Multi-level analyses decisions) represent tools or models that are applied in that particular area. So, I’ve seen some companies that will utilize a tool or a Suite of tools to capture stakeholder needs and articulate requirements either textually or graphically that can do computer-aided design and computer-aided manufacturing and assembly. Also, these companies use a Suite of tools that enable and assist in testing, integration, verification, and validation.

Ideally, in the case of MBSE, all the “Vee model” tools should be linked. Initially, perhaps manually, but ultimately will be linked to transfer data from one Suite of tools to another. At this stage, we get into MBSE. It might be a Suite of tools that a company or an organization uses but surrounded by a framework or an environment by which data can pass from one to another. So that at no time do we rely on documents or documentation; though someone can produce it, in most of these tools, someone can push a button, and it will have a report or some form of documentation. But this is the general environment where many companies are striving and represents a significant maturity level. Ideally, MBSE is the entire system development life cycle performed within what some people call a “digital ecosystem.”  “Digital ecosystem” is more than just a framework linking tools together (in fact, it is an entire ecosystem) that all works together. So that there is no dependence on documentation, the model truly becomes the authoritative source of data and information.

Thus, I’ve seen in real life that organizations are working in the process that we as a discipline are maturing, which is excellent news. Therefore, this will continue in 2023 and, in 2024, will start to accelerate as we continue to grow. Of course, reaching this expectation level requires commitment and capital; it will require new skills, training, knowledge, and education. So, there is an implicit set of requirements to achieve what we today call MBSE.

The cost of implementing Model-Based Systems Engineering (MBSE) is one of the many arguments I’ve heard against doing so.  The equipment required for MBSE is more expensive than the equipment formerly utilized for Systems Engineering. To adopt MBSE principles on a wide scale, it is not cheap to train an existing workforce of systems engineers in the methodology, semantics (languages like UML or SysML), and tools (such MagicDraw, Rhapsody, Enterprise Architect, etc.). Many people find it simple to argue that because their company currently has “good enough” processes in place, there is no room in any given project’s budget to justify the investment necessary to adopt MBSE.

The hidden costs of not doing MBSE are not considered in the conventional analysis of how implementing MBSE will affect a project’s bottom line.  There are frequently many players in the development of contemporary complex systems. Due to the fact that I have spent my whole career in the aerospace and defense sector, I can attest to the fact that when a new aircraft is being created, stakeholders such as Systems Engineers who specify system requirements and interfaces, Software engineers create the system’s software, hardware engineers create the system’s hardware, test engineers ensure the system performs as expected, safety engineers assess the system’s safety risk, cybersecurity engineers assess the system’s susceptibility to threats, and reliability engineers confirm the system satisfies the customer’s availability requirements. Each of these stakeholders has certain goals that could have an effect on one or more of the others.  Each of these parties involved also needs to comprehend the architecture of the system and consider the context in which their analyses are being conducted.

All stakeholders can consult a single model that describes the context and architecture of the system when MBSE is applied correctly.  Stakeholders can update a model that is updated by an architect to communicate their concerns and record the findings of their study rather than duplicating work by creating entirely new use cases and block diagrams.  With each additional stakeholder who uses an architecture model as their main artifact, the potential for cost savings grows.

Although MBSE requires a sizable initial expenditure, when it is applied in a realistic way, the savings obtained by lessening the amount of duplicate work performed by numerous stakeholders during the development of complex systems can substantially outweigh the investment.

Georgios Ardavanis  – 26/03/2023