From model to mindset: the real challenge of Model-Based Systems Engineering
- Salvatore Marangio
- Jul 25
- 21 min read
Updated: Jul 28
The failure of the MBSE: long live the MBSE!
Why MBSE fails (and how to make it truly work)
by Gian Giacomo Ermacora and Castrese Di Marino.
It used to be the “Lean.” Then it was the “Digital Twin.” Today it is the “AI everywhere.” Every company chases the wave of the moment. But following trends without understanding the basics is like building a house from the roof up. The most common justification for why you don't really do MBSE is, “We bought the best tool for Model-Based Systems Engineering, but after three months no one was using it.”
But then, why does this happen?
Model Based Systems Engineering (MBSE), which has evolved in recent periods into the acronym MBS(S)E (i.e., where the second “S” stands for Software, thus making the term such as Model Based Systems and Software Engineering), is an approach to complex systems engineering based on the use of formal models as the primary source of information, as opposed to the more traditional use of textual documentation.
MBSE is not a recent concept; in fact, people started talking about Model Based as early as around the 1970s, then with the emergence and spread of CAD drawing systems, the concept of a “virtual model” has increasingly evolved and established itself in engineering. While CAD defines the physical object and is the perfect representative of the “solution domain,” Model Based Systems Engineering, on the other hand, perfectly straddles the problem and solution domains. MBSE was created with the goal of enabling a natural flow between the domains because of the holistic view of the system, its behavior to and from the user and in relation to the world around it, as well as the relationships (implicit/explicit or extrinsic/intrinsic) with the systems with which the System of Interest (SoI) relates.
In formal terms, MBSE has been defined as “the formalized application of modeling to support the activities of requirements definition, design, analysis, verification and validation of a system, starting from the conceptual stages and throughout its life cycle.” So in theory this approach promises undoubted benefits, namely greater consistency and traceability of design information, improved change management, a major revolution in interdisciplinary integration, and a significant reduction in potential errors along the System of Interest development cycle.
Unfortunately, however, the reality of MBSE (and MBSSE) adoption is much more complex.
Countless organizations of all sizes have undertaken MBSE initiatives, encountering serious difficulties or even failures of the initiatives themselves, thus not realizing any of the expected benefits.
In this article, we aim to take an in-depth look at the reasons for such failures, articulating in particular three key aspects, namely (1) the inherent limitations of MBSE, (2) critical issues related to organizational culture and tools, and (3) some concrete cases in which MBSE adoption has failed, or succeeded only through radical organizational transformations.
The MBSE's inherent limitations
The primary ambitious goal of MBSE is to provide a modeling approach to describe the characteristics of a complex system. Unfortunately, however, it has some limitations that, if not properly understood, can get in the way of the effectiveness of the entire approach.
Conceptual ambiguities and immature standards
Incredibly, the term MBSE itself often generates confusion. As mentioned in the opening of the article, the concept of Model-Based is not a recent one. In fact, over the years the scientific and engineering community has proposed many variations and interpretations of the term. In fact, in engineering the word “model” is extremely generic; it can include any form of more or less simplified representation, for example, diagrams, simulations, prototypes, etc. It is precisely this conceptual ambiguity that has led to profound misunderstandings, not the least of which is the (erroneous) equation “MBSE = SySML,” i.e., the notion that adoption of MBSE means only using SySML. Reality suggests that SySML is only one of the possible tools, and this equivalence has generated fears and uncertainties. To date SySML, and it will be until the final and official release of version 2.0, is a language that is in fact not fully mature and is “interpreted” in slightly different ways by many software vendors. It is often criticized for its complexity and incompleteness, to the point that on many occasions people even prefer to use generic drawing tools, even such as Microsoft Visio, in order to avoid the learning curve of SySML. Being precisely a language and not a method, SysML brings with it the need to adopt a well-defined working method that implies below sets of processes, which, to make it even more articulated, introduce an additional level of complexity, for example, the adoption of a framework, which, while on the one hand directs operations, on the other hand requires study and application rigor.
This immaturity of standards and methods often results in a lack of clear and shared guidance: in fact, even today, there is no universally recognized methodology that explains in a practical way how to apply MBSE to real projects. Moreover, training is often limited to software tools and specific languages, such as SysML, but rarely offers step-by-step guidance on how to actually build a truly effective and useful model. In fact, the reference standards provide guidance on what to do, what kind of artifact to use, and ultimately, what the capabilities of the supporting software should be, but they stop there, at simple directions, however precise and to the point. As if knowledge of the grammar rules of a line is sufficient to engage in conversation.
This often leads project teams to feel a bit lost, forced to make crucial decisions almost “by trial and error” (What notation do we use? How far should we go? How can we really the requirements?), especially where there is a lack of an experienced guiding figure to mentor. In other words, if we look at the issue from a practical and methodological point of view, MBSE still has several undefined points and a maturity that has not been fully achieved; the real risk, therefore, is that we end up creating models that are not very coherent and, consequently, of limited effectiveness in the field.
Rigidity and limited integration of instruments
The software tools used for MBSE in turn carry other inherent limitations, often being rigid and not very interoperable with other engineering tools already commonly used in various domains, from requirements management and down the Engineering Lifecycle Management toolchain to PLM and physical simulation.
Theory would have it that MBSE could finally enable the “digital thread” that is supposed to connect all disciplines, but we know that in practice it often stumbles precisely on integration. Dedicated MBSE tools struggle to dialogue with specialized software (mechanical CAD, simulation environments, project management tools, etc.), causing potential fragmentation instead of integration. The natural solution is manual transfer of data between systems, resulting in inefficiencies and errors. Even in the case where integration systems exist, they are often either expensive and highly customized solutions or invasive with regard to process definition.
A further important issue is that of usability: MBSE tools have steep learning curves, the interfaces are not always intuitive and can discourage users. The need for specialized skills to use these tools effectively means that MBSE models potentially remain “locked” in the hands of a few specialists. As a result, the model risks not being searchable or understandable by the entire project team: stakeholders untrained in the formal language (e.g., managers, suppliers, or even engineers from other disciplines) struggle to interpret complex SysML diagrams.
This limits the accessibility of the model and depowers it, risking keeping it confined in a silo instead of serving as a Single Source of Truth. But when the model is truly central (accessible, queryable, tracked) it is no longer just a technical container; it becomes the common reference point for analysis, discussion, and decision-making.
The value of the MBSE emerges right there: that is, in the ability to provide a single, verifiable source of information, which eliminates ambiguity, reduces misunderstandings between different roles, and enables continuous dialogue between domains.
Without this condition, the risk is that each function will go back to talking to each other through its own tools (documents, spreadsheets, presentations) and lose alignment and coherence again.
Excessive abstraction and detachment from engineering reality
Abstraction is the MBSE mantra: “You have to create only high-level conceptual models, away from specific solutions!” But so what happens to business know-how?
In fact, pushing too far into abstraction can lead away from the concrete reality of engineering. In some industrial contexts, it has been noted that if MBSE is not properly integrated with business processes (which in turn must be ready to receive MBSE), one risks ending up operating in a separate silo, sometimes even as a formal documentation exercise parallel to the practical work of engineers.
Engineering teams, especially those that are very outcome-oriented, often see MBSE models as something theoretical, distant from the “real” work, almost an academic exercise that does not get its hands dirty with practical details. This bias can become a brake on adoption: the model ends up living in a world apart, without really affecting everyday design decisions. And so, paradoxically, the very sense of MBSE is lost.
Another risk associated with abstraction is “over-modeling”: the temptation to represent every single detail of the system, chasing the (often illusory) idea of a perfect digital representation.
This belief is actually a rather insidious conceptual trap: the widely held idea that for a model to be really useful it must describe everything about the system, in as little detail as possible.
In reality, trying to model every screw, every wire or every bit of a complex system is simply unrealistic. Resources - time, budget, energy - are exhausted well before you get to the bottom of it. The risk? Losing sight of the purpose of the model itself: to support decisions, not to become an encyclopedic endeavor.
The true value of a model lies not in its encyclopedic completeness, but in its ability to be a purposeful abstraction: it must be detailed enough to answer the relevant design questions, no more and no less.
As also pointed out in a NASA study, it is essential to “model only as far as is needed to answer the question under consideration.” Going beyond that risks turning modeling into a sterile exercise disconnected from operational reality.
If this principle is neglected, MBSE can generate hypertrophic models that are complex to maintain and even more difficult to keep aligned with the evolution of the real system. The result? Frustration, loss of confidence in the model and method.
So abstraction is the great strength of MBSE, but like any powerful tool, it must be used judiciously. Too much abstraction-or misdirection-can produce models disconnected from the real world and business reality, consequently, of little use to operational decision makers.
Critiques of MBSE culture and tools
Most failures in MBSE adoption stem from organizational, cultural and tool-related factors, i.e., how MBSE is introduced and supported in the company.
Below we analyze the main critical issues encountered.
Inadequate organizational skills
MBSE requires specific professional figures with a less than common mix of skills, namely knowledge of traditional Systems Engineering, mastery of formal modeling languages, abstraction skills and at the same time the ability to dialogue with other disciplines.
Many organizations have realized, in retrospect, that they lacked the necessary human capital and, above all, that they underestimated the need for their own investment in skills and training.
A business case study notes that “a general lack of experienced MBSE engineers” is one of the main obstacles to successful implementation. In other words, you can buy the best tool on the market, but if the team does not possess (or develop) the skills to use it effectively, the initiative is bound to face serious difficulties in achieving the desired success.
Steep learning curve and resistance to change
Introducing MBSE involves changing, in a significant way, the way engineering teams work, and it is not a matter of “learning new software” modeling, but rather of making a real “mindset switch.”
This culture shock is something, like any change, that can generate considerable resistance. The “it's always been done this way” syndrome is an enemy not to be underestimated: many engineers with years of experience in traditional methods may perceive MBSE as a bureaucratic imposition or a passing fad imposed from above.
Companies that have achieved significant successes over the years with the traditional document-centric approach tend to “sanctify” those methods, viewing with suspicion any innovation that involves risk, effort and investment.
Risulta evidente quindi che senza un chiaro valore immediato, il personale possa addirittura ribellarsi passivamente, ignorando il modello e continuando con i vecchi strumenti paralleli, facendo fallire l’iniziativa nel silenzio.
A recurring effect in projects introducing MBSE is that it is perceived as an added burden, not as a smarter way of working. If teams still have to write traditional documentation-because customers or existing processes dictate it-and in addition keep the model up to date, it is inevitable that they will see it as twice the effort, not a help.
This leads to one of the most common mistakes: superficial adoption of the MBSE, where tools and formalisms are introduced without really managing the cultural change that is needed. Without targeted training, mentoring in the field and a little patience to get through the inevitable settling-in phase, MBSE risks running aground against the toughest of barriers: the mental barrier of “I don't believe in it” and, even worse, “I don't have time to learn.”
Inability to adapt to legacy processes
MBSE, to be successful, in many cases requires revisiting an organization's established processes, often refined over the years for specific products. It requires putting on a “re-engineering” of the “way” an organization develops its systems and products.
However, when adoption is presented by external consultants or tool vendors simply as if it were a simple transition, all the problems associated with MBSE adoption emerge exactly as described above: clash with the reality of the processes in place, inadequacy of the environment and means, little or no preparation in people, detachment from business reality, and finally overly abstract and utopian narratives. Promises of change systematically unfulfilled.
A frequent mistake that is made is to drop the MBSE on top of existing and established workflows without making any changes to them, for example, adding modeling processes as a stand-alone phase, without thinking about how information can then flow between disciplines. This leads to a model that is disconnected; MBSE remains a dry branch parallel to the other disciplines and technical processes.
One thing to keep in mind is that MBSE implies and requires a data-centric and integrated approach, which just does not fit with “legacy” document-centric concepts.
The organization must be willing to redefine roles, deliverables and approval flows around the model, on pain of creating a mismatch: “engineers, accustomed to certain tools and practices, struggle to incorporate MBSE models into routine, with the result that MBSE becomes a parallel and underutilized effort instead of an integral part of the process.”
A case in point is requirements management: in many companies, dear old Excel or some legacy tool now part of the corporate DNA still reigns supreme. If you introduce MBSE without thinking about how to integrate it with these tools, you end up having to keep requirements updated in two places at once - in the legacy system and in the new model. The result? A real operational nightmare, wasting time, creating confusion and fueling the temptation to drop everything and go back to the method “that at least works.” Thus, when the benefit is not immediate, but only future, many technicians react with frustration and rejection: they see only one more model, not a better job.
This is not at all uncommon, indeed: in several projects people end up abandoning the use of SysML, simply because it is “more inconvenient” or “less familiar” than the tools they have been using all along. The model, if not made understandable and usable, generates distance instead of convergence. SysML, with its formalism, can be intimidating. But it is indicative that the same feeling emerges in CAD: interaction with the model is still experienced as cumbersome, disconnected, sometimes imposed. It is a clear sign that the problem is not (only) the tool, but how the value of the model is perceived in the real work context. When the new tool does not really integrate into existing workflows, but seems just a cumbersome addition, its fate is sealed.
The problem is that the MBSE, if it does not take the place of an existing process but merely sits alongside it, risks becoming just another burden to carry. And in environments where processes have been rote for years-with standardized documents, formalized reviews, checklists carved in stone-introducing something new is like trying to turn an oil tanker around with the rudder of a dinghy. It takes more than a good tool: it takes organizational courage and a real will to change.
Truly embracing the MBSE does not mean simply “adding a model here and there”: it means questioning the entire operational set-up of the company. And that, needless to turn around, is a huge effort. Unless carefully planned-with the right management commitment and serious involvement of process teams-the MBSE remains a side initiative, good for slides but irrelevant in day-to-day practice.
INCOSE experts themselves say it loud and clear: There are no turnkey process models for truly integrating MBSE into traditional flows. Each organization must build its own formula, tailor-made, supported by the right people with the right mindset and preparation. The problem? Many don't, out of fear or lack of resourcefulness or core competencies. Or, worse, each project invents its own extemporaneous version, generating confusion, misalignment and systemic inconsistency.
The result is that without decisive intervention in established processes-and the habits that support them-the MBSE remains a foreign body, which the corporate system eventually rejects as an incompatible transplant.
Lack of support from top management
An often underestimated-but crucial-aspect is the active involvement of top management, especially so that top management is clear about the business-level benefits that this type can grant through increased competitiveness in markets. . The adoption of MBSE is not a simple change of tool; it is not a matter of replacing one software with another. It is a structural transformation, one that puts hands on roles, processes, responsibilities and, above all, the way of thinking and working of an entire organization.
When this revolution is not understood and supported by top management, the initiative fizzles out before it even gets off the ground. In more than one case, it was observed that the main cause of failure was not the technology, nor the complexity of the method, but the total absence of an internal sponsor, someone with the authority and vision to drive the change and defend it in difficult times.
Conversely, when management truly believes in the value of the MBSE, then something else happens: concrete resources come in - time, training budgets, investment in the right tools - and those internal obstacles that would otherwise nail down any attempt at innovation begin to be removed. The transition, however complex, finds room to mature.
Success, in these cases, starts from the top, and it is not a slogan: it is a reality confirmed by so many successful projects. But for this to happen, it is essential to communicate the value of MBSE in terms that speak to the business: fewer acronyms, more impact on time, cost, quality, margins. If the narrative remains technical, if demos speak only in “SysMLese,” decision makers will soon fall out of love, and with them, so will funding, patience, and support.
In the end, what really matters is not just the tool, but the context that hosts it: the people, the processes, the mindset, and the courage to change. That is where the real game of MBSE is played. And as in any deep change, without convinced leadership, it is only a matter of time before everything goes back to the way it was before-or worse, into a limbo of unused tools and broken promises.
Case studies: necessary failures and transformations
To gain a concrete understanding of the failure (or success) of MBSE, it is useful to examine some real or emblematic cases. Here we present examples that highlight how superficial adoption leads to failure and, by contrast, how successful adoption requires profound organizational and process changes.
Shallow attempt and failure
A classic example of failure to adopt MBSE is that of the company that, seduced by the enthusiasm of the moment around SysML, decides to take “the plunge” by purchasing a modeling tool and sending the team to a couple of quick courses. Everything seems to start off well, with the enthusiasm typical of new things. But then? Then things get jammed.
The model begins to take shape, but meanwhile deadlines loom, “official” documents continue to be required in Word or Excel, and no one has really rethought how to integrate all this into the real workflow. So, little by little, engineers are reverting to their old ways. Not out of laziness, but out of survival: the model slows down, the customer wants the usual files, and there is less and less time. Talking to Chief Engineers, almost always this doubt or fear emerges, “How will MBSE speed up our processes?” There is a failure to perceive the long-term benefit in using a model versus traditional tools, which are simpler and more widely used, but much less performant over long distances.
Meanwhile, management watches from afar, without putting a face on it, without providing time, people or a clear vision. The result? The model is updated only to save appearances, when it is needed to make a “good impression” or close an audit. In fact, it becomes an exercise in style, not a useful tool.
It is a story we have seen before. And it is also confirmed by several studies: the MBSE, when treated as a simple tool change and not as a profound change in the way of working, is doomed to fail. Initiatives that don't include strong sponsors, time to really train people, and above all an overhaul of existing processes will slowly die out.
The moral is simple and brutal: If you approach MBSE as if you were installing new software, without touching anything else, you are just throwing away time and money. It is not the technology that makes the difference, but the context in which you drop it: the people, the processes, the support, the willingness to really change. Without these ingredients, any model-no matter how elegant-is destined to end up in a drawer.
NASA JSC case - successes achieved through organizational transformation
t the opposite extreme of failure cases, there is an experience worth recounting: that of NASA Johnson Space Center (JSC). As early as 2009, the center decided to bet seriously on MBSE, adopting it in frontier projects. But it has not been a walk in the park. The initial difficulties were all there: cultural resistance, concern about risk, and widespread skepticism about an approach perceived as too theoretical or complicated.
The difference? JSC did not just install a tool and take two courses. It undertook deep, structured, multilevel work. It trained key figures, built an internal support infrastructure - a real MBSE reference group - and defined clear rules of the game for everyone, with common guidelines, integrated tools and reusable templates.
This was not an “IT project,” but a cultural transformation. Internal “champions”-engineers with vision and leadership-were identified to drive change from the bottom up and make it happen in teams, day by day. An internal community, the SysML User's Group, was even created to share experiences, solve problems, and contaminate the organization with a new way of thinking.
Most importantly, the focus was on demonstrating the value of MBSE in practice. Not in words, but in everyday tasks: automatic report generation, requirements tracking, cross-functional, software and hardware visibility. In essence, engineers began to see how the model could really simplify their work-not complicate it.
It was a long process, and far from painless. To get there, the JSC had to overhaul its development processes, moving from a static document logic to a living, dynamic model capable of evolving along with the project. But the results came, and how.
A concrete example? The Deep Space Habitat (DSH) project - the living module for future deep space missions. There, the SysML model enabled an integrated representation of requirements, functions and components, giving everyone - from designers to stakeholders - a single, coherent and up-to-date view of the system under construction.
That model was not an “extra file.” It was the official source of truth for the project. Because of this centrality, the team gained more control over changes, better tracking, and much more efficient management of interdisciplinary complexities. Indeed, when the model is truly at the center, cross-platform, tracked and accessible, all information and knowledge resides there. Software tools are no longer simple editors, but become environments for use, navigation and collaboration. Knowledge is no longer dispersed, reviews are done through the model, and decisions have a clear context. The benefits are obvious: complexity management, better understanding, effective communication.
The lesson is clear: MBSE can indeed deliver on its promises-but only if it is treated for what it is: an organizational transformation, not a plug-in to add to the old routine. Even at NASA, if there had been no real investment in skills, practices, and culture, the model would have remained an academic exercise. Instead, it has become a living, useful tool. As it should be.
Automotive sector - cultural change as a key to success
Another interesting case comes from the automotive world, where a company had decided to focus on MBSE. But the beginning, let's face it, was not the brightest. The SysML model was perceived by design teams as a strange, distant creature, almost an academic experiment dropped from above, completely disconnected from the daily reality of CAD, simulations, continuous iterations and production pressures.
The result? Systems engineers modeled on one side, detail specialists continued on their way. Two worlds that didn't talk to each other, and the model, however elaborate, stayed there-useful perhaps for making a presentation, but useless for solving real problems.
Those in charge, however, had the merit of not ignoring the signs. Instead of pushing through guidelines and regulations, they chose a different path: to involve people, really. They organized mixed workshops, putting systems engineers and mechanical, electrical, software designers side by side. Objective? To understand each other. To make the model not just formally correct, but practically useful.
During these meetings, an interesting thing happened: those who modeled learned to “talk simple,” adapting the views of the model to the real questions of their colleagues. And the others, those who turned up their noses at first, began to explore the model with curiosity, asking questions, suggesting improvements. Slowly, that cultural gap narrowed. The model began to answer concrete questions, simplify decisions, save time on unnecessary rework. 5000 requirements became 500; customer need was represented clearly and effectively, immense datasheets became diagrams in a clear, organized, usable logical and functional architecture. Well-structured information became knowledge that moved from one level to another with extreme simplicity and clarity.
In just a few development cycles, what was considered a burden became a real coordination tool. Teams spoke the same language. Problems were being prevented rather than chasing them. And the model, from being a foreign body, became an integral part of the way of working.
Of course, it didn't happen by magic. It took new spaces for dialogue, mutual training, and above all the willingness to revise processes, adapting them so that the MBSE was not an extra, but the protagonist an accessory, but an ally. And as is often the case, real change began when we stopped thinking in terms of tools and started working on people. The best tools (methodological and software) in the hands of unprepared and inadequately trained and involved people lead to widespread costly frustration. On the other hand, if capable and competent people can accomplish wonders with a sheet of paper, a pencil, an idea and a little time, what could they accomplish if given the right tools?
What, really, do these cases teach us? That when MBSE works, it is never by accident. All successful examples have a lowest common denominator: there is deep transformation behind them, not just a technology upgrade. We're talking about new digital infrastructure, integrations between tools that didn't talk to each other before, structured training, process change, and - most importantly - leadership that believes in and drives change, day in and day out.
In contrast, whenever MBSE has been introduced in a superficial way - buying a tool, drawing a few diagrams, perhaps inserting a few “trendy” terms into documents - the results have been disappointing, when not disastrous. Because MBSE is not a paint job to be given over an existing organization.
It is a restructuring job.
And it requires time, coordination and a clear vision.
As many experts say, it is not enough to think about the technical aspect. You need an approach that embraces the whole: people, processes, culture and tools. This is the only way to make the model central to the way complex systems are designed, built and managed.
MBSE is not a plug-and-play solution. It never has been. It is a paradigm shift, with all that that entails. And if you take it lightly, not only does it risk not delivering results, but it can make things worse, generating confusion, wasted resources and widespread disillusionment.
Summing up
MBSE failure, when it happens, is not the fault of the approach. It is not a structural weakness or an underlying misconception. Almost always, the problem lies in how MBSE is adopted. It is easy to fall in love with the concept, to think that all you have to do is introduce a modeling tool, add a few diagrams and voila - transformed system. But unfortunately, it doesn't work that way.
MBSE is not a magic wand that is added on top of existing processes without touching them. It is more like deep surgery: it requires preparation, specific skills and, above all, a real will to change. And this applies not only on a technical level, but on a cultural, organizational, human level.
Sure, the limitations are there - SysML can be hostile, the tools do not always shine in terms of usability, the abstraction sometimes makes you lose touch with the real world. But all this can be managed, if one has the courage to approach adoption for what it really is: a systemic revolution. Concrete examples are PLM tools whose introduction led to strong clashes, yet today they are enormously popular and now indispensable assets of business workflows.
Here's the crux: no company should face this path alone. It is too easy-and too human-to get attached to one's own processes, one's own certainties, one's own “this is how we have always done it.” The risk, very high, is that of bending the new over the old: adapting the MBSE to obsolete processes, rather than taking the opportunity to renew them. In doing so, you end up sterilizing all the transformative potential of the method.
That's why you need to team up with experienced consultants, who not only know the tools inside out, but who live and breathe standards like SysML, methodological frameworks like Arcadia, Harmony, MagicGrid, UAF, and know how to accompany an organization through deep transformation. We are not talking about technical training, but real structured change management work.
This is precisely the heart of ONE-SYS' mission: to support companies in this transition, helping them to design and build their MBSE system in a way that is robust, sustainable, and truly integrated into the way they work every day. We do this every day, side by side with our customers, translating ambitions into reality and models into operational value.
Because MBSE, if adopted seriously, is not just an evolution of systems engineering: it is a leap that can rethink the way an entire enterprise conceives, builds, and operates its products. It is a leap that requires strong leadership, investment in training, and a willingness to question roles, responsibilities, and processes taken for granted.
And there are no shortcuts. One cannot “try a little MBSE” as if it were a passing fad. Either you embrace it all the way, as a strategic lever of transformation, or you end up feeding frustration - and the usual narrative of “broken promises.”
In conclusion, the point is not whether MBSE works. The point is: are you ready to face it for what it really is? Because if the answer is yes, the results come. And they are transformative. Greater consistency between requirements and design, less rework, real traceability, and a more aware, more aligned organization, more ready to deal with the complexity of today's-and especially tomorrow's-systems.
The first step is simple, but not easy: stop looking for shortcuts and start building methodically, with vision, with expertise. And know that you are not alone: that is what ONE-SYS is here for.
Sources used in the article
Cloutier, R., & Bone, M. (2015). "MBSE Adoption Challenges and Recommendations." INCOSE International Symposium.
Friedenthal, S., Burkhart, R., & Sampson, M. (2009). "INCOSE MBSE Initiative – The Roadmap to Deployment." INCOSE IW.
Link: https://www.researchgate.net/publication/267687693_INCOSE_Model_Based_Systems_Engineering_MBSE_Initiative https://www.omg.org/sysml/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf
Estefan, J. A. (2008). " Survey of Candidate Model-Based Engineering (MBSE) Methodologies." INCOSE Technical Report.
Paredis, C. J., et al. (2010). "An Overview of the SysML Modeling Language." Proc. of INCOSE International Workshop.
DOI: 10.1002/sys.20179
Sandia National Laboratories (2016). "Model-Based Systems Engineering Adoption Assessment." Internal Review.
Mohammad Chami, Jean-Michel Bruel. A Survey on MBSE Adoption Challenges. INCOSE EMEA
NASA: MBSE implementation reports and pilot projects (incl. Deep Space Habitat case).
INCOSE MBSE Working Group (2023). "MBSE Maturity Survey Report."
Accenture (2024). "Future of MBSE."