MBSE: Moving to a Data-Centric Practice of Systems Engineering

Guest Blog by Lou Wheatcraft of Wheatland Consulting, LLC

Today’s systems are becoming increasingly complex and software-intensive. Yesterday’s electro-mechanical systems had fewer interactions both internally and externally - interfaces could be shown on drawings. For these complex, software-intensive systems, internal and external interactions have increased several orders of magnitude as have the threats and vulnerabilities. Critical functions are carried out by the software - electro-mechanical parts of a system are “enablers” for the software.

This presents major challenges for organizations being able to effectively manage all the data, information, and artifacts across the lifecycle for these types of systems.

Historically, organizations defined and recorded the data and information associated with the various artifacts in the form of “documents”. As systems become more complex and regulated, the sheer volume of documentation has become overwhelming; especially in terms of configuration management, change control, completeness, correctness, and consistency. Because of the complexity, there are more people involved in the development of these systems spread over different geographical locations. This results in many of the documents being developed and managed within silos with limited collaboration.

Because of these issues, it is nearly impossible to keep all the data and information contained within the various documents in sync, current, correct, and consistent resulting in no real single source of truth (SSoT). For highly regulated systems, the amount of documentation that must be developed, maintained, and supplied to regulators to show compliance has become overwhelming. Inconsistencies in these documents can result in a system that fails system validation and that is not approved for use.

The cost and time overhead associated with managing a large number of documents consumes a large part of development costs. The time overhead results in longer development times and time to market for many systems, making a company less competitive and less profitable. Additionally, quality suffers resulting in post-system launch costs associated with increases in returns, recalls, warranty work, and company image degradation associated with negative social media comments – all of which also eat into profits. A highly regulated system that is not approved for use can result in a company’s stock price plummeting and, in some cases, the company going bankrupt. The old, 20th-century, document-centric approach is no longer effective for many of today’s systems of the 21st century. As a result, many organizations are seeking approaches to address these challenges.

An organization that is leading the move towards a better way is the International Council of Systems Engineering (INCOSE) of which I am an active member. As stated in INCOSE Vision 2025, “a constant theme throughout the evolution of systems engineering is the ever-increasing complexity of systems which can be observed in terms of the number of system functions, components, and interfaces and their non-linear interactions and emergent properties. Each of these indicators of complexity has
increased dramatically over the last fifty years and will continue to increase due to the capabilities that stakeholders are demanding and the advancement in technologies that enable these capabilities. This complexity presents organizations with challenges that need to be addressed. Failures can result in tremendous loss."

These challenges are a result of increases in:

• Complexity.
• The role software has in the system architecture (software-intensive systems are the norm).
• Dependencies and the number of interactions between parts of the system.
• The interactions between a system and the macro system it is a part.
• The number of threats across interface boundaries and vulnerabilities to those threats.
• Dependencies between project management and systems engineering.
• Dependencies between systems engineering lifecycle process activities and artifacts.
• Oversight.
• Competition.
• The pressure (and need) to reduce development time and time to market.
• Risks: program/project, development, manufacturing, system integration, system verification, system validation, and operations.
• The number of projects that are over budget and experiencing schedule slippage.

To address these challenges, we must find a better way how we practice systems engineering.

Key areas that need to be addressed in meeting these challenges include:

• Incorporate systems thinking into all phases of product development. Systems thinking involves thinking as all systems in terms of the behavior of the system as a function of the interaction of its parts as well as interactions between the system and its users, external systems, and the operating environment.
• Projects must manage the integrated system and associated systems engineering artifacts from the beginning with a focus on:
  • Interdependencies of the parts that make up the system.
  • Interactions – both internal and external.
  • Integrated system behavior and emerging properties as a result of those interactions.
  • Relationships between all the various systems engineering and product management artifacts
    across the system lifecycle.
• Understand the role of textual needs and requirements as well as diagrams/models and which form is best to communicate a specific thing.
• Establish traceability between all data and information across the system lifecycle.
• Move from a “document-centric” to a “data-centric” practice of systems engineering.

