Redefining the Future of Systems Engineering

By Steven Dam

The International Council on Systems Engineering (INCOSE) recently published their “Vision: 2035” document. While discussing the theme with another INCOSE member, he asked me what I thought about it. I thought for a few seconds and said, “The only thing I know is by 2035, we won’t be calling our capabilities MBSE (Model-Based Systems Engineering).”

In a 2011 paper, Cecilia Haskins presented the “Plateau of Productivity” diagram below. Her conclusion from the paper was, “There are significant implications for the placement of the ‘we are here’ arrow. If MBSE is sitting near the ‘Peak of inflated expectations’ we can expect a roller-coaster ride into the ‘Trough of disillusionment.’  On the other hand, if we are entering the ‘Slope of enlightenment,’ then we are on our way to the ‘Plateau of productivity,’ and early adopters will reap the benefits of competitive advantage sooner rather than later. This author feels optimistic that the latter placement is defended by the historical perspectives presented in this paper.”

If that was true in 2011, then where are we in 2022? Perhaps MBSE should be leading systems engineering today rather than the future. If this is the case, then what keeps MBSE from gaining greater adoption? 

MBSE focuses on having living models to capture and express the technical aspects of systems engineering. It was pushed as a counterpoint to the “document-based” systems engineering of the 20th Century. The problem comes in the capability of these models to be expressed in a form that helps decision-makers come to a conclusion. This is because systems engineering is much more than modeling and simulation. So what’s next for systems engineering?

I think decision-makers want to see data from various detailed engineering analyses transformed into information so that they can make decisions. If we want to get “buy-in” from senior managers, we must communicate to them in a language they can instantly understand and the work must be data-driven. This means the future of systems engineering is Data-Driven Systems Engineering (DDSE)!

DDSE is defined as “The transformation of user needs to requirements for design engineering and the transformation of design engineering data into verified and validated
system-level information for decision-makers to make better decisions throughout the lifecycle.”

DDSE requires a language that is not based solely on models but includes both models and an ontology for capturing all the data associated with the system, not just the models. Fortunately, this language already exists and supports the entire lifecycle of both systems engineering and program management. This language is the Lifecycle Modeling Language (LML), implemented in state-of-the-art tools that have proven the capability needed to capture the data and present it in a form that communicates well to all audiences.

There are 3 reasons why I believe LML is the language for DDSE

  1. LML was designed by systems engineers for systems engineering and program management. The group that put this specification together drew from decades of experience in these fields, looking at all the ways we have tried to gather this information since the 1960s. The result is a language that systems engineers and program managers can easily understand, adapt, and extend as their needs require. You can see by the figure below the models and classes in the LML standard. They explicitly include cost, schedule, performance, and risk. It also includes other common systems engineering terms, as well as the entity classes needed for physical and functional modeling. Also, extensions are both allowed and encouraged. The appendices in the recent LML v1.2 Specification provide linkages to other languages (SysML, DoDAF Meta-Model 2.0) and domains (V&V). The LML Steering Committee is actively developing further extensions and expects to release a v2.0 that adds some of the key ones to the base set of entity classes. LML also includes three mandatory diagrams: Action (for functional modeling), Asset (for physical modeling), and Spider (for traceability). However, it also encourages visualization of the data for all entities and suggests common diagram types to enhance communications.

  1. It’s an open standard. It is under the governance of the Lifecycle Modeling Organization in section 501(c)(3), which was an outgrowth of the original LML Steering Committee. The standard is non-proprietary and is being taught in over 200 schools around the world. The goal of this organization is to “provide organizations a structured and behavioral language that will provide a simple way to understand and communicate cost, schedule, and performance design information to all stakeholders in a standard manner.” For those interested in ontology there is an OWL file available upon request.
  2. It can be used in any tool that has an open schema capability. That includes tools like DOORS, CORE/Genesys, Cradle, MagicDraw, etc. All they have to do is capture the information and then be able to create outputs with the data in these classes. These outputs can be in various forms, including CSV and XML formats. The committee is also working on APIs to enhance transferability to other tools and languages. 

DDSE and LML work together to better communicate the value of systems engineering. The future of systems engineering is data-driven, and SPEC Innovations is joining the future today!

About SPEC Innovations: Visit specinnovations.com and innoslate.com to see how we are taking a data-driven, MBSE approach.

About LML: Visit lifecyclemodeling.org for more information.