About the ‘S’ in MBSE


As demonstrated by a simple Google search, the MBSE acronym seems to be widely and consistently understood. Yet, the consensus about ‘M’ standing for models comes with different meanings for ‘S’ standing either for software or different kinds of systems.

Tools At Hand (Annette Messager)

In practice, the scope of model-based engineering has been mostly limited to design-to-code (‘S’ for software) and manufacturing (‘S’ for physical systems); leaving the engineering of symbolic systems like organizations largely overlooked.

Models, Software, & Systems

Models are symbolic representations of actual (descriptive models) or contrived (prescriptive models) domains. Applied to systems engineering, models are meant to serve specific purposes: requirements analysis, simulation, software design, etc. With software as the end-product of system engineering, design models can be seen as a special case of models characterized by target (computer code) and language (executable instructions). Hence the letter ‘S’ in the MBSE acronym, which can stand for ‘system’ as well as ‘software’,

As far as practicalities are considered, the latter is the usual understanding, specifically for the use of design models to generate code, either for software applications, or as part of devices combining software and hardware.

When enterprise systems are taken into consideration, such a limited perspective comes with consequences:

  • It puts the focus on domain specific implementations, ignoring the benefits for enterprise architecture.
  • It perpetuates procedural processes built from predefined activities instead of declarative ones governed by the status of artefacts.
  • It gives up on the conceptual debt between models of business and organization on one side, models of systems on the other side.

These stand in the path of the necessary integration of enterprises architectures immersed into digital environments.

Organizations as Symbolic Systems

As social entities enterprises are set in symbolic realms: organizational, legal, and monetary. Now, due the digital transformation, even their operations are taking a symbolic turn. So, assuming models could be reinstated as abstractions at enterprise level, MBSE would become the option of choice, providing a holistic view across organizations and systems (conceptual and logical models) while encapsulating projects and applications (design models).

MBSE provides a holistic view of organisations and systems.

That distinction between symbolic and actual alignments, the former with conceptual and logical models set between organization and systems, the latter with design models set between projects and applications, is the cornerstone of enterprise architecture. Hence the benefits of implementing it through model based system engineering.

Leveraging MBSE

While MBSE frameworks supporting the final cycle of engineering (from design downstream) come with a proven track record, there is nothing equivalent upstream linking business and organization to systems, except for engineering silos using domain specific languages. Redefined in terms of enterprise architecture abstractions, MBSE could bring leveraged benefits all along the development process independently of activity, skills, organization or methods, for enterprises as well as services and solutions providers.

As a modeling framework, it would enhance the traceability and transparency for products (quality) as well as processes (delays and budgets) along and across supply chains.

‘S’ For Service

Implemented as a service, MBSE could compound the benefits of cloud-based environments (accessibility, convenience, security, etc.), and could also be customized without undermining interoperability.

To that end, MBSE as a service could be reframed in terms of:

Customers (projects): services should address cross-organizational and architecture concerns, from business intelligence to code optimization, and from portfolio management to components release.

Policy (processes): services should support full neutrality with regard to organizations and methods, which implies that tasks and work units should be defined only with regard to the status of artifacts.

Messages (artefacts): the specification of artefacts must be strictly aligned with enterprise architecture layers:

Contracts (work units and outcomes): services are to support the definition of work units and the assessment of outcomes:

  • Work units are to be defined bottom-up from artefacts.
  • Outcomes are to be assessed with regard to work units
  • Value in Models Transformations:
  • Transparency and Traceability: Two distinct model sets – Architecture Models and Implementation Models.

Endpoints (collaboration): if services are to be neutral with regard to the way they are provided, the collaboration between the wide range of is to be managed accordingly; that can only be achieved through a collaboration framework built on layered and profiled ontologies.

As a concluding remark, cross-breeding MBSE with Software as a Service (SaaS) could help to integrate systems and knowledge architectures, paving the way to a comprehensive deployment of machine learning technologies.


One thought on “About the ‘S’ in MBSE”

Leave a Reply