Redefining the Future of Systems Engineering

The International Council on Systems Engineering (INCOSE) recently published its “Vision: 2035” document. While discussing the theme with another INCOSE member, he asked me what I thought about it. I thought briefly and said, "By 2035, we won't use the term MBSE (Model-Based Systems Engineering) for our abilities."

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 at its highest point of hype, we can expect a bumpy ride into disappointment. Moving past the 'Slope of enlightenment' and reaching the 'Plateau of productivity' indicates progress. Early adopters will have a competitive advantage sooner. This author feels optimistic that the historical perspectives presented in this paper defend the latter placement.

If that was true in 2011, then where are we in 2022? Perhaps MBSE should be leading systems engineering today rather than in 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 pushed as a counterpoint to the “document-based” systems engineering of the 20th Century.

The issue is the models' ability to help 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?

Decision-makers want to see large amounts of data from various detailed engineering analyses transformed into information. Doing this allows them to easily make decisions.

If we want to get “buy-in” from senior managers, we must communicate to them in a language they can understand. 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 doesn't focus solely on models. It needs a language that captures data associated with the system while including 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). LML improves state-of-the-art tools that have proven the capability needed to capture the data. It also presents it in a form that communicates well to all audiences.

There are 3 reasons why I believe LML is the language for DDSE: It was created for and by Systems Engineers, it's an open standard, and it can be used in any tool with an open schema.

Systems engineers designed LML for systems engineering and program management. The group that put this specification together drew from decades of experience in these fields. They looked 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.

In the figure below, you can see 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.4 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. This version would add 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.

It’s an open standard. LML is under the governance of the Lifecycle Modeling Organization (LMO) in section 501(c)(3). LMO was an outgrowth of the original LML Steering Committee.

The standard is non-proprietary and taught in over 200 schools around the world. The goal of LMO 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 LML, check out the specification details and other available downloads.

It can integrate with 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, then they can 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!