Recently many systems engineers have questioned whether MBSE is the best approach for their projects. Although MBSE is designed to reduce complexity, the common modeling languages (SysML and UML) leave important stakeholders, who are usually outside of the systems engineering community, confused. These modeling languages create a communication barrier between the systems engineer and their client. Systems engineers have designed notations to interpret the results of the modeling languages to their customers, but this adds more complexity for stakeholders. Many systems engineers confuse the modeling language and the MBSE approach. Ultimately, it is SysML and UML that causes this divide and decrease the productivity of the project, not the MBSE approach.
Among other technologies, the approach to systems engineering has evolved with the advancement of personal computers. Before anyone had personal computers in the workplace, systems engineers overwhelmed themselves with tracking data in their paper notepads. There would be numerous occasions of when I would find myself in a room with other systems engineers exchanging data, sometimes large amounts, with handwritten notes. When the personal computer became available, we quickly started using programs such as Word, Excel, and PowerPoint to document our work. While this was a great alternative, software developers were already developing MBSE tools that would ease our transfer of data, support MBSE principles and manage databases. MBSE tools have drastically improved our methods in MBSE and are now considered the primary standard within the systems engineering discipline.
Software tools for MBSE have improved the quality and productivity of current systems engineering work flows. Instead of tracking information in notebooks or word documents, MBSE software tools keep the information in a database and then auto-generate reports for you. MBSE allows for better traceability. For example, we used to build “as built” diagrams to keep record of system changes. Due to the amount of effort and time the “as built” diagrams required, many of us opted out of making them causing issues later on in the lifecycle. Software tools make sharing large amounts of information easier with collaboration features. Risks are decreased, because the software tools give us a better method of estimating cost. Validation and verification are ongoing throughout the lifecycle of a project rather than at the end. Overall, MBSE software tools reduce the complexity of a systems engineering project.
Despite all the benefits, the MBSE approach has come into question. Many systems engineers do not understand the advantages this approach gives them. Much of the reason for this is the lack of separation of the MBSE approach and the modeling languages. SysML especially causes confusion for important stakeholders, due to its overly complex language. Modeling languages can change and improve over time. SysML, based on its predecessor UML, which is still used today, only recently became an open standard. The increased use of SysML and the recent concerns with MBSE are most likely related.
Systems engineers can become frustrated and overwhelmed with how UML and SysML constantly change, which makes it more difficult for the systems engineer to be productive and efficient in developing their projects and keeping them from being too complex for the stake holder. We now have yet another open standard modeling language, Lifecycle Modeling Language (LML). LML reduces complexity for all stakeholders and increases the productivity and communication of a project by simplifying the language. However, systems engineers have to learn another language. The steep learning curve may not seem worth the improvements, but like most professionals we have to learn and grow within our field. If medical practitioners were not abreast with new research and technology, the medical field would never improve. Systems engineering is no different. If the stakeholder and systems engineer can understand the concepts of the project with little explanation, then learning a new language might well be worth the sacrifice of its steep learning curve and breaking away from the complexities of UML and SysML.
As systems engineers we cannot let the inefficiency of a modeling language distract us from using an effective approach. Modeling languages can always be improved upon as new technology comes along. SysML improved on UML by including non-software components and decreasing its size. LML improves SysML by decreasing the SysML’s complexity and confusion for non-systems engineer stakeholders. The modeling language and the MBSE approach are separate, but must be used together to work. Systems engineers should not be deterred from using the MBSE approach, but continue to adapt and explore other languages that are more effective in communicating information to the stakeholder.