My initial intention for this blog was to talk about what I describe as MBSE tool maturity levels. And I will surely get around to those levels. But first I think it is important to draw attention to the definitions of MBSE that experts use and offer some observations that might be helpful to those who are beginning their own MBSE initiatives.
What is MBSE?
The International Council on Systems Engineering (INCOSE) describes MBSE as the “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through-out development and later lifecycle phases.” This is simple enough to digest and the only noticeable difference between it at their definition of systems engineering is the reference to “formalized application of modeling.” They do not however, define what “modeling” means.
NASA says MBSE “involves applying software-based tools to capture systems engineering evidence — typically called “artifacts” — in a systematic, disciplined way that allows people to manage complexity while communicating effectively across the life cycle of a system.
MBSE is to perform systems engineering – connects system relationships
Controlling system configurations
Communicates an overall system picture accessible to all
Makes it easier to integrate disparate material
Ensures everyone is working on the same up to date material at all times
NASA’s definition certainly provides a good deal of information, but they don’t even use the word “model” in their description. Lenny Delligatti, one of the most respected MBSE experts in the world wrote that, “A modeling method is something like a road map; it’s a documented set of design tasks that a modeling team performs to create a system model. More precisely, it’s a documented set of design tasks that ensures that everyone on the team is building the system model consistently and working toward a common end point. Without such guidance, there will be wide variance in the breadth, depth, and fidelity that each member of the team builds into the system model.” What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system.” These definitions are super informative.
An observation I have is that organizations instantly equate MBSE with the use of a SysML tool. The experts tell us however, that MBSE is the combination of methods to create a representation. None of them say that to perform MBSE one must adopt a graphical modeling tool. There are many different methods to create models/representations. Some are graphical and some are textural. At the heart of MBSE is the drive to move from static documents (Word and Excel) into an information-based paradigm. The table below eloquently articulates the differences and standout benefits of using an MBSE approach.
There are certainly many organizations that are still performing systems engineering only using documents. For the rest, there are a plethora of tools in the ecosystem used to create models including tools that support SysML. To begin the journey of MBSE, you don’t have to adopt a SysML tool right away. Maturity of MBSE is still young. Very few organizations do it for a program in an end-to-end manner. The learning curve is steep. Generally, a few engineers become the “scribe” and then end up translating to the extended team. And keep in mind a systems engineer is a “cat herder.” This person is the one who sees the big picture, understands the problem, and is the translator across engineering domains and the business. A SysML tool won’t be the only tool in their arsenal.
This finally brings me to describing MBSE tool maturity levels. Many organizations are already performing MBSE without even calling it MBSE just by the tools and processes they use in the organization. Level 0 is what I describe as only using documents and having no model representations at all. Level 1 is barely a step up from level 0 but the have a requirements tool in place or possibly a Kanban board that is capturing loosely coupled relationships between data. Level 2 is where teams are now combining the use of the RM tool with diagrams. Perhaps they are drawing diagrams in Visio or a UML tool. Level 3 is the combination of requirements, architectures, diagrams are used in conjunction with a defined methodology for how the information is defined, related, and analyzed. The tool will programmatically constrain the data in order to provide consistency as well as provide the mechanisms to define once and then reuse. Level 4 tool maturity is where organizations use a requirements tool and SysML tool.
Jama Connect aligns as Level 3 maturity. Customers who use Jama Connect experience their requirements becoming a source for strategic information during all stages of the system lifecycle. Requirements are turning into actionable data. The software world with its mass adoption of agile practices is trickling into the systems space and requirements now take different shapes. MBSE takes more than use of a language-based graphical modeling tool. Even for a Level 4 maturity, natural language is still the great common denominator. Not everyone will be an engineer and able to interpret models. Requirements and the structured architecture within Jama Connect provides the necessary context. Jama Software’s Traceable MBSE™ approach can be seen as the bridge one uses to leave behind documents and move towards Level 4 maturity.
Last month we held a webinar on model-based systems engineering titled, “MBSE Easy, Overcoming Organizational Challenges.”
This webinar was well received by our customers, and we wanted to make sure nobody missed out on this great content. Below, you’ll find a recording of the webinar and an abbreviated transcript.
Shifting to MBSE is an Organizational Paradigm Shift
An organizational paradigm shift from document-centric to model-based systems engineering (MBSE) can be daunting. The learning curve for systems engineers can be steep and the return on value is not often immediately apparent. In this webinar, I will explore some of the most common MBSE challenges and tactics to help teams eliminate the barriers to broader adoption. I will also illustrate how Jama Connect can be used to streamline a collaborative data-driven approach and provide more immediate systems engineering value to larger numbers of stakeholders. The agenda topics that we’re going to go over today are benefits of MBSE to the broader stakeholder community, best practices for cultural adoption, the expected return on value, keys to eliminating documents and then using Jama Connect to facilitate the implementation of MBSE.
The Benefits of MBSE – Specifically Human Understanding
To help us understand the benefits of MBSE to a broader stakeholder community, let’s talk about what it is used for. MBSE in the words of industry leaders like INCOSE, NASA, or Gartner Research describe it as “facilitating understanding or providing aid to decision-making, connecting system relationships, controlling system configurations, providing communication of an overall system picture that’s accessible to all.”
It ensures everyone is working on the same up-to-date material at all times. I see a theme here. Many of these are very human-centric. MBSE is designed to take that complexity and allow it to be consumed and understandable by everyone. From a technical standpoint, configuration control, versioning, relationship management are some of the keys. Why MBSE? Human understanding, decision-making, relationship management, configuration and version complexity management are just not things you can easily achieve when you mire yourself in documents.
In a document-based world, engineers might be manually searching documents, manually managing a section number heading scheme in the document, it might be creating siloed trace information and spreadsheets. They might not know where the latest version of a particular document is or who might have even changed the document last. They might be relying on a single person who is the tool guru because the tool is old and too hard to learn how to use. They might be spending hours or days cross-referencing many data sources just to determine an impact change or consider a trade-off. Here we are in 2021 and still, so many of us are kind of swimming in the sea of documents. Mechanical engineering, electrical engineering, and even software engineering, these disciplines have been using models for decades, right. Now, having the best information at the system level is critical. What we need is a paradigm shift away from documents and a shift in the way you think.
The Benefits of MBSE for the Broader Stakeholder Community
The benefits of a paradigm shift from documents to data that MBSE brings is not merely for the systems engineer to reap. The new ways of thinking about the system being developed and the new structure of the data itself benefits everyone. I’d argue that the system view is the most important view of all. I think most of you are systems engineers out there and I think you tend to agree. MBSE allows engineers to work successfully at greater levels of complexity. It also improves the communication between the technical communities as well as the business and even the customer. It provides visibility of the gaps that you might have, errors, misalignments of the system design — those kinds of problems might result in defects in the system or cause design rework or cause missed requirements or even dropped requirements. Some of the MBSE challenges — there are challenges out there with adopting MBSE.
The Unique Challenges of MBSE – And Tips for How to Solve Them
The benefits that MBSE promises do present some of these unique challenges to those who are beginning their MBSE journey. The learning curve can be steep. Learning the language of SysML and maybe your chosen modeling tool takes a long time. This learning curve can’t be done in silos or via tutorials. The learnings need to be backed by your experience. Organizations need to adopt strategies for not just how their systems engineers are trained but how they will use MBSE and then how they need to adopt strategies for how the entire organization works and communicates in that paradigm.
Overcoming Organizational Resistance to Change
Organizational changes are often met with resistance to change. Change has to start at the executive sponsorship level. I think that goes without saying — any organization adopting any kind of change really needs an executive sponsor. That executive sponsor needs to demonstrate their leadership with their actions. MBSE lip service won’t work. They have to be involved and they have to demonstrate that they’re willing to make the changes themselves.
MBSE isn’t necessarily a one-size-fits-all either. The method and extension of the methods needs to be adapted to the actual system of interest that’s being developed. Systems also need to be developed with modularity and reusability.
Many of the challenges to adoption are human factors and they might be the easiest to mitigate by perhaps simplifying your tools and your approach. Misaligned teams struggle to overcome those cultural boundaries to develop the services and products. MBSE is not something that just the systems engineering team does but it’s a technique. It’s similar to the Agile method, it’s something that the entire organization embodies. It requires that change in culture in order to adopt.
Moving from a documents-based approach to MBSE doesn’t have the be daunting. Start small. Put aside doing day-to-day work in the documents and have everyone across the team access data in your chosen MBSE solution. Even if you don’t have a dedicated SysML tools, you can perform MBSE by creating lists or drawings that capture architectures and behaviors.
In many cases, it takes time to fully adopt MBSE and engineers might feel insecure. Moreover, implementing MBSE is not about just using the tool, it’s about understanding what to model, why, and for which outputs. Again, that comes with experience. Don’t bite off more than you can chew. Don’t just roll out your SysML tool and expect to be doing MBSE. That just doesn’t work. Try to leverage web-based tools that provide more stakeholders a consumable view of the information that maybe they would regularly see in documents.
If tools are becoming your focal point, make sure that they are usable and do provide value across the teams. Communicate the MBSE return on value to them. Communicate the return on the value back to your leadership team. Systems engineering, unlike software or electrical or mechanical engineering doesn’t have that output that’s tangible to the customer. Leaders need reminding of the value that MBSE is delivering.
Download our new whitepaper, A Path to Model-Based Systems Engineering (MBSE) with Jama Connect, to learn more about digital engineering & MBSE benefits, obstacles, and success factors.
The Benefits of Collaboration for Government and Defense Teams
Tomorrow’s defense and government systems must be built at a lower cost with shorter timelines often using new Agile acquisition strategies. Since government and defense program teams are largely comprised of civilians and contractors working in distributed locations, efficient and streamlined collaboration is crucial.
In 2018 the US Secretary of Defense encouraged everyone to adopt new practices in order to modernize delivered systems and prioritize the speed of delivery. This encouragement was backed by a Digital Engineering Strategy with aims to allow the DoD and industry partners to work more collaborative at the engineering level. They defined digital engineering “as an integrated digital approach that uses authoritative sources of system data and models as a continuum across disciplines to support lifecycle activities from concept through disposal.”
Expected benefits of digital engineering include:
Better informed decision making
Enhanced communication
Increased understand of and confidence in the system design
A more efficient engineering process
Jama Connect’s digital mission engineering platform has been specifically designed to assist in reaping these benefits. The platform’s core functionalities – including requirements version control, change management, baseline management, traceability, verification and validation, and risk analysis – are enhanced with a streamlined collaboration capability that establishes alignment across teams working within complex government programs.
Jama Connect lets government programs leverage lean, information-driven lifecycle techniques for managing strategic objectives, requirements, Agile user stories, features, risks and more.
Two qualities that set Jama Connect apart from the competition include:
Distributed government and defense teams must consider ease of adoption and usability when researching requirements management (RM) solutions. Our customers confirm that if engineers and stakeholders don’t find a system intuitive and accessible, acquisition and implementation can be a costly miscalculation. Jama Connect is built and maintained with high-fidelity usability as the guiding principle.
Many requirements management tools require users to achieve unrealistic levels of expertise or otherwise hire expensive experts who fit the criteria. Consequently, most teams end up working outside the system using documents and spreadsheets. The result: A requirements and traceability ordeal that slows the development cycle, introduces unnecessary amounts of risk, and defeats the purpose of having a dedicated RM tool.
The Benefits of Collaboration in a Modern Requirements Management Platform
Requirements management in Jama Connect eliminates reliance on documents and supports rapid delivery of complex, workable systems by bridging all the teams and work in real-time. The result is the connection of a multitude of interacting subsystems with a robust digital thread.
Jama Connect provides a modern solution that transforms system development into a transparent, measurable, and controlled systems engineering discipline. With industry-leading competence in an enterprise-class platform that is rapidly adaptable to the unique needs of each organization, Jama Connect is an analyst-recognized leader in the requirements management market, delivering unmatched value in each of the following areas:
Requirements Engineering: Our web-based application provides the ability to intuitively author requirements, maintain versions, control change, baseline, and collaboratively review and approve.
End-to-End Traceability: Link and decompose program-level capability requirements and operational requirements to derived system requirements, and then down to lower-level software and hardware requirements.
Change Management: With fine-grain impact analysis providing instant data insights, you can make informed decisions as requirements evolve during long development cycles or shift in mission, cost, or technology.
Fast Reviews & Approvals: Share and gain consensus on acceptance criteria by leveraging higher levels of stakeholder collaboration among government, suppliers, and subcontractors.
Virtualized Control Boards: Built-in collaboration technology lets teams capture all communication in a central system alongside system data. Items linked to related conversations, questions, and reasoning can be reviewed throughout development and archived after.
Quicker, Clearer Decisions: Request decisions on changes within the context of the items and projects. Transparent decision-making gives you immediate clarity and saves time.
Risk Management: The pressure to develop systems with lower costs, shorter timelines, and agile acquisition never stops. Jama Connect provides a voice across acquisition, development, and integration teams to collaboratively define, validate, and verify risks and ensure that they are accounted for and mitigated in the earliest stages of development.
Verification & Validation: Seamlessly manage traceability between requirements and test cases used for verification & validation and provide evidence to comply with regulations and standards.
To learn more about how Jama Connect supports digital engineering and collaboration for Government and Defense teams, download our whitepaper.
In today’s age of digital transformation, most product development teams are experiencing an issue of burgeoning software content causing immense effort and complexity to understand, write, design and validate, and produce. Digital engineering (DE) is a broader movement that takes shape in many industry segments such as medical device development, automotive, defense, consumer electronics, and aerospace to reduce the pains of developing new products, systems, and software. But, differences in maturity and methods sometimes make understanding the true state of DE difficult.
DE is an integrated approach that uses authoritative sources of system data and models (instead of documents) as a continuum across disciplines to support lifecycle activities — from concept through disposal. In the simplest of terms, it is the act of creating, capturing, and integrating data using models and innovative technology in an orchestrated manner in order to unlock greater value and provide positive impacts on cost and schedule. It is the system model for which MBSE is useful.
When developing avionics weapons systems, a document-based systems engineering process is inefficient and lacks an authoritative source of truth. Meeting the demands of modern development allows more teams to be connected to the design and engineering process. This allows everyone to have a clear understanding of the big picture and leads to better informed decision making, enhanced communication, increased understanding of and confidence in the system design, and a more efficient engineering process.
Meeting Market Challenges and Managing Complexities with MBSE
Model-based systems engineering (MBSE) has been a popular topic in the systems engineering community for over a decade, but the level of movement or path towards implementation has not always been clear. Market forces are increasing the demand and urgency for organizations to implement the MBSE discipline across the enterprise.
Across industries including aerospace, transportation, industrial manufacturing, and healthcare, customer demand for new, complex, and interconnected products, systems, and software is ever-increasing — and these systems must now be smarter, safer, and more environmentally friendly — all while remaining affordable.
For teams using a cumbersome, and often disparate document-driven approach, facilitating a common understanding of complex systems across diverse stakeholders can often be problematic. To stay competitive, companies building these complex systems require a solution that reduces time and effort by providing an MBSE approach where the combination of collaboration, modeling, tools, and methods streamlines the end-to-end systems engineering process.
A good MBSE practice will prevent rework due to poorly developed requirements or lack of communication across engineering teams. It will help to eliminate risks by providing an architectural roadmap that makes it easier to visualize and provide validation checks.
Customers will be happy with the system delivered and report fewer complaints because the application of MBSE has enabled the teams to more easily perform requirements analysis and validation to ensure that what is being designed and built is solving the correct problems that the customer has.
To manage increasing complexity, engineers and stakeholders must use tools (like Jama Connect™) and techniques whose data is both human-readable and has the capability to integrate across the ecosystem. The challenge is having the ability to efficiently design and build as well as effectively collaborate across stakeholders with vastly different engineering disciplines (e.g., software, mechanical, materials, electrical, chemical, environmental). Each subsystem needs to interoperate with the others to achieve the expected system function, adhere to safety and/ or government regulations, and ultimately meet the customer’s requirements.
Download our new whitepaper, A Path to Model-Based Systems Engineering (MBSE) with Jama Connect, to learn more about digital engineering & MBSE benefits, obstacles, and success factors.
Digital engineering is an integrated approach that uses authoritative sources of system data and models as a continuum across disciplines to support lifecycle activities from concept through disposal. In the simplestof terms, it is the act of creating, capturing, and integrating data using models and innovative technology in an orchestrated manner in order to unlock greater value and provide positive impacts on cost and schedule.This integrated approach means that the datafrom the digital models such as CAD models, electrical circuit models, system models, and software models as well as the domain discipline processes are orchestrated tightly. Hardware, systems, and software engineers are now working much more closely to design and develop systems.
Digital engineering is a movement that takes shape in many industry segments such as medical device development, automotive, defense, consumer electronics, and aerospace to reduce the pains of developing new products. The U.S. Department of Defense (DoD) has a poor track record of fielding new systems on time and within budget. Acquisition teams are mired in antiquated processes and are risk averse to attempt improvements if it causes too much organizational friction.
The DoD has recognized its deficiency and has identified the following challenges with their current acquisition engineering process:
It has a linear acquisition process that is not agile or resilient
Stakeholders use stove-piped infrastructures, environments, and data sources to support various activities throughout the lifecycle
Communication, collaboration, and decisions happen through static disconnected documents and subject to interpretation
The existing practices are unable to deliver technology fast enough
The Drive for Evolution in Engineering Practices
Kristin Baldwin, Acting Deputy Assistant Secretary of Defense for Systems Engineering,wrote that, “In this era of rapid growth in technology, information, and complexity, we need to evolve our engineering practices. This evolution incorporates advancements in our engineering methodologies (methods, processes, and tools) to enable data-driven decision-making throughout the acquisition lifecycle.”
In 2018 the US Secretary of Defense encouraged everyone to adopt new practices in order to modernize delivered systems and prioritize the speed of delivery. This encouragement was backed by a Digital Engineering Strategy which aims to allow the DoD and industry partners to work more collaboratively at the engineering level.
DoD’s Expected Benefits of Digital Engineering
Expected benefits of digital engineering include better–informed decision making, enhanced communication, increased understanding of and confidence in the system design, and a more efficient engineering process
The Top Five Goals of DoD’s Digital Engineering Strategy
Formalize the development, integration, and use of models to inform enterprise and program decision making
Provide an enduring, authoritative source of truth
Incorporate technological innovation to improve the engineering practice
Establish a supporting infrastructure and environments to perform activities, collaborate, and communicate across stakeholders
Transform the culture and workforce to adopt and support digital engineering across the lifecycle
There is a dire need to reduce the red tape without compromising the federal laws of oversight.
Smart Systems Engineers
A systems engineer’s primary job is to work with the end users who are paying for the product. They have “operational requirements” that must be satisfied so that they can meet their mission needs.
The current vision for the past decade has been to leverage Model Based Systems Engineering (MBSE) and use models to analyze and manage those requirements to ensure they are met at the end of the product development.
The systems engineer becomes the translator from the electrical engineers to the mechanical engineers to the computer scientists to the operator of the system to the maintainer of the system to the buyer of the system. Each of these teams speaks a different language.
The idea of using models was a means to provide communication in a simple, graphical form yet, only a tiny percentage of programs have demonstrated MBSE’s utility to achieve this vision. Smart systems engineers today recognize that models need to be expressed in more consumable formats to the broader stakeholder community so that communication and collaboration can take place.
Jama Software’s Digital Engineering Bridge
Jama Connect helps satisfy the DoD Digital Engineering Strategy’s first goal (formalize the development, integration, and use of models to inform enterprise and program decision making) by acting as a digital engineering bridge that connects the model world with the document world.
Time consuming and error prone methods of data consumption via documents, spreadsheets, and legacy requirements tools introduces program risk and increases cycle time to the program timeline.
JamaConnect’s unique user interface (UI) allows non-technical stakeholders to visualize a model of the system of interest and interact with the requirements in familiar views like documents and spreadsheets.
The Benefits
Whether Jama Connect is used in conjunction with MBSE SysML models or used as a standalone digital engineering platform, the system provides:
Visualization of the shared system model and the status of its artifacts in the development lifecycle
System and behavioral diagrams
Faster requirements development
Verification and validation of requirements developed in the model
Mechanisms for broader audience communication and participation – tool specialists are not needed
Baselining of requirements
Requirements attribute management and workflow
Requirements decomposition and tracing
Specialized document generation and data reporting
Using Jama Connect in the application of MBSE to create models is supported by a series of pre-defined views and its underlying relationship ontology which enforces the rigor and consistency demanded by the framework.
Jama Connectcan be used in conjunction with dedicated SysML tools or as a standalone system. In fact, the data in Jama Connect is organized much in the same fashion as that in a modeling tool and performs many of the same functions. This is what makes it very attractive to organizations that do not have enough staff trained to use dedicated SysML graphical modeling tools.
What Are Requirements in Jama Connect?
From a big picture perspective, requirements themselves are the digital thread that connects the stakeholders stated needs and constraints to the system, hardware and software design that articulate to developers what must be developed. The notion that a “document” needs to exist for requirements to be captured and managed is a paradigm that the Digital Engineering Strategy is meant to eliminate. Jama Connect and modeling tools maintain requirements as atomic, individual objects that can then be consumed by all engineering disciplines in their own fashion. The overhead of maintaining documents just so they can be communicated to non-technical stakeholders is eliminated.
There is also misconception that requirements engineering is performed only by systems engineers. A more agile approach to requirements engineering is when all stakeholders are validating requirements as they are being written (or as close to real time as possible). But this is difficult since a SysML model requires a specialist with many months of technical training to be able to read and understand. By using Jama Connectinstead of documents or legacy requirements tools, the primary means for communication moves away from static and disconnected documents and shifts the paradigm to models and data serving as the basis for connecting traditionally siloed elements—providing an integrated information exchange throughout the lifecycle.
Authoritative Source of Truth?
The DoD has used the phrase ‘single source of truth’ for decades, so much so that it has become the butt of ridicule. Misaligned tools and processes foster data to be stored in documents since that is the only medium that can be shared across vast varieties of stakeholders. This practice has led to: outright errors in data since it is difficult to keep track of the versions of documents; increases to the development timelines in order to just produce “documents” that are polished in formatting more suitable for print purposes; and increases to the overall cost since contractors have to charge for the additional document production time and publishing expertise. It is common for engineers to complain more of their time is spent producing pretty documents than doing engineering work.
The Digital Engineering Strategy is attempting to combat the “where’s the latest document” question by describing in their second goal an authoritative source of truth. “The authoritative source of truth facilitates a sharing process across the boundaries of engineering disciplines, distributed teams, and other functional areas. It will provide the structure for organizing and integrating disparate models and data across the lifecycle. In addition, the authoritative source of truth will provide the technical elements for creating, updating, retrieving, and integrating models and data.”
The Jama Connect platform is purpose-built to facilitate data sharing across various stakeholder disciplines and location boundaries. An easy to use web UI is used to capture and work with both data as well as the real-time decisions and feedback taking place around that data which keeps all stakeholders informed when change occurs and makes sure everyone gets the content they need—right when they need it. The result is that stakeholders can now access the most recent versions of data that engineers are working on without having to rely on document exports – the root of all waste.
Fitting Within the Infrastructure
No one tool alone will fulfill the new Digital Engineering Strategy and so to avoid the same problem of stovepipes that documents bring, the infrastructure and the tools used must become more consolidated and collaborative. Tools whether it is a MBSE tool, software engineering tool, testing tool, or CAD tool needs to have its data easily integrated with the rest of the tools within the infrastructure. The “DoD’s strategy is to focus on standards, data, formats, and interfaces between tools rather than being constrained to particular tools.” This is probably the most difficult of all goals to achieve, not because of the lack of data exchange standards or capabilities provided by the vendors, but simply because of the distributed nature of the development teams themselves.
In a contractor supply chain model, customers and their contractors perform their work on their own networks which are disconnected from each other. And even when working solely at a government site, classification levels force segregation of data onto different networks. Strategies to deal with integrating the data in the complex environment must be planned for.
Jama Connect’sfoundational architecture eases integration within the tool ecosystem. It has a built-in RESTful API and supports the industry standards OSLC and ReqIF formats for exchanging data. These important capabilities mean that when organizations go to integrate their digital engineering tools, numerous readily available 3rd party integration platforms are available; and in many cases already have templates to connect the endpoints in place.
Parting Words
There isn’t a single silver bullet to digital engineering, but I hope you leave this post with some ideas, some encouragement, and maybe some new determination to start your digital engineering journey.
To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.
As we enter a new decade of technological advancements, Jama Software asked select thought leaders from various industries for the trends and events they foresee unfolding over the next 10 years.
Jama Software: What are the biggest trends you’re seeing in MBSE right now and how are they impacting product development?
Dirk Zwemer: The biggest trend we’re seeing is the growing realization that MBSE is not a function of any one software tool, not PLM, not SysML, not requirements. The goal is the Digital Thread, the complete set of domain models organized, connected and version-managed in a way that allows everyone on the development team to find the data they need to do their jobs. Each discipline and each organization have a seat at the MBSE table (Figure 1).
Figure 1 Seats at the MBSE Table
Implementation of the Digital Thread is still incremental in every enterprise. Early adopters look for specific integrations that enhance collaboration between team members, speeding completion of tasks and reducing errors from domain model inconsistencies. As they implement the Digital Thread more fully, they realize even greater gains in model validation and verification, which allows deeper exploration of the system design space within project schedules.
JS: What are some continuing or new trends in MBSE you expect to see over the next decade?
DZ: First, the engineering software tools and the Digital Thread infrastructure that connects them are all becoming scalable enterprise applications, sharing services and data either in the cloud or in on-premises servers. Standard interfaces such as RESTful or OSLC APIs will help support this, but the great heterogeneity of data, models and use cases will handicap approaches that restrict themselves to these technologies.
Second, no single MBSE methodology will be universally adopted, so flexibility in searching, visualizing, and documenting the Digital Thread will become important. Tools with a “one size fits all” interface will be at a disadvantage relative to open source, open standard and third-party components that can give users the reports and metrics they need with minimal effort and cost.
Third, MBSE is moving downstream through the system lifecycle. The Digital Thread will cover:
With respect to tool integration, this will initially involve:
SysML → PLM → MRP
And we can expect to see increasing activity on this bridge. The advantages of devops processes in the software world will be increasingly obtainable for cyber-physical systems, as well.
JS: What sorts of process adjustments do you think development teams will need to make to accommodate these changes?
DZ: Practicing good data governance will be the biggest adjustment for most development teams building the Digital Thread.
Cybersecurity will be an immediate concern. With the rollout of CMMC v0.6 (Cybersecurity Model Maturity Certification), DoD contractors, primes on down, will need audited cybersecurity practices to compete for government contracts starting in 2020. Information sharing will be particularly impacted.
While cybersecurity is nominally concerned with preventing access by bad actors, information access by collaborators is also an issue. Process teams will look for ways to selectively share data, e.g. between customer and supplier, that prevent the partner from accessing deeper levels of proprietary technology.
If the Digital Thread shares information between repositories, process teams will need to explicitly define data ownership, i.e. which repository is master, and processes for data comparison, notification, and update.
All these adjustments will be easier if the enterprise adopts standard, well-documented authentication mechanisms. In too many organizations, these have grown ad-hoc, different for each repository, and with no central management or knowledge base. Implementing the Digital Thread in such environments will prove frustrating, so common authentication protocols will be needed.
JS: What do you think will remain the same in MBSE throughout the 2020s?
DZ: While not absolutely necessary, architecture modeling will remain an important part of MBSE and SysML will remain the dominant architecture modeling language. The SysML v2 Submission Team is working under the auspices of the Object Management Group to keep SysML relevant, with a final submission target of June 2021. Proposed changes will make SysML more precise, intuitive, and reusable, especially in the area of modeling usages and variant designs. A new underlying metamodel and a companion standard for SysML API and Services will open new opportunities for model creation, management and visualization. Together, these new features should broaden the reach of SysML across the development team while reducing the barriers of learning new tools, terminology, and notation.
JS: Anything else you’d like to add?
As new MBSE adopters flood the market and existing users refine their processes, the “Voice of the Customer” will be heard louder than ever. Buyers will want tools that are easy to use, cost-effective, and customer-configurable rather than vendor-customized. There will be plenty of opportunities for newer vendors that can meet these needs.
My initial intention for this blog was to talk about what I describe as MBSE tool maturity levels. And I will surely get around to those levels. But first I think it is important to draw attention to the definitions of MBSE that experts use and offer some observations that might be helpful to those who are beginning their own MBSE initiatives.
![[Webinar Recap] MBSE Made Easy: Overcoming the Organizational Challenges](https://www.jamasoftware.com/media/2021/03/2021-03-11_MBSE-webinar-wrap-up-blog.jpg "[Webinar Recap] MBSE Made Easy: Overcoming the Organizational Challenges")