Out of this search for a better way, an approach referred to as Model-based Systems Engineering (MBSE) has emerged.

When introduced to MBSE, many organizations have several key questions: “Why should I move my organization towards MBSE?”, “Just what is MBSE?”, and “What is the real intent of MBSE?”

Why Should I Move My Organization Towards MBSE? A quick and simple answer is “To avoid the issues discussed above!” Less overhead, decreased time to market, higher quality, decreases in post-launch issues, fewer issues associated with a system being approved for use, increased profits, higher stock prices, and a growing company should be reason enough. However, there are several other fundamental reasons for adopting MBSE from a business strategic perspective: competitiveness and relevancy.

MBSE can be considered a technology. Like all innovative technologies, there is a spectrum concerning the rate of adoption. There are innovators, early adopters, early majority, late majority, and laggards. The late majority and laggards generally get left behind.

John Maudlin is an economist, venture capitalist, and investment advisor. He is extremely interested in investment opportunities concerning companies that are innovators and early adopters. In a recent article “Technology Rules” he states:

“….it’s remarkable how many industries and government agencies are still operating on ancient (as in the 1990s) technology, [just] muddling through.”

“... what happens when those organizations take off their old-tech handcuffs? They will run better and develop new capabilities they never had before. Customers, workers, and investors will all benefit.”

“Humans have a comparative advantage at higher levels of abstraction: creativity, intuition, and holistic judgments. Each is necessary. The best technologies do not automate complex problems, as many assume; they equip people to solve them faster and more effectively.”

With this perspective, it is hard to understand that given we are 22 years into the 21st Century, why do so many organizations continue to practice system engineering based on outdated 20th Century document-centric methodologies?

Another issue is relevancy. In a paper [3] presented at INCOSE’s 2021 International Symposium, the authors provided a quote attributed to Jack Welch of GE, “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.” This quote supports the idea that organizations' “rate of change must increase to match the rate of change in industry and the rapidly evolving technology universe.” In the increasingly competitive business world of today, the late majority and laggards face the prospect of becoming irrelevant. Hopefully, you now have a better understanding of why you need to adopt MBSE within your organization. But there is still the question “What exactly is MBSE?”

What exactly is MBSE? When asked to define MBSE, ask 20 people and you will get 20 different answers! There are several different perspectives: To some, MBSE is equated to the use of SysML and other language-based modeling tools to develop analytical, logical, behavioral, and architectural models to:

• Practice Model-based Design (MBD) starting with a set of design input requirements and using language-based modeling tools to architect and design a system to meet those requirements - ending with a set of design output specifications to which the system is built or coded.
• Use models to do the analysis needed to better define needs, design input requirements, architecture, and design.
• Use models to develop a “digital twin” and to run simulations to help mature a design and identify issues before the system is built or coded.
• Use models across all life-cycle stages as analysis tools to help ensure completeness, consistency, and correctness of the various systems engineering artifacts.

It is important to understand that MBSE is NOT SysML! MBSE is much more than just using language-based modeling tools to develop analytical, logical, behavioral, and architectural models. At the core of confusion is the word “model."

The INCOSE Systems Engineering Handbook (SE HB) states that “a model that represents a system and its environment is of particular importance to the systems engineer who must analyze, specify, design, and verify systems, as well as share information with other stakeholders. Different types of models are used to represent systems for different modeling purposes.”

In the INCOSE SE HB v4, the word “model” shows up over 680 times! The term is used to refer to the various visualizations of the data and information including analytical, logical, behavioral, and architectural models, textual descriptions, as well as documents, functional flow diagrams, data flow diagrams, interface diagrams, architectural diagrams, or drawings. In this context, a “model” can be any representation or abstraction of the system of interest (SOI) that best suits the purpose for which it was created. Thus, there are various kinds of models.

