Model-based systems engineering is many things. It is architecture and analytics. It is communication and analysis. It is methods and tools. Fundamentally, it represents a shift from low fidelity representations in documents to higher fidelity, richer representations serving as the single source of truth for both communications and analysis. Ultimately, it is far more evolution than revolution in our thinking and approach. That said, in the many discussions I have had with organizations around the world, both in my Vitech role and my time as INCOSE President, I have observed seven classic errors organizations make as they deploy model-based systems engineering.
Error #1 – Starting too big.
Though we are generally conservative in our practice and strive to incorporate appropriate margins in our design, engineers are often fundamentally optimistic. We see great possibilities as we seek to deliver new capabilities, and that includes the tremendous opportunities available to our organizations as we adopt MBSE. We see the fundamental benefits in quality, speed, cost reduction, and risk reduction. We see the ability to better align practices and people across the engineering lifecycle. And in seeing the grand possibilities, we often overreach looking for all of the benefit at once.
While the change to MBSE is certainly evolutionary rather than revolutionary, it is still change. By undertaking too much change at once, we trigger the organizational immune response which inhibits rather than enables new practices. In overreaching and advancing on broad fronts, we create unnecessary dependencies. If we are even allowed to begin the effort (attempting too much change frequently stops an initiative before it even starts), we stumble in at least one area, and ultimately under deliver against our grand promises. Far better to start with a deliberate – but useful – scope and grow from there.
Error #2 – Starting too small.
Just as you can start too big and undertake too much change, you can start too small and run into a host of other problems. Often, organizations select a small pilot effort that is not particularly relevant. In doing so, they may identify a “toy problem” that doesn’t translate or scale to their corporate efforts making the pilot irrelevant. The other frequent condition is marginalizing the deployment to remain “under the radar” and “start small” such that there is no real corporate investment or strong business champion. If the effort encounters any hiccup or resistance, the lack of investment and business champion leaves the effort completely exposed and generally dooms it to failure. The Goldilocks principle is in play so don’t go too big or too small. Select a problem and set the scope so that it is “just right.”
Error #3 – “Keeping up with the Joneses.”
Systems engineering is not one size fits all, and neither is deploying MBSE. Some problems involve more new design, innovation, and architecture. Some family of systems or product line efforts are more about incremental change, analysis, and detailed engineering rigor. Some projects are focused on time to market. Some are all about quality, confidence, and risk reduction. The problem and context should drive the specific process and implementation of MBSE. Just because one particular MBSE deployment approach worked for one project in one organization does not mean it will work for a different project with different needs in a different organizational structure and culture.
There is also a great deal of misinformation across the industry. In some cases, a strong “not invented here” culture results in ignorance of other advances and possibilities. In other cases, it’s a matter of positioning project results in a most favorable light. An open and honest sharing of successes and challenges would help us move forward as a community, but regrettably the backstory I have heard from my many INCOSE visits rarely matches the more polished success story framed for public release. Seek knowledge and shared experiences wherever you can, but always take what you are given with a grain of salt. The path to success is not implementing what someone else talked about on their project. The path to success is in matching your organizational approach and solution to your problem, culture, and needs.
Error #4 – Chasing standards.
As engineers, we know there is value in standards. However, the key is not in conforming to all standards (that is simply not possible.) The key is in selecting the right standards applicable to your problem and your journey. In representations, architecture, and data exchange, we often hear about UML, SysML, IDEF, DoDAF, MODAF, TOGAF, FEAF, TEAF, DAF, NAF, UPDM, UAF, XML, XMI, FMI, OSLC, AP239, and more. Almost all have a place, but none are universal. Don’t put the cart before the horse and begin with standards compliance in an age of standards explosion. Begin with the problem at hand, identify the supporting processes and approaches, and then select the relevant standards rather than prioritizing standards compliance over delivering the right systems engineering solution.
Error #5 – Thinking it’s a tool (or a technical) issue.
Though model-based systems engineering appears to be a technology, the deployment of MBSE is not a technical problem. Yes, there are technical challenges as we seek to improve the fidelity, efficiency, and effectiveness of communication and analysis. However, changing the way we represent knowledge as organizations and as a profession is more about people, culture, and approach rather than technology. When dealing with organizational change, technology must be an enabler, not the focus. Too often, we think that selecting a tool is all that’s needed to adopt MBSE. What’s really needed is a journey map that identifies interfaces and interactions across the engineering lifecycle, the various participants with their corresponding needs and biases, and the strategy to instill the necessary knowledge and experience while also addressing change across technical, process, and even cultural dimensions.
Error #6 – Falling into the trap of diagram-based systems engineering.
The change from document-centric to model-based approaches is often depicted as moving from specifications to diagrams. This makes for a simple graphic, but it has lulled many into believing that the destination resides in specific representations (most frequently SysML.) SysML is a very useful representation in systems engineering, but a stack of SysML diagrams does not equal MBSE any more than randomly drawn front, top, and side projections equals CAD. MBSE is about coherence and integration of the single descriptive architectural model, not multiple disjoint diagrams or even separate requirements, behavior, and implementation models. MBSE is about connectivity between the descriptive architectural model and the multiple analytic models that provide the engineering rigor. It’s all about the interrelationships and consistency of these relationships (regardless of the diagram or representation) to ensure we maintain design integrity. The many diagrams are valuable projections, allowing us to construct, analyze, and communicate the model from specific viewpoints. They are not the model itself.
Error #7 – Focusing on the MB rather than the SE.
The last error is both the largest and most common. We often obsess about our tools and our methods, and that is certainly true with the evolution to model-based approaches. In doing so, some establish modeling as a separate effort and specialty within the systems engineering team rather than an enabling approach for all systems engineers. Many begin modeling for the sake of modeling, doing too much, going too deep, or simply modeling the wrong things. Model-based systems engineering is critical in our efforts to engineer ever-more complicated and complex systems in an era of unprecedented change. However, it is a tool and technique in our systems engineering toolbox. We must begin with the end in mind and maintain our focus on applying systems engineering to deliver the required value to the customer and the stakeholders in an effective and efficient manner.
MBSE holds the promise of systems engineering with greater efficiency and effectiveness. It blends enhanced rigor with enriched communication. It is more scalable and more tailorable, enabling organizations to align their approach to reduce risk, increase quality, increase engineering resilience, reduce cost, or improve time to market. It is a critical step on the continued journey to advance our systems engineering practices. Hopefully we can begin to avoid these seven classic errors as we help our organizations deploy model-based systems engineering.
