For over ten years, the systems engineering community has been focused on the transformation from document-centric to model-based techniques. In terms of the Roger’s innovation adoption lifecycle, we are beyond the early adopters, in the early majority, and moving towards the tipping point where model-based systems engineering becomes the expected framework and approach. In terms of the Gartner hype cycle, some are at the peak of inflated expectations, some in the trough of disillusionment, and a few on the slope of enlightenment.
In the past I have shared classic errors organizations make in deploying MBSE and how to apply systems engineering to the deployment of MBSE to avoid these errors. However, there are still far too many sitting on the sidelines, not having started their journey towards MBSE. Time and time again, the same imaginary roadblocks – great reasons not to adopt model-based systems engineering – come up. Some are roadblocks that the community spawned through inaccurate or unclear messaging. Some reflect natural misconceptions that emerge during periods of change.
Imaginary Roadblock #1 – “MBSE requires SysML (or UML or UPDM or UAF).” Models have always been and always will be central to engineering, even if they only reside in the engineer’s brain. The issue is to surface models and make them available for conversation and evaluation. When viewed in this light, the journey to MBSE is about evolving from low-fidelity representations in documents to higher-fidelity, richer representations. It is also about capturing knowledge in a more granular form for management, analysis, and learning.
While representation sets like SysML (as well as UML, UPDM, UAF, and even IDEF) provide a path to conversation and understanding, they are not the only vocabulary, or even the best in every situation. MBSE – and systems engineering – require that we communicate based upon the needs of the parties so that we achieve mindshare and alignment. The choice of expression is open to any means that does the job – SysML or traditional; technical representation or cartoon; diagram, movie, augmented reality, or even text.
Imaginary Roadblock #2 – “We’re doing SysML (or UML or UPDM or UAF) so we are already doing MBSE.” If we use Microsoft PowerPoint® or Visio® to manually draw top, front, and side projections, are we ‘doing CAD’? Certainly not! So why do we confuse producing representations of a model with the model itself?
The model provides integration, connectivity, and coherence. Diagrams (or any view) are projections of the model from a particular viewpoint representing a subset of information in a particular representation to meet a particular need. As we construct and modify projections, the key to MBSE is that we must modify the underlying model – not just the representation – to maintain consistency both of the objects and their interrelationships. If we are drawing diagrams without a structure to ensure connectivity and coherence, we’re simply drawing pictures. Substituting a collection of diagrams for a stack of documents falls far short of the integrity and power of a true MBSE model.
Imaginary Roadblock #3 – “We are already doing modeling and simulation.” If you are doing modeling and simulation as part of your systems engineering effort, please keep doing so. They bring much needed analytical rigor. However, classical modeling and simulation is using models in systems engineering, not MBSE itself. The difference comes back to integration, connectivity, and coherence. Connecting our models in a coherent framework at the system level – particularly if we use the descriptive architectural model to coordinate the analytical models – yields tremendous benefit. The use of analytical models alone denies us this benefit, much as simply assembling components without a greater architecture fails to deliver the desired system outcomes.
Imaginary Roadblock #4 – “We must implement the architectural and analytical aspects to get any benefit.” Those versed in MBSE recognize that there are two primary types of models in MBSE. There is the descriptive architectural model where innovation occurs, where we engineer in key systems characteristics such as resilience and security, where we have our one chance to manage complexity. There are also the analytical models which bring rigor, efficiency, and effectiveness to our systems engineering efforts. When tackling a new problem, we emphasize the architectural model, leveraging a limited number of key analytical models to ensure rigor. When working the next iteration of a system, we emphasize the analytical models, leveraging the architectural model to maintain coherence.
To manage a vast potential problem / solution space coupled with a daunting set of architectural and analytical aspects to address, begin with the end in mind. Implement the blend that is right for your problem and your circumstances, ensuring connectivity and coherence of the blend you choose.
Imaginary Roadblock #5 – “It’s too complex.” If we fall victim to the first roadblock (we must learn a new representation set) and the fourth roadblock (we must tackle architecture and analytics), transitioning to MBSE may be too complex. Returning to the fundamentals and remembering that MBSE is an evolution from low-fidelity documents to higher-fidelity, richer representations, the complexity fades away. MBSE need not be more complex than traditional document-centric approaches. Done well, MBSE can be less complex because of improved knowledge representations and communications. It is not the “easy button”, but it does remove the roadblock for transitioning your approach to systems engineering.
Imaginary Roadblock #6 – “We must model everything, and it’s not possible to model everything.” The second half of this statement is absolutely true and is a trap in which many practitioners find themselves. It is not possible to model everything in systems engineering, but that is not required in MBSE. We must have a top-level descriptive architecture spanning from user needs through behavior, architecture, and test. This top-level layer gives us coherence, connectivity, and a framework for consistency. We then add greater detail where we find new requirements, new approaches, new technologies, critical parameters, and unknowns. If we understand a dimension of the problem or solution, we need to capture it in sufficient depth to align the team understanding, but we do not need to go to the atomic level. Instead, we invest our time and energy in areas of change, risks, leverage, and the unknown. The result is a model of varying depth – one that reflects sound engineering judgment as opposed to pursuing the dream (fantasy) of taking all aspects to equal and infinite depth.
Imaginary Roadblock #7 – “Implementing MBSE is one size fits all.” In The Last Lecture, Randy Pausch said “Engineering is not about perfect solutions. It is about doing the best you can with limited resources.” True for engineering and systems engineering, it is absolutely true for MBSE. Tailoring is the key.
You tune your implementation of MBSE to the shape of your problem, achieving the right blend of architecture and analytics to deliver value. You tune the representations used for your project team members, users, and customers to enhance communication and alignment. Even before you begin, you seek to understand the voice of the business so that you properly tune for its primary business concerns. The particular approach and implementation that worked for another project or organization will be different and should be so. Shared lessons are great, but we need to use those lessons to inform our specific journey rather than believing that we must follow in someone else’s footsteps.
Imaginary Roadblock #8 – “It’s a technical problem.” There certainly is a technical dimension to model-based systems engineering. But the biggest challenges are not technical. They are culture and change – at a personal, organizational, and ultimately industry level. Failing to understand this inhibits us from crafting the right journey to solution.
MBSE is about an evolutionary change in the representation of knowledge in order to achieve alignment and shared cognition. That is, by definition, a cultural problem. We must embrace varied perspectives, needs, and backgrounds, technical and otherwise. Existing interfaces must evolve – whether the way information is shared and analysis is performed within an organization or the way information is passed from the customer to the engineering organization and across the supply chain. The existing mental model and set of business processes that house those interfaces must evolve as well. The old process and framework that worked for a document-centric approach may inhibit – if not strangle – a model-based approach.
The misperception that the adoption of MBSE is a technical problem spawns two additional, self-inflicted roadblocks. First is the belief that “all I need is the right tool.” Second is the thought “I can learn it myself”. Don Gelosh from WPI likes to describe systems engineering as a contact sport, and MBSE is no different. Understanding what to do is relatively easy but doing it well is difficult, and you learn it by doing. If you want to learn how, seek the guidance of those who have done it before. They can help understand your need, suggest a path tailored to your circumstances, help you avoid pitfalls, and provide guidance as you stumble. The most effective path is through training and mentoring.
Imaginary Roadblock #9 – “MBSE is the answer…it does everything.” By far my favorite roadblock is the roadblock that many don’t see as an inhibitor. By accident or intention, many have become snake oil salesmen offering MBSE as the fundamental answer for everything that ails systems engineering. They create the impression of MBSE as a cure-all which makes those considering MBSE wary. It’s not that easy.
MBSE doesn’t do it all, but it is a key part of the answer. As a necessary addition to our systems engineering toolkit, MBSE can certainly advance our practice and serve to unify disjoint processes, methods, and techniques. Done well, it is invaluable in an age of ever-increasing complexity and ever-accelerating change. It is an enabler, but only an enabler and only a part of the systems engineering solution. We can use MBSE to be more explicit, to better understand our practice and the interconnections across the engineering and project lifecycles. We can build upon an MBSE foundation, but we should never confuse that with MBSE being the answer to everything.
So for those already on the journey to MBSE, why worry about these imaginary roadblocks? In some cases, better understanding a perceived block can help you adjust your path for even greater success. However, the far greater reason is that ultimately we must change at a whole-of-industry level if we are to advance the practice of systems engineering. Industry changes only to the degree that organizations, projects, and individuals change. As such, we must embrace the role of change agent and in doing so lower the barrier to entry and smooth the path to MBSE rather than emphasize complexity as engineers often do. We must avoid dogma and the ideal, recognizing that perfection is the enemy of progress while remaining right (we cannot afford to ’dumb it down’ to the wrong answer). If we can eliminate these imaginary roadblocks, we can clear the way for ourselves and others. Better yet, if we can avoid creating additional imaginary roadblocks in the future, we can avoid some of the fear, uncertainty, and doubt that accompany transition to model-based systems engineering.