The common denominator of all these representations is that they are all visualizations of the underlying data and information that is used to construct and represent the system under development. Again, referring to the INCOSE SE HB:

“MBSE is often contrasted with a traditional document‐based approach to SE. In a document‐based SE approach, there is often considerable information generated about the system that is contained in documents and other artifacts such as specifications, interface control documents, system description documents, trade studies, analysis reports, and verification plans, procedures, and reports. The information contained within these documents is often difficult to maintain and synchronize, and difficult to assess in terms of its quality (correctness, completeness, and consistency).”

“In an MBSE approach, much of this information is captured [electronically] in a system model or set of models. The system model is a primary artifact of the SE process. MBSE formalizes the application of SE through the use of models. The degree to which this information is captured in models and maintained throughout the life cycle depends on the scope of the MBSE effort. Leveraging an MBSE approach to SE is intended to result in significant improvements in system requirements, architecture, and design quality; lower the risk and cost of system development by surfacing issues early in the system definition; enhance productivity through reuse of system artifacts; and improve communications among the system development team.”

Given there can be multiple types of models, and visualizations of the data and information in those models generated while progressing through the system life cycle processes, a 10,000-foot level view of systems engineering from a data-centric perspective is needed to help understand the context in which various artifacts and their underlying data and information are generated and used. An MBSE approach to system engineering uses various types of models and visualizations of the data and information in those models to help stakeholders better understand the context in which various artifacts and their underlying data and information are generated and used while progressing through the system lifecycle.

What is the Real Intent of MBSE? MBSE is not really about any particular type of model or visualization of data and information – whether that be a model, diagram, report, or document – but is about the underlying data and information. MBSE enables system engineers to establish consistency, completeness, and correctness of the underlying data and information that represents the various models and visualizations.

The data and information model that must be developed must represent all the SE artifacts generated during the system development process activities across all lifecycle stages. Thus, information associated with the elicitation of stakeholder needs and requirements, lifecycle concept definition, analysis, and maturation, deriving an integrated set of needs, and transforming those needs into sets of design input requirements, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages as well as help assess the impact of changes made to any of the data items. Design inputs must be traceable to design outputs.

The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of systems engineering so as to realize the real intent of MBSE. From this perspective, the true intent of MBSE is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system lifecycle process activities, resulting artifacts, and their underlying data and information.

“MBSE, from a data-centric perspective, involves the formalized application of shareable sets of data to represent the systems engineering work products and underlying data and information generated to support lifecycle concept maturation, needs and requirements definition, design, analysis, and verification and validation activities throughout the system lifecycle, from conceptual design to retirement.” [1]

With this data-centric perspective of MBSE, the capability to capture, manage, access data, and manage the interrelationships between systems engineering work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map/index) of disparate data sources. This data and information is captured using a variety of systems engineering tools and applications.

INCOSE INCOSE-TP-2018-001-01, 2018, Integrated Data as a Foundation of Systems Engineering, prepared by the Requirements Working Group

To effectively manage our ever-increasing complex, software-intensive systems, there are benefits to managing this underlying data and information in such a way it can be shared across the system lifecycle process activities, shared between the various systems engineering tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex, software-intensive systems as well as enable collaboration between not only the project team members but also external stakeholders involved in the development of the system.

The practice of systems engineering is often viewed from many perspectives. Similar to the old story of the blind men and the elephant, systems engineering cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry-specific application, etc.). To successfully practice systems engineering, wise systems engineers recognize and use each perspective as appropriate to the activity they are performing. Based on their needs they choose the appropriate tool and visualization that will meet their needs.

The degree to which the data and information is captured and managed is driven by the needs of the organization and projects from a business and technical perspective based on the size and complexity of their programs, product line, culture, processes, workforce, diversity, and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.

Benefits of Implementing Systems Engineering from a Data-Centric Perspective [1]

A data-centric perspective of systems engineering complements the system lifecycle process activities by enabling the opportunity for system development with increased quality, lower cost, lower risk, and shorter development times. Adopting MBSE and implementing a data-centric perspective enables organizations to realize the following benefits:

