MBSE 2.0 – what’s that all about?

I just came back from the INCOSE IS2019 conference and I’m eager to report that the view I expressed in my recent blog on systems engineering was also addressed by David Long of Vitech (congratulations on becoming the latest INCOSE fellow!) in his MBSE 2.0 (Model Based Systems Engineering) presentation. Here are two key slides from that session which Dave graciously allowed me to use:

Notice that the MBSE 2.0 slide accentuates the central role of Requirements Architecture. That is very important because the very top level requirements form the bridge to and a context between a more holistic Systems Thinking (a.k.a. “understanding” which is related to but not exactly part of MBSE) and a more detail oriented Systems Engineering (a.k.a. “intervening” which is the essence of MBSE).

At the same conference the team from Thales held a day long PLE (Product Line Engineering) workshop. Part of the workshop was a look into the intricacies of using Systems Thinking to identify the key stakeholder’s capabilities (a.k.a Requirements) as a prerequisite to the development of a system model. The PLE angle is also very important because it drives the concept of a 150% capabilities approach from the start which subsequently allows for the definition of multiple 100% variants.

So what’s my point? My point is that the concepts of MBSE 2.0 and PLE have key implications at both ends of MBSE: the upper left end of the engineering V curve that feeds MBSE (where Systems Thinking provides the right context to a 150% system model) and the lower/right parts of the engineering V curve that feed the rest of the design process (realized/implemented configurations of the 100% system variants)—and that as a result there are a lot of interrelated data models.

So here we are: Systems Thinking allows us to identify the key 150% Requirements (with formally defined variability), which allows us to define a 150% system model (with formally defined variability), which are then leveraged by PLE (developed and managed as part of MBSE) to properly implement 100% variants in multiple engineering domains (that also have formally defined variabilities). It’s all connected, configurable, collaborative, and transdisciplinary. As a result, I see a bright future for resilient and flexible PLM (Product Lifecycle Management) platforms because MBSE 2.0 can’t succeed without formal enterprise-wide configuration control and data traceability across, well, everything – two key pillars of a true digital thread.

Are you ready for this digital transformation of your entire design process?

BTW – the term “transdisciplinary” was recently adapted by INCOSE as more desirable to “multidomain.” That’s because the former stresses the concept of interaction between disciplines while the latter comes across as accepting of disconnected discipline silos—look here. I like that!