• Meet the challenges associated with increasing complexity for current and future systems discussed previously.
• Provide greater consistency of all artifacts and work products because any single piece of design data and information can be expressed authoritatively within integrated/federated, shareable sets of data that can later be referred to by others for decisions or the formation of other work systems.
• Provide better visibility into the principal characteristics of the whole, integrated system because multiple views from the data and information model can be created that succinctly address specific stakeholder needs, concerns, and interests.
• Provide greater congruence and configuration management between documentation and reality. Differing views of the underlying data and information model can be automatically generated into engineering artifacts, reducing the effort to keep the artifacts and their underlying data and information up to date and consistent, resulting in artifacts that match the best available, current data and information.
• Establish a Single source of truth (SSoT). SSoT represents the official state or baseline version of data and information model—regardless of what someone says or thinks, no matter what they “remember” or what perspective they have concerning what is being done or built or a decision that was made, if it isn’t in the project’s configuration managed, data and information model, it isn’t the truth. (Requires all the underlying data and information to be configuration managed and kept current and consistent.)
• Facilitate the navigation, traceability, and interrogation of data and information across all system lifecycle stage activities. Managers and engineers can have access to the correct, complete, and consistent data and information more quickly, and on an as-needed basis, without going through manual distribution or search processes.
• Enable the reuse of systems engineering and project management artifacts and underlying data and information. Considerable time and expense can be saved when an organization can reuse SE and PM data and information and not have to start from scratch for each new project (brownfield systems). This reuse ability is key to effective product line management.
• Facilitate the management of the stakeholder needs, requirement definition, design, build/code, and system verification and system validation activities in an integrated, consistent manner. Data and information associated with verification and validation activities across all system lifecycle process activities can have higher quality and provide greater insight concerning the status of verification and validation activities. This makes it easier to show compliance and that stakeholder needs are being met.
• Reduce the costs associated with the erroneous design and resulting rework. Analysis of the systems engineering artifacts and work products and underlying data and information can reveal a flaw or inconsistency as soon as it is created, enabling correction before downstream work is done, work that would be invalid, and costly and time-consuming to correct if the upstream mistake were not corrected immediately. This also helps to avoid huge expenses associated with recalls, returns, warranty work, and negative comments on social media.
• Facilitate the identification of interactions (interfaces), helping to ensure the system of interest can be successfully integrated into the macro system it is a part of and reducing integration issues and costly rework and schedule slips associated with these issues.
• Provide identification, management, interoperability, and integration of artifacts and work products and their underlying data and information across business or organizational elements needed to support program budget and schedule goals. For example, with the ability to metatag data, information, and work products, they can directly be linked to the WBS, budget, schedule, and risk management activities.
• Ensure data and information needed by programs and projects (e.g., for milestones, gate reviews, mission operations, risk mitigation, and anomaly investigations, decisions, and outcomes) are identified and managed to provide traceability of the data and information used in decision-making.
• Use measures to better manage systems engineering activities across all system lifecycle process activities. Measures allow managers and systems engineers to monitor trends, assess progress, and identify issues to help ensure the system being developed will meet stakeholder needs and expectations.

Systems Engineering Toolset

Choosing the appropriate systems engineering tool set is critical for organizations to move to a data-centric practice of systems engineering. This toolset and associated processes enable:

• Development, management, and configuration control of all systems engineering artifacts and associated data and information across the lifecycle.
• Management and assessment of change across the lifecycle.
• Management and control of risk across the lifecycle.
• Compliance with standards and regulations.
• Establishment of a Single Source of Truth (SSoT).

Key Features of the Systems Engineering Toolset

In order to do these things and realize the benefits of moving to a data-centric practice of SE, the SE toolset should have the following capabilities.

• Ability to manage needs, requirements, risk, verification, and validation artifacts in one place.
• Ability to establish end-to-end traceability of data and information across the system lifecycle.
• Support increased collaboration and more effective communications between geographically separated team members.
• Allow data to be shared with other tools in the systems engineering toolset.
• Allow data to be linked to artifacts generated by other tools in the SE toolset.
• Quick and easy implementation.
• A short learning curve, is easy to use, and has an intuitive user interface.
• Customizable by the user to fit the organization’s product line, processes, and culture.
• Provide robust reporting and dashboards that provide management insight into the up-to-date status of the system development activities across the lifecycle.

Parting Thoughts

In order to effectively develop today’s increasingly complex and software-intensive systems and avoid the many negative consequences of the outdated document-centric practice of systems engineering, organizations must move to a data-centric practice of systems engineering which is the real intent of MBSE. Organizations need to develop a level of organizational systems engineering capability that will enable them to realize the benefits listed above.

Since one size doesn’t fit all, an organization needs to assess the systems engineering capabilities that best fit its domain, system line (degree of complexity), and culture. The level of systems engineering capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects.

Based on the needs of the organization and the level of systems engineering capability they choose, organizations need to choose the appropriate systems engineering toolset, update their processes, and train their people in these tools and processes

References

[1] INCOSE INCOSE-TP-2018-001-01, 2018, Integrated Data as a Foundation of Systems Engineering, prepared by the Requirements Working Group, INCOSE.
[2] INCOSE-TP-2010-006-03, 2019, Guide to Writing Requirements, prepared by the Requirements Working Group, INCOSE.
[3] S. Sheard, M. Bouyaud, M. Osaisai, J. Siviy, K. E. Nidiffer; A Guide for Systems Engineers to Finding Your Role in 21st-Century Software-Dominant Organizations, Technical Paper presented at IS2021
[4] Wheatcraft, L., Ryan, M., Dick, J., Llorens, J., 2019. “The Need for an Information-based Approach to Requirement Development and Management”, paper and poster presentation at INCOSE IS 2019.

Biography
Lou Wheatcraft is a senior consultant and managing member of Wheatland Consulting, LLC. Lou is an expert in systems engineering with a focus on needs and requirements development, management, verification, & validation. Lou provides consulting and mentoring services to clients on the importance of well-formed needs & requirements helping them implement needs & requirement development and management processes, reviewing and providing comments on their needs and requirements, and helping clients write well-formed needs & requirements.

Specialties include: Understanding and documenting the problem; defining project & system scope; defining and maturing system concepts; assessing, mitigating, &
managing risk; documenting stakeholder needs; transforming needs into well-formed design input requirements; allocation, budgeting, and traceability; interface management, requirement management; & verification and validation.

Lou’s goal is to help clients practice better systems engineering from a needs & requirements perspective across all life cycle stages of system/system development. Getting the needs & requirements right upfront is key to a successful project. Poor needs & requirements can triple the chances of project failure.

Lou has over 50 years of experience in systems engineering, including 22 years in the United States Air Force. Lou has taught over 200 requirement seminars over the last 21 years.
Lou supports clients from all industries involved in developing and managing systems and systems including aerospace, defense, medical devices, consumer goods, transportation, and energy.

Lou has spoken at Project Management Institute (PMI) chapter meetings and INCOSE conferences and chapter meetings. Lou has published and presented many papers concerning needs and requirements for NASA’s PM Challenge, INCOSE, INCOSE INSIGHT Magazine, and Crosstalk Magazine. Lou is a member of INCOSE, past Chair and current Co-Chair of the INCOSE Requirements Working Group (RWG), a member of the Project Management Institute (PMI), the Software Engineering Institute (SEI), the World Futures Society, and the National Honor Society of Pi Alpha Alpha. Lou has a BS degree in Electrical Engineering from Oklahoma State University; an MA degree in Computer Information Systems; an MS degree in Environmental Management; and has completed the course work for an MS degree in Studies of the Future from the University of Houston – Clear Lake